Engineering Leadership Development

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

For senior engineers growing to staff engineers, learn to let go of control. I've managed and mentored a number of engineers over the years, and I've noticed a common failure mode in strong senior engineers that holds them back from growing. They go from leading a team of ~5 to a team of ~12 and suddenly their old operating models aren't successful any more. One such engineer told me, "I don't have time to code any more. I don't even have time to review every change!" My immediate response was: "Why do you feel you need to review every change in a team of this size?" This engineer, and others like him, fell into one of the classic senior engineer traps. As the TL of a small team, you can become intimately familiar with your codebase, to the point that you've written or reviewed every single line within it. That familiarity is a strength, and makes you a good TL and senior engineer. But it does not scale to larger team sizes and bigger engineering roles. One of the things you must let go of in order to scale is the idea that you need to inspect and approve everything. Code can be high-quality without being written exactly the way you would write it. Instead of asking "how do I find time to review everything?" you have to start asking "how do I ensure quality without reviewing everything?" That's the question that leads you to operate like a staff engineer. There are many viable answers: delegate authority, mentor more junior folks, institute a culture of testing and observability, swap low-level code reviews for high-level design reviews. But the path to growth beyond being the TL of a single team or component always requires that you figure out a scalable way to be accountable for a larger domain of code than you can feasibly exercise complete control over. Relinquishing some control is the only path to a broader scope.

I "worked the system" to help my first two senior engineers become Principal Engineers. Here is how I did it and how you can copy this process. Often, I write about leaders. I do not say enough about how individual contributors can grow and how managers can partner with them to do so. Today, I give specific examples with names. In 2011, Amazon had strict rules about promoting senior engineers (L6) to Principal Engineers (L7). I was part of the review process that changed these standards because our data showed external hires at this level "failed" ~10x more often than internal promotions. We were driving away internal stars by holding them to a higher bar than external hires. But when I tried to hire a Principal Engineer, the evaluators determined that my team of several hundred engineers "had no work challenging enough to need a PE." This was nonsense, but instead of hiring I would need to get one of my own senior engineers promoted. My plan was to take one of my strongest engineers, give him a principal-scope job, and use his work as proof to justify his promotion. My organization had about 50 first-level technical teams (each with a manager and 6 to 10 direct reports) spread across Seattle, SoCal, and Bangalore. New to leading such a huge, distributed organization, I had lost touch with each team's detailed work. To be a better leader, I needed to get deep with my teams. This also created an opportunity to "make" a Principal Engineer. I asked a star on my team, Geoff Pare, to pick one team each week for a 90-minute architecture and roadmap deep dive. My EA helped with scheduling and Geoff picked the teams, helped them prepare, and invited other senior engineers to the reviews. Now we get to the tricky secret recipe: 1) I cared enough to try to break the promotion logjam for my top engineers 2) I created a plan that tied to my own needs so that I could win at the same time 3) I put a system in place (once a week, one team, supported by my EA) to make it sustainable 4) I asked Geoff lead off the questioning and discussions with the team. Candidly, this masked the fact that with my huge organization I was sometimes unfamiliar with a team’s work. 5) Through the review process, I fixed my own unfamiliarity. When we presented Geoff's promotion case after doing this work, the tune completely changed from when I had tried to hire a PE. Reviewers said, "He's already doing a PE job, leading architecture across 500 people." He sailed through his promotion. I replaced Geoff in this role with another star, Trevor Lipscomb, and he became a PE soon after. The lesson to managers is this: To grow your team, you must invest effort and bend systems to your goals. For ICs: Look for opportunities like this to collaborate with your manager. Find win/win situations to increase their buy-in on your promotion. My class has "Senior Manager" in the title, but the playbook works for IC roles too. Join to get promoted. https://buff.ly/gos4t9i

Arguably, the most important job of a leader is to develop talent and build great teams, starting with their direct reports and their direct report team. Great leaders understand that investing in the individuals on their team, to help them grow and have greater impact, is their core job and not an overhead or a chore for them. They also know that great individuals don’t necessarily make a great team and that building high performing teams requires even additional investment. Finally, they recognise that these investments are key to transformative and sustained growth of the company. Here are some of my reflections and learnings in regard to developing talent. I will share some thoughts on building high performing teams in a separate post. 1. Enable your team member to soar with their strengths. Often leaders spend too much time agonising about the gaps or opportunities their team member may have. Amplifying what your colleague is really good at is good for the organisation and for the individual. This is about providing them with challenging opportunities where they can make a massive impact with their strengths, and celebrating their accomplishments. 2. Actively invest in helping your team member neutralise their major weakness(es), especially if the latter is preventing them from being effective or achieving their true potential. This is about building context with them as to why this weakness can slow them down and helping them internalise that working on this opportunity is good for them. Coaching in the moment or reflecting about situations which you were both part of and helping them recognise an action or behaviour that could have been different is often powerful. 3. Build an environment of transparency so that the individuals understand where they stand within the organisation. Being unclear with feedback or holding back on sharing how an individual is perceived within an organisation so as to avoid hurting them, is actually counter productive. Helping team members sharpen their antennas around how they come across to others goes a long way towards developing reflective, continually learning leaders. 4. Make development conversations an integral part of the work related discussions to the extent possible. Avoid making them awkward, one off events but rather an ongoing commitment to supporting your colleague in their development journey. 5. Most importantly, recognise that the responsibility you have is a privilege and not a license to preach. We could all be working for each other some day and just because one is leading someone within an organisational context doesn’t make one “superior” to their direct report. Helping develop leaders of the future is one of the most impactful and rewarding aspects of being a leader. What are some of your reflections on this topic? #leadership #development #talent #careergrowth

My Anti-To-Do List as a Product Leader: (𝘵𝘩𝘦 𝘵𝘩𝘪𝘯𝘨𝘴 𝘐 𝘸𝘢𝘯𝘵 𝘵𝘰 𝘢𝘷𝘰𝘪𝘥 𝘢𝘵 𝘢𝘭𝘭 𝘤𝘰𝘴𝘵𝘴) 1. Do not carry the product burden alone As a product leader, I often feel the weight of the product's success or failure rests disproportionately on my shoulders. But in truth, it is a team effort. I must rely on and empower my team, not take on the full burden myself. 2. Do not pretend to have all the answers    I need to frequently seek feedback from my team and customers, and listen intently. Their on-the-ground insights will lead to better solutions. 3. Do not mask struggles or failures I should show vulnerability and transparency with my team when we hit obstacles. Hiding challenges and failures erodes trust and psychological safety. 4. Do not pretend expertise over my engineering team I aim to be fluent in my product's technical capabilities and limitations. But that is different than actually building the tech. I need to recognize the expertise my engineering team brings and lean on their judgement 5. Do not dictate deliverables without context I must share not just the 𝘄𝗵𝗮𝘁 but also the 𝘄𝗵𝘆 behind my expectations. Providing clear context empowers my team to make the best decisions aligned to the strategy 6. Do not treat data as gospel Metrics inform but do not dictate decisions. I need to apply nuance and context based on the situation and blend quantitative data with qualitative insights. 7. Do not get derailed by others’ perceived urgency   I must anchor on my product strategy and push back on scope creep from stakeholders, rather than getting pulled off track reactively. 8. Do not let work displace life I need boundaries to avoid burnout. My long-term effectiveness requires nurturing other parts of my life. 9. Do not shy away from disagreement As a leader, disagreement will happen. But avoiding conflicts leads to sub standard outcomes. I need the courage to lead through it.   10. Do not ignore intuition When data conflicts with my experience, it merits deeper digging. Intuition and data should balance each other. 11. Do not fake enthusiasm   I should transparently express what excites me about my product but also where we need to improve. Pretending will reduce credibility over time. 12. Do not compromise ethics Pressures may emerge to cut corners, but I must uphold integrity even when inconvenient. My team is looking up to me. 13. Do not get too comfortable The most dangerous place is my comfort zone. I need to continuously push into unknown territory, avoiding stagnation.  14. Do not disconnect from user struggles As my product grows, it’s easier lose touch with real customer problems. Staying connected to users’ “why” matters most. 15. Do not define success too narrowly    While vanity metrics have their place, I must focus on "who" this product helps and how. That is how lasting value is created. -- What resonates or needs refinement? Let's keep honing these guideposts together.

Honesty and directness are two of the most valuable traits in any workplace, yet I feel we are losing them...or losing the skill behind them. While many people are avoiding directness for fear of causing discomfort, others dive into “telling it like it is” without the tact and empathy that make honest feedback constructive. Somewhere along the line, these important qualities got tangled up with conflict or insensitivity, making many people shy away from direct feedback or honest opinions. It's important to recognize that: 💡 People often seek reassurance or pity, but what they often need most is honesty and directness. ⚠️ And if we don't recognize this and we lose honesty and directness, we lose the foundation for trust and growth. ⚡ Empathy and kindness are crucial at work, but they shouldn’t come at the expense of clarity and truth. We need to show people we value them by delivering the truth with empathy and respect. When we do this, we also impact efficiency. Instead of tiptoeing around issues, we can address them, find solutions, and move forward. Problems that might have lingered for months can be addressed in a single, honest conversation. There is no need to choose between being direct and being empathetic! It’s about combining the two thoughtfully. ✔️ Take a moment to notice your own emotion and consider how your words and tone will be received ✔️ Be conscious of tact, timing and empathy ✔️ Be specific and constructive..."I've noticed (specific issue) and I'd like to chat about what we can do about it" ✔️ Focus on the issue not the person ✔️ Encourage people to give YOU constructive feedback...and highlight that it goes both ways ✔️ Stick to facts, not opinions. And be clear on the impact before seeking solutions. Change starts with LEADERS! Research from Edelman’s Trust Barometer shows that transparency and honesty are top drivers of trust in leadership, with 84% of respondents saying that open and honest communication from leaders builds trust. We are all leaders in some respect so we can all ask ourselves...am I being direct and honest enough with the people around me? The people I care about? ❓ What are your thoughts on the topic ❓ How can leaders strike the right balance between honesty and empathy to build a culture of trust ❓ What’s one approach that’s worked well for you ❓ Leave your comments below 🙏 #trust #respect #openness #honesty #leadership #teamwork

When I started my career as a young enthusiast chemical engineer, everything was tangible. Clear. Measurable. Structured. And for a while, that was ok. But as I moved into leadership, I learned: → The higher you go, the less success depends on technical skill and the more it depends on emotional clarity. You don’t grow by being the best engineer. You grow by being the person others trust to lead. If you want to lead people, you must see their potential,  not just their performance. If you want to drive change, you must communicate clearly,  calmly and consistently. If you want to scale impact, you must be seen not for attention,  but for alignment. Most engineers are humble and amazing people. They let their work speak for them. But results don’t speak. People do. And people follow what they feel. Leadership isn’t just a shift in skills. It’s a shift in self-perception. From silent contributor → thoughtful communicator. From task-focused → purpose-driven. From reactive → reflective. It doesn’t happen overnight. But it can happen with intention, patience, and self-awareness. The real question is: Are you ready to lead from who you are, not just what you know?

Upskilling Strategies: Yesterday we looked at the Upskilling for business success and today we're going to look at customizing learning pathways for your Tech team. In today’s tech landscape, a one-size-fits-all approach to training just doesn’t work. To build a high-performing, future-ready tech team, upskilling programs need to be personalized and role-specific. 🔍 Start by assessing your team’s current skills: Use skills assessments, 360-degree feedback, and project performance reviews to understand the strengths and gaps within your tech teams. 🔑 Tailor learning pathways to meet the needs of specific roles within your organization. A few examples: ·       Cloud Engineers can benefit from certifications and training in platforms like AWS, Microsoft Azure, or Google Cloud. ·       DevOps Teams should focus on tools like Docker, Kubernetes, Jenkins, and CI/CD pipelines to streamline workflows and improve collaboration. ·       Cybersecurity Specialists need continuous learning in threat detection, encryption, and certifications like CISSP or CEH. ·       Software Developers could advance their skills in languages like Python or Java, or explore microservices and API development. 🎯 Personalization matters. When you align learning paths with individual roles and career goals, your team is more engaged and motivated, and the impact of upskilling is much greater. To create a successful upskilling strategy: ·       Set clear development goals based on current and future business needs. ·       Leverage e-learning platforms that offer customizable learning paths and assessments. ·       Encourage mentorship and peer learning to reinforce new skills within the team. ·       Investing in personalized learning paths doesn’t just future-proof your workforce—it drives innovation, improves retention, and keeps your tech teams agile and ready for the challenges ahead. Are your upskilling programs tailored to the unique needs of your tech team? #upskilling #personalizedlearning #techtrends #cloudengineering #DevOps #cybersecurity #continuouslearning #workforcedevelopment

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.

I have spent the past weeks in Silicon Valley meeting investors, researchers, and entrepreneurs. It is clear that the center of gravity in AI is shifting again. A new operating model is emerging. You see it in the pace of frontier innovation, the billion-dollar seed valuations of agentic AI startups, and the teams building systems that can think, act, coordinate, and improve. Inside global enterprises, the pattern is consistent. AI adoption is broad, but value is still shallow. The bottleneck is no longer the model. It is execution. This came up again in a recent conversation with Andrew Ng. The value of large language models is real, measurable, and accelerating. The question is no longer “Does AI work?” The question is “Can your organization adapt fast enough to capture the value?” And the hard part is not the tool. It is the team. Forward-Deployed Engineers The highest-performing companies are investing in a new capability: the Forward-Deployed Engineer. Demand has grown by 800 percent this year, and the impact is significant. A Forward-Deployed Engineer is neither a software engineer, a consultant, nor a solutions architect. It is a technical expert who sits inside the workflow, works with real data, prototypes fast, deploys in production, and translates business needs into engineered systems. This is the talent stack behind the agentic enterprise. The Rise of Agentic AI Research from Google and Microsoft makes the shift clear. We are moving from tools to systems that can reason, act, observe, and improve. Agentic AI is not automating deterministic workflows. It is moving into open-ended roles that require evaluation, judgment, and adaptation. This is the beginning of AI augmenting managerial, analytical, and decision-oriented work. And this is why AI is no longer a technology project. It is an organizational design challenge. The winning organizations in the next decade will not be the ones with the most AI. They will be the ones who can orchestrate intelligence, human and machine, into coherent systems of execution. AI is no longer the advantage. Execution is.