Practical Guidance for Engineering Leaders

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.

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.

You’re an engineering leader, a staff+ engineer, or a product owner who sees the cost of technical debt every day. But when you try to advocate for time to fix it, execs either nod vaguely or change the subject. You’re not wrong—you’re just not being heard. Here’s why that happens: When you say "tech debt," they hear "not urgent." When you say "refactor," they hear "money pit." When you say "architecture," they hear "someone else’s problem." But the reality is: Tech debt slows down your ability to ship new features. It increases the risk of outages or missed SLAs. It silently drives away your best engineers. So how do you make them care? I coach engineering and product leaders on how to frame technical priorities in business language—so they get the time, resources, and executive backing they need. Here’s the approach: Tie tech debt to business risk or cost: "This feature now takes 3x longer to ship because of X." Use executive language: Talk time-to-market, reliability, developer retention—not code quality. Frame it as an investment: "Fixing this sets us up for velocity in Q3." Make tradeoffs visible: "If we don’t fix this now, we’ll miss Y opportunity." Track real pain: Show data on cycle time, error rates, or turnover. Don’t wait for permission. If your leadership still sees tech debt as an engineering problem, it’s time to change the story you’re telling. This is where I come in. I help technical leaders communicate with power—bridging the gap between strategy and systems. Whether through coaching or fractional partnership, let’s get your org moving faster and smarter. #technicalleadership #engineeringmanagement #productstrategy #executivecommunication #startupgrowth

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

My honest advice after coaching senior engineers: 1/ Stop waiting for permission. Tech leadership isn't a title - it's taking ownership when nobody asked you to. See a problem? Write the proposal. Team confused? Create the doc. Junior struggling? Start mentoring. 2/ Master the "leverage equation." Focus on multiplying others' impact. One framework I teach: "See it, Frame it, Fix it, Teach it." Identify patterns across the team, create solutions that scale, then enable others to execute. 3/ Get comfortable being uncomfortable. You'll facilitate meetings without all the answers. You'll make decisions with 70% information. You'll have difficult conversations about performance. The script that changed everything for me: "I noticed X happening. I'd like to own fixing it. Here's my plan..." Your manager might not support you. Start anyway. Most seniors have the skills. They lack the confidence to step up without an invitation. Don't wait.

The mark of a good leader is how the team functions in their absence. - Some leaders leave behind a team that struggles—systems and workflows are heavily reliant on their presence, causing productivity dips and frustration. - Others leave behind a team that continues to thrive. While the team may miss their contributions, they are fully equipped and empowered to operate seamlessly. The difference lies in mindset. Good Leaders: - Focus on mentoring and growing the team, not just solving problems themselves. - Build systems that are resilient and documented, minimizing dependency on individuals. - Encourage knowledge-sharing to ensure no critical information is siloed. - Regularly assess workflows, empowering others to take ownership and innovate. It’s about shifting from being indispensable to making the team indispensable. This lesson took me time to learn, but it’s now one of the first things I teach mentees—helping new grads grow into high-performing engineers in just a few years. #Leadership #Mentorship #EngineeringExcellence #TeamResilience #GrowthMindset #TeamBuilding #KnowledgeSharing

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

Stop pretending you're still technical. Every leadership book tells you the same thing. Let go. Delegate. Step back. That's terrible advice. I've watched engineering leaders follow that playbook. They stop touching code. They stop reviewing architecture. Then they wonder why their teams stop trusting them. You don't earn credibility with engineers by sitting in strategy meetings. You earn it by proving you still understand the craft. Not by doing their job. By knowing enough to ask the right questions when something smells wrong. I still read pull requests. Not to approve them. To understand what my teams are solving and how they're thinking about it. I still prototype. Not to ship. To pressure test whether the thing I'm about to promise a VP is even possible in the timeframe. The other week a "bug" came in. Instead of shielding my team and deflecting to production support, I dove in. Checked the logs. Found a data issue. Fixed the customer experience in 30 minutes instead of letting it sit in an incident queue for days. The moment I stop understanding how our systems break, I lose the ability to make good decisions about them. The best engineering leaders I've worked with never stopped being engineers. They stopped shipping code and started shipping decisions. But they never lost the ability to understand what ships. The day you stop building is the day you start guessing.

10 tips from my book "Leading Effective Engineering Teams" I recently announced my new book "Leading Effective Engineering Teams"! After leading engineering teams at scale and seeing what works, I wanted to share just a few of the ideas from the book that could help others. Build psychological safety - Our research in Google's "Project Aristotle" revealed this as the #1 predictor of team success. I share specific techniques to build environments where engineers feel safe to take risks and innovate. Empower without micromanaging - I've seen firsthand how trust and autonomy drive 3x better outcomes. I outline my framework for setting clear guardrails while giving teams the space to own solutions. Scale your effectiveness systematically - I present my 3 E's model (Enable, Empower, Expand) for scaling team effectiveness from the ground up, based on proven patterns from Google. Foster clear communication - Drawing from thousands of 1:1s and team meetings, I provide strategies that have consistently improved team alignment and execution. Define clear success metrics in terms of outcomes (e.g. how does the work help users and the business) vs. outputs - I share the OKR frameworks we used at Google to measurably boost team effectiveness by 23%. Prioritize career development - I share more about a GROW model I've refined over years of mentoring engineers into successful tech leaders. Structure for innovation - Learn the specific organizational patterns that enabled my teams at Google to consistently ship breakthrough features. Lead with data - I reveal the key metrics and dashboards I've found most valuable for making better decisions and driving continuous improvement. Balance technical and leadership skills - Based on my journey from engineer to leader, I provide a roadmap for developing both technical depth and leadership breadth. Proactively feed opportunities and starve the problems - I share my framework for identifying and nurturing high-impact opportunities while preventing issues before they arise. The book includes real case studies, practical templates, and concrete techniques from my experience leading teams at Google. I wrote this to help engineering leaders at all levels build more effective, impactful teams. I hope the tips and book are helpful in some way! 🔗 Available now: https://lnkd.in/gVVQSwZr #programming #softwarenengineering #leadership

Advice for engineering leaders building AI-native engineering teams. 1. Don't focus too much on code generation and metrics like lines of code produced by AI Instead, look for the real bottlenecks, as more code won’t solve the problem. The bottleneck might be code review, planning, or system design, especially as engineers become much more productive. 2. Let engineers experiment Give teams a generous, sometimes unlimited, token budget and the freedom to experiment. Encourage people to explore without pressure or fixed expectations about what success should look like. Where this breaks down is when leadership has a very rigid idea of how AI should be used and forces that approach onto teams. 3. Look for people who are excited about AI Do you already have people who are excited about AI and noticeably more productive? If so, help them spread what they’re learning. Create space for sharing: internal hackathons, demo sessions, and dedicated channels where people can exchange tips and workflows. 4. Stay close to technical details As a leader, it’s more important than ever to stay close to the technical details. At the same time, it’s critical to empower your team to make decisions. That means optimizing how decisions get made: clear ownership, clear escalation paths, and minimal friction. To learn more, read this Engineering Leadership article: https://lnkd.in/d5ambTDW