Intent & Capability. Never Resources.

Fifteen years ago, I walked into my first program management role and heard something that made me wince. A senior executive was discussing headcount planning and casually referred to our engineering team as "resources to be allocated." These weren't spreadsheet entries - they were people I'd just spent weeks getting to know. Anupam, who could debug anything after his morning chai. Asha, who had this uncanny ability to spot design flaws before they became disasters. Sandeep, who'd been coding since before most of us owned computers.

That's when it hit me. Every corporate objective, every ambitious target we set, comes down to two things: Intent and Capability.

Intent isn't just leadership saying they want better outcomes for customers. Real intent is when you see a VP rolling up their sleeves at 8 PM because they genuinely believe the solution matters. It's the difference between hitting quarterly numbers and actually solving problems that keep people awake at night.

But here's what I've learned managing teams across Mumbai, London, and Singapore - capability isn't just budget allocation. Yes, you need financial backing. But true organizational capability? That's when someone like Sandeep decides to stay back and mentor a junior developer, not because his KRAs demand it, but because he remembers when someone did the same for him. It's when Asha suggests a completely different approach that saves six months of work, because she feels heard and valued enough to speak up.

I've seen companies with massive budgets fail spectacularly because they treated people like interchangeable components. And I've watched small teams punch way above their weight because leadership understood that behind every successful program is someone who chose to care about it.

Maybe it's time we retired "human resources" altogether. How about "Human Capability" instead? Because the moment we start talking about people as resources, we've already missed the point.

What do you think? Does the language we use in corporate environments shape how we actually treat people?

Build teams that actually deliver... themselves

Last year at 5:47 PM one Friday, one of my lead engineers pinged me: "We're blocked on the API integration, the integration team went dark, and the release is due on Monday" My immediate instinct was to jump in, fix it myself, make the heroic save—after all, I've been doing this for 15+ years and know exactly how to untangle these messes. But here's the thing about leadership I've learned the hard way: the moment you rob someone of solving their own problem, you've stolen their growth. So instead I asked: "What are your top three options, and which one would you bet on?"Delivery consistency isn't about clockwork precision or robotic adherence to sprint velocity—it's about building a team that knows how to think when things go sideways. Because things will *always* go sideways at 5:47 PM on a Friday. The best teams I've built weren't the ones with the fanciest tech stack or the most impressive resumes; they were the ones where each person felt ownership, not just over their code, but over the outcome. When someone on your team wakes up at 2 AM thinking about an elegant solution to yesterday's problem, not because they have to, but because they genuinely care—that's when you know you've built something real.Team morale isn't just donut parties and motivational quotes (though I'm not opposed to good donuts). It's that moment when your junior developer presents an architecture idea that's actually better than yours, and you're genuinely delighted rather than threatened. It's watching someone who joined six months ago now mentoring the new hire with the same patience and enthusiasm someone once showed them. Morale lives in the space between "I trust you to figure this out" and "I'm here when you need me"—that delicate balance where people feel both challenged and supported.The engineer from Friday? She came back in 40 minutes with a workaround involving a clever retry mechanism I hadn't even considered. We shipped as promised on Monday, and more importantly, she later owned that entire integration pattern across our services. These are the strange and abstract victories that create great teams—not the perfect sprint retrospectives or the flawless burn-down charts, but the accumulated moments where people surprise themselves with what they're capable of achieving. That's the real delivery consistency: building teams that solve tomorrow's problems you haven't even thought of yet. And most importantly, trusting your team to solve them in time for the milestone delivery.

The Art of Leading Without a Manual: Lessons from Managing 30+ Engineers

Three years ago, I inherited a team that looked suspiciously like a collection of brilliant individuals who'd rather debug code than attend meetings. Sound familiar? As someone who once convinced his family to let him ride a motorcycle by sheer persistence over "1 year, 9 months and 22 days," I knew this would require a different approach than the standard management playbook.
The breakthrough came when I stopped trying to be the smartest person in the room and started being the most curious instead. During our first team retrospective, instead of dictating process improvements, I asked a simple question: "What's the one thing that makes you want to throw your laptop out the window?" The responses were brutally honest and incredibly insightful. Our deployment pipeline was slower than Mumbai traffic during monsoon, and our code review process had more bottlenecks than the old RTO where I once got my license.
Here's what I learned about leading technical teams: they don't need a boss, they need a conductor. My job isn't to know every line of code or architect every solution. It's to remove obstacles, amplify their brilliance, and occasionally translate "this will take five minutes" into realistic timelines for stakeholders. When one of my engineers spent three days optimizing a query that improved system performance by 40%, I didn't question the time investment - I celebrated it in our all-hands meeting. Well worth the boxes of donuts for the team that week!
The real magic happens when you create space for people to be themselves while working toward something bigger. Whether it's implementing ISO 27001 compliance or delivering a critical client feature, success comes from understanding that every engineer has their own version of that perfectly timed motorcycle kick-start - you just need to give them room to find their rhythm. Today, our team delivery rate has improved by 35%, but more importantly, they actually look forward to our Monday stand-ups. Not bad for someone who "dislikes speaking with people, unless I really really like them."

Delivering Software Like Tuning a Royal Enfield: Patience, Process, and a Good Mechanic

There's something beautifully analogous between delivering enterprise software and getting a vintage Bullet to start on the first kick. Both require understanding the intricate mechanics beneath the surface, both demand respect for process, and both will humble you faster than you can say "deployment pipeline."

After 20 years of wrangling code releases and managing $3M+ budgets, I've learned that successful software delivery is less about heroic last-minute saves and more about boring, repeatable excellence.

The epiphany came during a particularly stressful client delivery three years ago. We were implementing a complex integration, and our Agile transformation was about as smooth as my first attempt at riding that Bullet - lots of stalling, some embarrassing moments, and the occasional backfire. That's when I borrowed a page from Raju bhai's garage wisdom: "Every machine has its rhythm, you just need to learn to listen."

So instead of forcing our team into textbook Agile practices, we started adapting the methodology to fit our actual workflow, not the other way around.
The results were transformative. Our delivery cycles shortened from 6 weeks to 3 weeks, our on-time delivery rate jumped to 92%, and most importantly, our code quality improved dramatically. We implemented continuous integration that actually worked, established code review practices that enhanced rather than hindered productivity, and created automated testing suites that caught issues before they became customer problems.

The secret sauce wasn't in the tools - it was in treating software delivery like craftsmanship rather than just cranking out features.
Today, when I review our weekly delivery metrics with clients, I see the satisfaction in their faces that mirrors my own when I hear that perfect mechanical tick of a well-tuned watch. Clean code deployed seamlessly, features that solve real problems, and systems that scale gracefully - these aren't accidents, they're the result of patient, methodical excellence. Some might call it boring, but there's profound beauty in software that just works, every single time.