Engineering Leadership Competency Development

As a Principal Engineer, one of my main goals is to enable and empower other engineers. Being a Principal Engineer involves not only technical expertise but also leadership and mentorship. Here are some of the things I do to enable and empower other engineers effectively: Clear Communication and Context Sharing: - Provide thorough context when assigning tasks or explaining projects. This helps engineers understand the bigger picture and make informed decisions. - Explain the "why" behind technical decisions and architectural choices to help engineers connect the dots. Encourage Autonomy: - Give engineers the freedom to experiment and explore different solutions. This fosters creativity and innovation. - Set guidelines and expectations while allowing room for individual problem-solving approaches. Safe Environment for Failure: - Emphasize that failures are learning opportunities, not setbacks. Encourage risk-taking and experimentation. - Foster an open culture where engineers feel comfortable sharing their failures and lessons learned without fear of judgment. Mentorship and Coaching: - Offer guidance and mentorship to help engineers navigate challenges and make informed decisions. - Provide constructive feedback on their work and help them identify areas for growth. Provide Growth Opportunities: - Identify projects or tasks that align with their career goals and give them a chance to learn and stretch their skills. - Support their professional development by suggesting relevant workshops, courses, or conferences. Advocate and Support: - Stand up for "your" engineers in meetings and discussions, especially during challenging situations. - Acknowledge and highlight their accomplishments to leadership and stakeholders. Open Door Policy: - Be approachable and available for discussions, questions, and concerns. - Create an atmosphere where team members feel comfortable seeking help when needed. Lead by Example: - Demonstrate a strong work ethic, technical proficiency, and collaboration skills. - Display a positive attitude and a willingness to learn from others. Promote Knowledge Sharing: - Organize regular knowledge-sharing sessions, where engineers can present their work, share insights, and learn from each other. Celebrate Successes: - Recognize and celebrate achievements, both big and small, to boost morale and motivation. Inclusive and Diverse Environment: - Foster inclusivity and diversity within the team. Respect different perspectives and encourage open discussions. Continuous Improvement: - Regularly seek feedback from engineers on your leadership style and ways to improve the work environment. Enabling and empowering engineers is an ongoing process that requires adaptability and empathy. These strategies help me create an environment where engineers feel valued, motivated, and empowered to excel in their roles.

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

In conversations with engineering leaders, I'm noticing an emerging theme: smart, capable managers who "grew up" in the 2010s and early 2020s are struggling to adjust to a new reality in tech leadership. For over a decade, the rule of the game was simple: hire, grow, and retain. Leadership meetings were dominated by conversations about headcount, hiring progress, and ambitious growth targets. There was grilled venison tapas at lunch, and we talked a lot about psychological safety and inclusion. These were important topics (and tapas), but they existed in an environment of abundance. Sure, we wanted things to be more efficient — but the solution was often to spend more money to make it so. We had no choice — headcount was growing by the day, and the focus was on scaling rapidly to meet demand and capture market share. Fast forward to today, and the landscape has shifted dramatically. I spoke with a VP of Engineering recently: smart, capable, and struggling with how to report upwards effectively while still maintaining empathy for the realities of software engineering and the people in their organization. They were visibly relieved to hear me say that others are grappling with these same challenges. Engineering leaders at all levels are living in a new world of intense scrutiny and accountability. The instincts and strategies they honed over years of rapid growth aren't serving them well in this new environment. Under pressure, toxic approaches that would have been quickly dismissed in the past are now getting airtime they never would have deserved before. We're seeing a fundamental shift in what it means to be an effective engineering leader: 1. Financial Acumen: Leaders now need a deep understanding of financial metrics and how engineering decisions impact the bottom line. 2. Operational efficiency: There's a renewed focus on doing more with less, optimizing processes, and identifying areas of waste. 3. Strategic prioritization: With limited resources, the ability to ruthlessly prioritize and communicate trade-offs has become crucial. 4. Change Management: Leaders must guide their teams through organizational changes and shifts in company strategy with transparency and empathy. 5. Metrics-driven decision-making: There's increased pressure to justify decisions with data and demonstrate tangible value. 6. Stakeholder management: Navigating complex relationships across the organization and managing expectations has become more critical than ever. The challenge lies in balancing these new demands with the core principles of effective engineering leadership: fostering innovation, maintaining team morale, and delivering high-quality products. How has your role changed in the past 12-18 months?

I was doing a reference check for a senior engineer role recently. The manager shared something that stopped me in my tracks. When they started in their leadership role, they discovered associates who'd been there for 3 years. Same position. Same work. Management had written them off as a "sunk cost." They weren't paying attention to them. Just throwing them in the mix to triage tickets. But this manager saw something different. They built competency frameworks. Not fancy programs. Just clear structure showing what "good" looked like at each level. L&D pathways that gave associates authorisation to upskill. One associate churned out 2 to 3 certifications in 3 months whilst doing their day job. Started leading internal initiatives. Getting brilliant feedback. The promotion became a no-brainer. But only because someone actually helped them advocate for themselves. And the best part? Once promoted, this engineer immediately turned around and started mentoring the associates coming up behind them. Your associates aren't underperforming because they lack capability. They're underperforming because you lack structure. This isn't just about being a good leader. This is succession planning. When your senior engineers leave or get promoted, who's ready to step up? If you're not developing your associates now, you'll be hiring externally at a premium later. What's one change you've made that's had the biggest impact on developing your junior engineers?

The best engineering leaders don’t save the day. They build teams that don’t need saving. Tech leads who fall into the Heroic Engineer Trap when they: Jump in to save a release at the last minute. Debug production issues because "no one else can." Bottleneck learnings to whatever critical PR they happen to have time for. At first, it feels useful, necessary—even rewarding. But over time, it becomes a leadership failure in disguise. 🚨 Your team stays dependent on you. They don’t grow if you keep being the last line of defense. 🚨 You mask deeper problems. Poor automation? Gaps in team knowledge? Heroics hide systemic failures. 🚨 You burn out. And when that happens, the team falls apart. Real tech leadership isn’t about fixing problems—it’s about creating a system where problems get solved without you. ✅ Shift from hero to coach. Guide your team while handling production issues before they escalate. Stop being a doer and become a facilitator. ✅ Pair, post-mortem, and distribute knowledge until you’re not the only expert. ✅ Automate away the chaos. CI/CD, strong testing, and clear ownership reduce the need for “saviors.” Automate what "done" means and don't let humans gatekeep on everyday processes If you're fixing bugs at midnight you’re compensating for a broken engineering process. Have you ever fallen into the Senior Engineer Trap? How did you escape it? 👇

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.

Leadership is easy. You just use your knowledge to tell the team what to do… … Right? This is what I thought years ago when I transitioned from being a senior engineer to leading a team as an engineering manager. I thought I’d cracked the code: just apply my technical expertise, guide the team, and voilà--success! Spoiler alert: I was wrong. The game was fundamentally different. No longer could I just “fix” things by diving into the code or tweaking the architecture. My role had shifted, and so did the skills required to succeed. This challenge compounded when I became a director. I had to scale myself as a leader, and trust me, it wasn’t easy. Here are three lessons I’ve learned along the way that might help you transition from an IC role to a leadership position: 1) Develop Strategic Thinking While Letting Go of the Day-to-Day As a senior IC, it’s all about diving deep into the details. But as an exec, your focus needs to shift to the bigger picture. Think about where your team and organization need to be 1, 3, or even 5 years from now. Step back and empower others to own the day-to-day work. Provide clarity on the “why” and “what,” and let your team handle the “how.” It isn’t “hands-off” leadership--it’s “hands-available-when-needed.” 2) Build Influence Across Teams and Stakeholders Influence isn’t just about giving great presentations (though that helps). It’s about building relationships and trust across functions--product, marketing, finance, you name it. You need to connect the dots between departments and align everyone toward a common goal. One of the most valuable lessons I learned was that your ability to lead doesn’t depend on your authority; it’s about your ability to influence without authority. 3) Maintain Technical Credibility While Empowering Others Here’s the tricky part: As a technical leader, you can’t lose touch with your technical foundation, but you also can’t write all the code or design every system. Stay informed by asking the right questions and understanding the trade-offs your team is considering. This way, you can provide guidance without micromanaging. The best leaders balance credibility with trust, creating space for their teams to grow and thrive. Going from IC to exec isn’t just about a new title or responsibilities. It’s about fundamentally changing how you think, work, and lead. It’s hard--but it’s worth it. Leaders- what lessons did you learn as you transitioned into leadership? ICs- If you’re preparing to take that step, what challenges are you facing? Drop your thoughts in the comments--I’d love to hear your perspective.

I see a big difference between engineers who move into leadership smoothly and those who struggle. It rarely comes down to technical ability. It comes down to openness. The engineers who lead well today are the ones who stay curious. They listen to younger team members and actually try new ideas. They understand that methods evolve. They’re not afraid to say, “show me how you’re doing that.” The opposite mindset still exists. Some senior engineers insist that the old way is the right way because it worked for them. But that approach doesn’t hold up when teams are made up of people who learn and communicate differently. If leadership is your next step, start practicing openness now. When you’re reviewing a design, ask why someone approached it that way. When a younger engineer brings up a new tool, try it before you decide it’s not useful. Good leaders set direction. Great ones also create space for others to contribute. Engineering is collaborative by nature, and the best leaders keep that spirit alive even as their responsibilities grow.

The Bridge Builders: A Story of True Engineering Leadership !! Early in my career as an engineering leader, I came across a metaphor that stuck with me: Engineering managers are bridge builders. But here’s the twist—these aren’t bridges you can see or touch. They’re invisible connections that align vision, strategy, and execution. Let me tell you about a moment that changed how I thought about leadership. A few years ago, we were working on a high-stakes project. Deadlines were tight, tensions were high, and technical debt felt like a boulder we were rolling uphill. One day, a senior engineer approached me and said, “I don’t think we’re solving the right problem.” He was right. We were so focused on what we were building that we’d lost sight of why we were building it. As a leader, I realized I had two choices: 1. Push the team harder to deliver on time. 2. Pause, realign, and rebuild the bridge between our technical goals and business priorities. I chose the second option. We gathered the team, revisited customer feedback, and refocused on the problem we were trying to solve. The result? We scrapped half the roadmap, doubled down on a single feature, and launched something that not only met the deadline but became one of our most successful rollouts. Here’s what that experience taught me about leadership: • A leader’s job isn’t to have all the answers; it’s to ask the right questions. When you feel like something is off, lean into it. Challenge assumptions. Encourage your team to do the same. • Clarity beats speed. The fastest way to fail is to move quickly in the wrong direction. Slow down to align before you accelerate. • People need purpose, not just tasks. When teams understand the why behind their work, they move mountains. As leaders, it’s our job to connect their work to the bigger picture. Leadership isn’t about being the smartest person in the room. It’s about building bridges—between ideas, people, and outcomes. And when those bridges are strong, they carry teams to places they never thought they could go. What bridges are you building today? #EngineeringLeadership #Storytelling #TeamAlignment #LessonsInLeadership

The very best engineering leaders have stronger communication and interpersonal skills than technical skills. The job is now more leader than engineer. It pays to heed that. I am part of a very large and active online community of engineering leaders. I won't name it here, but you probably know it. Every few days, an up-and-coming leader posts a variation on the same question, and a discussion ensues. The details change, but the question is nearly always the same, roughly: "how much technical oversight should I have over the engineers, now that I am a manager?" I've come to believe that there are basically two positions on this issue. And everything that happens in your company (assuming this is a tech company), in fact everything that will happen from here on, absolutely hinges on which side you're on. One side is focused on the technical. This leader sees themselves has having risen through the ranks based on their technical knowledge, their engineering prowess, the respect they have gained from the engineers. They believe their job is to "drive" engineering forward, to arbitrate quality, to enhance processes, to weigh in on architecture and technical stack. There are engineering organizations that require such hands-on technical guidance. These are not the highest performing self-organized teams, and so there is a need for such oversight. They could be coached and guided to become more performant, but not by overseeing their technical work. It's simply aggravating the lack of ownership and responsibility that created the gap in the first place. The other side is focused on leadership. This leader sees themselves as responsible for making sure that folks who do the engineering work have everything they need in order to do it well. They respect the autonomy of the team, and empower them to make their own decisions about tech stack, process, architecture. This leader spends most of their time meeting with individuals and helping them to become better at their craft. This is the mindful leader who is able to coach engineers through their own self-improvement, rather than dictating how they should work. These are the very best high-performing teams. The leadership style radiates trust, and the teams rise to accept that trust by taking care of each other and the code. A team like this would balk at any technical micro-management. They don't need it, and they don't want it. Over time, a leader like the first type above would probably drive out the best people, so that all who were left were those who thrive in a technical micro-management environment. The type of leader can very much determine, over the long run, the type of engineering organization that is being led, and thus the business outcomes that are achieved by that team. Where you stand on this issue, more technical vs more leader, will likely make or break the company.