Lessons Learned from Leading an Engineering Society

When I got promoted to my first VP role, I thought: more control, more meetings, more decisions. Turns out, that was the fastest way to fail as a leader. I went from managing a few teams to owning strategy and execution for an entire function. Overnight, my calendar exploded. I thought leadership was about doing more. Here’s the truth: I got it wrong. A lot. Over the next two years, I learned the hard way that being a true leader is very different from being a great manager. Here are the lessons that stuck, because I earned them the hard way: 1. Management ≠ Control I hovered. I micromanaged. And I watched trust erode. People didn’t need my shadow, they needed clarity and confidence. 2. High performers quit quietly I lost a rockstar early. Not to a competitor - to boredom. Top talent needs challenge, not comfort. 3. Urgency destroys priorities When everything is a fire drill, nothing matters. I learned to step back and define what really moves the needle. 4. Fewer decisions, better systems I thought being a VP meant making every call. That’s how you burn out. The fix? Build systems that make decisions for you. 5. Morale starts with hard truths I sugarcoated bad news to keep the peace. It backfired. Teams trust you more when you stop spinning. 6. Meetings hide accountability If no decision gets made, it should’ve been an email. Every meeting needs an owner and an outcome. 7. Burnout signals broken systems I used to think tired teams needed pep talks. Wrong. Burnout means your structure is broken, not your people. 8. Quiet ≠ Inactive I almost wrote off a quiet engineer, until I realized they powered half our success. Leaders look deeper. 9. Culture follows what you allow What you tolerate becomes the norm. Missed deadlines, skipped follow-through - ignore it, and it becomes culture. Two years later, I realized something big: Leadership isn’t about doing more. It’s about creating an environment where the right things happen without you in the room. If you’re making the leap from manager to leader, here’s my advice: -Unlearn control. -Focus on systems, not heroics. -Remember: culture is built in the moments you overlook. You’ll mess up (I sure did). But if you embrace these hard truths, you’ll become the kind of leader teams run toward, not away from.

When I first transitioned from individual contributor to engineering leader, I thought my job was to have all the answers. To always know the right path. To solve every problem myself. 𝗜 𝘄𝗮𝘀 𝘄𝗿𝗼𝗻𝗴. Here’s the truth no one tells you: 𝗧𝗵𝗲 𝘀𝗸𝗶𝗹𝗹𝘀 𝘁𝗵𝗮𝘁 𝗺𝗮𝗸𝗲 𝘆𝗼𝘂 𝗮 𝗴𝗿𝗲𝗮𝘁 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿 𝗱𝗼𝗻’𝘁 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗰𝗮𝗹𝗹𝘆 𝗺𝗮𝗸𝗲 𝘆𝗼𝘂 𝗮 𝗴𝗿𝗲𝗮𝘁 𝗹𝗲𝗮𝗱𝗲𝗿. As an engineer, success is clear: you write the code, solve the problem, ship the feature. As a leader, success becomes fuzzy. It’s no longer about what you deliver—it’s about what your team delivers. Here are 3 lessons that hit me hard during this shift: 𝗦𝘁𝗼𝗽 𝘀𝗼𝗹𝘃𝗶𝗻𝗴—𝘀𝘁𝗮𝗿𝘁 𝗲𝗺𝗽𝗼𝘄𝗲𝗿𝗶𝗻𝗴. Instead of jumping in to fix every issue, ask: “What do you think we should do?” You’ll build confidence and unlock potential in your team. 𝗟𝗲𝗮𝗱 𝘄𝗶𝘁𝗵 𝗰𝗹𝗮𝗿𝗶𝘁𝘆, 𝗻𝗼𝘁 𝗰𝗼𝗻𝘁𝗿𝗼𝗹. A great leader doesn’t micromanage; they set clear goals and trust their team to figure out the “how.” 𝗠𝗲𝗮𝘀𝘂𝗿𝗲 𝘀𝘂𝗰𝗰𝗲𝘀𝘀 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁𝗹𝘆. Your wins are no longer about code or tickets—they’re about growth, trust, and outcomes. The moment I embraced this mindset, my team thrived. And honestly? So did I. Leadership isn’t about being the smartest person in the room. It’s about creating a room where everyone feels empowered to bring their best. If you’ve made this shift—or are navigating it now—what’s been your biggest lesson? Let’s learn from each other. #Leadership #EngineeringManagement #CareerGrowth

Early in my career as an Engineering Manager at #Amazon, I avoided being too direct because I didn’t want my team to hate me — turns out, that’s exactly how you fail your team. My manager told me something I’ll never forget: “You can’t expect people to do what you want unless you tell them what you want.” Here’s what I had to learn: 1. Avoiding hard feedback isn’t kindness — it’s poor management You’re choosing your comfort over their growth. 2. If you’re saying it in a review, you’ve said it too late It should never be the first time they’re hearing it. 3. Being liked shouldn’t come at the cost of being clear The moment you prioritise comfort over honesty, you stop leading. 4. Good feedback is specific — not generic “Be more proactive” doesn’t help. “Call out risks earlier instead of raising them at the end” does. 5. Feedback isn’t just for when something is wrong If you only speak up when things go badly, you’re already too late. Most engineers don’t struggle because of hard feedback — they struggle because they never got it. #EngineeringManager #Leadership #CareerGrowth #TechLeadership

As Chief Engineer of strategic ballistic missile submarine USS Kentucky, I felt I had to have every answer. I was in every action, every system, every repair. The stakes were too high for anything less. But here’s the truth: that approach was untenable. No single person can shoulder that weight forever. What saved me—and what made our team world-class—wasn’t my control. It was: ✅ Delegation — trusting officers and sailors to own their watch. ✅ Intent-based leadership — giving clear direction, not micromanagement. ✅ Trust-based communication — speaking up early, listening deeply. ✅ Transparent expectations — clarity about what “good” looked like. ✅ Deep but meaningful checking — not hovering, but verifying. Scaling your business is no different. Early founders often try to be in every decision, every hire, every customer interaction. But just like on a submarine, that weight will break you—and stall your team. The transition from “I control everything” to “we achieve everything together” is what transforms brilliant engineers and scientists into enduring leaders. 💡 Where are you in that journey—holding every answer, or scaling through trust? #Leadership #ScalingUp #Delegation #ExecutiveCoaching #EngineeringLeadership #CoreX #Trust #IntentBasedLeadership #focalpountcoaching

One of the most defining moments in my leadership journey came from a simple realization: Our students were seeking more spaces to feel seen, heard, and celebrated. At 21, returning from NYU, I reflected on our convocation ceremony at Manav Rachna—an event rooted in pride and tradition. While it carried the weight of legacy, I saw an opportunity to make it more student-focused and emotionally resonant. That moment sparked a shift in how I approached leadership—not by choosing between tradition and transformation, but by blending both. 1️⃣ The Convocation Celebration Inspired by NYU’s vibrant format, I proposed some unconventional changes. What I found was incredible support from our leadership, grounded in data and driven by a shared desire to honour our students more meaningfully. The outcome? A 300% increase in graduation attendance and moments that lived on through proud social media shares. 2️⃣ The Internship Evolution There were initial concerns that interdisciplinary programs might affect academic depth. But when engineering students returned from marketing internships with sharper problem-solving skills, the results spoke for themselves. Today, 78% of participants outperform peers in innovation challenges. 3️⃣ The Feedback Framework We introduced “Reverse Office Hours,” a space for students to offer structured feedback to faculty. What began as an experiment has grown into a valued tool for refining curriculum and enhancing classroom engagement. The Lesson? Great institutions thrive not by preserving legacy alone, but by embracing student voices as catalysts for growth. At Manav Rachna, it’s not about tradition versus change—it’s about evolving together. So, when I’m at a crossroads, I ask: •⁠ ⁠Are we doing this because it truly serves our students or simply because it’s always been done? •⁠ ⁠Can this policy stand up to the thoughtful feedback of a 19-year-old learner? The real magic begins when we stop viewing “student-centric” and “senior-led” as opposing forces—and start seeing them as partners in progress. #education #innovation #students #convocation #graduation

I once saw a VP of Engineering roll up his sleeves during a P0 outage, and it completely redefined leadership for me.  It was a high-stakes moment.  A major sales event, our big billion sale was happening for the whole of Indonesia. Millions of users and a critical service had just crashed.  The engineering team was already in the trenches, deep into debugging. I was working alongside them. And then, in walks the VP.   Not to demand updates.   Not to assign blame.   But to dive into the logs,  tracing issues alongside the team.  No one expected it.   He had every reason to step back,  and let the engineers handle it.   But he didn’t.  That day, there were no titles across our office,  everyone was just another problem-solver.  Here’s what I learned: ► In a crisis, true leaders show up.   — They don’t hover from a distance, they get involved.   — They clear roadblocks.   — They lead by example.  ► But outside of a crisis, true leaders step back.   — They build trust.   — They give teams space.   — They empower others to shine.  Some leaders focus on control when everything is smooth but go missing when real challenges arise. Great leaders do the opposite. They trust their teams to build without interfering, but when chaos hits, they’re right there, helping clear the path. So next time you’re in a tough spot, ask yourself:   Are you helping solve the problem, or are you just watching it get worse?

Great engineering leadership isn’t about solving everything. It’s about creating the conditions where your team can. In my early leadership days, I thought I had to walk in with the answers. Over time, I learned something better: Most engineers don’t need hand-holding. They need clarity, context, and trust. Here’s how I lead now (and what’s worked): 1. Present the problem, not a pre-baked solution. → Engineers are problem-solvers. Don’t rob them of that. → Instead of “We need to use Kafka here,” say: “We need async processing at scale. Thoughts?” 2. Share constraints early. → Be open about deadlines, budget, team bandwidth, or tech debt. → Constraints help the team make realistic design choices. 3. Make room for trade-off discussions. → Your job isn’t to rush decisions. It’s to ensure good ones. → Let the team think through latency vs cost, monolith vs microservices, etc. 4. Guide the decision, don’t dictate it. → Ask: “What risks do you see?” or “What’s your fallback plan?” → Step in only when clarity or urgency is needed. 5. Protect builder time. → Cut unnecessary meetings. Shield them from noise. → Innovation dies in a calendar full of status syncs. Leadership is knowing when to speak and when to listen. You don’t earn trust by having all the answers. You earn it by helping your team find better ones.

Very rarely does one get a chance to do what most engineers consider career-defining — and quietly terrifying: modernizing platforms that the business cannot afford to stop — systems so deeply embedded in the business flow that the org had built an entire nervous system around them. What I've learned about leadership in those trenches looks nothing like what gets talked about in most engineering articles. Because when you're running a platform that processes millions of transactions a day, where a one-minute outage has direct revenue consequences, engineering leadership looks fundamentally different. You have to hold multiple truths at once. first: your platform is a product. It has users, adoption curves, and a value proposition. If engineering teams dread integrating with you, if documentation is a maze, if the capabilities you're investing in don't map to the revenue lines your business is betting on — you're failing, regardless of your SLA. second: your platform is quiet, steady, and invisible — the highest compliment any platform team can receive is that nobody is talking about them. Silent in the background yet holding up everything that matters to the business. That requires obsessing over reliability, configurability, and the kind of quiet adaptability that lets the business pivot without the platform becoming the bottleneck. third: the hardest decisions aren't technical. They're prioritization — while the business keeps moving. You're never building in a clean room. The platform must evolve while it's running at full load. Every technical decision must be weighed against what the business needs now, not what engineering needs eventually. fourth: never stop moving. Most efforts start strong, migrate a slice or two, and end up with two half-finished systems running in parallel indefinitely — neither fully trusted, and both expensive to maintain. The job is to turn every opportunity into momentum until you reach the tipping point and to stay focused when the finish line isn't yet visible. Read the full article below.. And let me know your thoughts. What else am I missing?

What I Wish I Knew as an Engineering Manager When I transitioned from being an engineer to an engineering manager, it felt like I had walked into a new game—except no one handed me the rulebook. At first, I tried to apply the same principles that made me successful as an engineer: focus on technical problems, write great code, and aim for perfection. But I quickly realized… those skills weren’t enough. Leadership is a completely different challenge. It’s not about being the smartest in the room or solving every problem yourself. It’s about empowering others, navigating ambiguity, and creating an environment where the team thrives. Here are a few hard truths I’ve learned along the way: 1. Your success is no longer measured by what you deliver—it’s about what your team achieves. Early on, I held onto tasks because it felt safer. But the real impact comes when you step back and let the team take the lead. It’s uncomfortable at first, but seeing someone grow because you gave them space? That’s the real reward. 2. You’re debugging humans now, not code. If your team isn’t aligned or a project stalls, the problem isn’t always technical—it’s often rooted in communication, trust, or clarity of roles. Learning to spot these “bugs” and resolve them is the real skill of management. 3. Decisions don’t have to be perfect, but they have to be made. As engineers, we’re trained to seek the “right” solution. But as managers, waiting for perfect clarity often means missed opportunities. Sometimes, you just need to make the best call with the data you have and adjust as you go. 4. Meetings aren’t the enemy—they’re your new codebase. I used to think meetings were distractions. Now, I see them as where the real work happens. Every meeting is an opportunity to align, resolve conflicts, and steer the team toward success. 5. Feedback is the most powerful tool in your arsenal. Giving feedback isn’t just about improving performance—it’s about building trust. When you do it consistently and thoughtfully, it transforms your relationship with the team. Becoming an engineering manager isn’t just a career shift—it’s a mindset shift. You’re not there to “control” the team; you’re there to guide them, learn from them, and create the conditions where they can do their best work. Which of these lessons resonates with you? Or what advice do you wish you’d known earlier in your management journey? #Leadership #EngineeringManagement #GrowthMindset

Leading a team of engineers at Paytm taught me invaluable lessons as we scaled from a small group to over 300 individuals. Here are some key takeaways: - **Lesson 1: Trust and Empowerment:** Trusting your team is paramount. Avoid micromanaging by leveraging tools, automation, and innovation to streamline repetitive tasks. This approach frees up time for creative thinking and fosters a more dynamic work environment. - **Lesson 2: Strategic Spending:** Saving money isn't just about cutting costs; it's about smart allocation. By optimizing expenses, we could redirect resources towards innovative projects like PocketUrMoney, PaytmCaller, Self-Heal, Squilify, and OneView. Every saved dollar fuels new ideas and drives progress. Reflecting on my career spanning two decades, I've come to appreciate the challenges and rewards of nurturing a large team. Join the conversation below to share your thoughts on the complexities of team growth. #Leadership #TechGrowth #Teamwork #Learnings Let's engage in a discussion on the nuances of team expansion and development.