Developing a Leadership Mindset in Engineering

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

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.

9 out of 10 engineering leaders reverse their emotional intelligence at the worst possible moment. They micromanage when teams need space. They vanish when teams need technical leadership. The pattern shows up everywhere: The VP who rewrites code during sprint planning but goes silent when production burns. The engineering director who can't let teams architect solutions but disappears during crisis calls. This costs you everything: Your best engineers leave because they can't grow, then watch you vanish when things break. Your team's trust erodes. Your credibility becomes situational incompetence. Here's what changed my understanding completely: 3 AM. Huge retail client's entire payment system crashes during their biggest sales day. $50K bleeding per hour. Team paralyzed. Junior developer hyperventilating. Senior architect stuck in analysis paralysis for 2 hours. As Solutions Architect, I had a choice: Stay in my "leadership lane" and coach from the sidelines. Or violate every management book and dive into the code myself. I grabbed my laptop. Found the database deadlock in 20 minutes that they'd missed for hours. System restored. Revenue bleeding stopped. Client saved their biggest sales day. But the real impact wasn't the fix. The team watched a leader step in without blame during the moment that mattered most. That night taught me the framework that separates adaptive leaders from rigid ones: Your emotional intelligence requirements flip based on the situation. Same leader. Completely different EQ skills. CRISIS MODE - Lead from the front: ↳ Self-awareness: Recognize when your technical skills matter more than your title ↳ Humility: Code-level problem-solving regardless of organizational chart ↳ Ego management: Solution over status, every single time ↳ Calm under pressure: Your stress becomes their panic - manage it ↳ Technical empathy: Feel the weight of what your engineers are carrying NORMAL OPERATIONS - Lead from the back: ↳ Trust: Your team solves it better when you're not hovering ↳ Patience: Growth happens slower than your impatience wants ↳ Restraint: Keep your hands off the keyboard when fingers itch ↳ Active listening: Hear the problems they're not saying out loud ↳ Psychological safety: Failure becomes learning when you're not judging ↳ Empowerment: Autonomy with availability, not abandonment Get this right: teams innovate fearlessly and execute flawlessly under pressure. Get this wrong: teams stagnate during calm and collapse during crisis. Your comfort zone isn't what your situation requires. Crisis demands technical courage. Innovation demands emotional maturity. Before you step in today, ask yourself: Does this situation need my technical skills or my restraint? ♻️ Share this to your network. 🔔 Follow Dan Tudorache for leadership insights that match what your technical team actually needs right now.

You feel like you're hitting your career ceiling not because of your technical skills… But because you're waiting for permission to lead. You're excellent at what you do, and perhaps you've been waiting for a manager to notice your hard work and hand you a promotion. But no one notices. I used to think leadership was a title - that you were either an engineer or a manager. But after coaching hundreds of technical professionals, I've learned that leadership isn't a role; it's a mindset. It's the engine that drives your career forward, long after your technical skills alone have peaked. The truth is, you don't need a promotion to start leading. Leadership is about taking responsibility for more than just your own tasks. It's about thinking strategically, communicating clearly, and caring deeply about the people you work with. If you’re ready to start leading from where you are today, here are some things you can do right now: - Offer to mentor a junior engineer. - Take the initiative to improve a process that's frustrating your team. - Practice listening more than you talk in meetings. - Have a difficult but necessary conversation no one else wants to start. These small actions build the muscles of leadership. They show people you're not just a problem-solver, you're a leader. And people who act like leaders... become leaders. The next time you're at work, ask yourself: "What's the next leadership action I can take right now?" You might be surprised at how quickly things shift. Want help with the shift? DM me and let’s talk!

Here's the leadership strategy that propelled me to Principal Engineer at Google: "I push rocks down hills." This is the pithiest summary of Principal Engineer-ing that I've come up with, and it's a major part of how I approach exec-level engineering leadership. Moving up the career ladder as an engineer is about finding leverage: ways to produce more value per unit of time. You can grow your skills so you can handle harder projects and finish them faster. You can improve your judgment so you identify opportunities that produce more value for the effort. You can lead teams, so your skills and judgment get magnified across more contributors. One way to magnify your output as a leader is by turning a hard problem into an easy problem. Something I've observed over time is that it's a lot more challenging to start a project than to keep a project moving in the same direction. The first few commits, the project outline, the high-level architecture: these are the hardest and the most consequential challenges. Once the skeleton is in place, it's harder for a project to run off the rails. Starting projects is hard; maintaining that momentum is comparatively easy. This leads to the discipline of pushing rocks down hills. Your goal isn't to drive a project to completion; it's to impart enough momentum to the project that it will cross the finish line even if you stop paying attention to it. The goal is to build teams that don't need you. Don't build teams with yourself at the center: build teams with yourself on the outside. Once a problem is moving under its own momentum, it's no longer a high-leverage place to spend your time. You can move on. It's time to push a different rock down the hill. One consequence is that you will start more projects than you finish. Not because the projects *don't* finish, but because *you're* not the one driving them over the line. You need to have the humility to step back and give credit to the folks who finish the job. Scaling yourself means taking a smaller share of credit for a larger number of projects.

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?

The best engineering leaders I've worked with all had one thing in common. They treated the intern and the VP the same way. Not because they were naive about hierarchy. Because they understood something most leaders never learn. The way you treat people who can't do anything for you yet is the clearest signal of who you actually are as a leader. I've watched senior engineers talk over junior teammates in design reviews. Dismiss ideas without hearing them out. Reserve their best energy for the people above them and give everyone else whatever was left. And then wonder why their team had a retention problem. Here's what those leaders missed. The junior engineer you dismissed in today's meeting becomes the Staff engineer someone else develops and loses you to in three years. The teammate you talked over had the solution you spent two sprints trying to find. The culture you build when no one is evaluating you is the one your team lives in every single day. Respect isn't a reward you hand out based on titles and credentials. It's a standard you hold regardless of who's in the room. The engineers who become the leaders people actually want to work for don't wait until someone proves their worth. They lead with respect first. Every time. For everyone.

One of the most important lessons I’ve learned in leadership is that you don’t have to be the expert. In fact, often, not being the expert can be an advantage in pulling together a great team that delivers fantastic outcomes. For someone who has spent much of my life in engineering businesses, I have a rather unusual background - I’m not an engineer nor a distribution expert. My degree is in food sciences and agriculture, and I trained as an accountant. Before stepping into industry, I spent 12 years as an investment banker in London and New York. What this background has taught me is the value of building a diverse team and trusting them to deliver… whilst providing a bit of coaching along the way. I have never believed I could engineer anything better than the engineers I’ve had the privilege to work with, nor make better people judgements than the people team . Instead, my role has always been about facilitating success - creating an environment where diverse talent can work effectively together as an aligned team, allowing everyone to contribute by empowering them doing what they do best in pursuit of common objectives. In engineering and beyond, the key to success lies in empowering people. It’s about enabling teams to recognise and truly understand the needs of the customers they serve and to develop efficient and effective solutions to the problems they and other stakeholders face. As leaders, we don’t need to have all the answers. Our job is to make sure we create the right culture and ask the relevant questions, and then provide the space, resources and support to let talented individuals work effectively together to find the best solution. No matter your industry or discipline, success is never about the contribution of one person. It’s about trust, collaboration, and creating a space where everyone can contribute to their full potential. #Engineering #Leadership #Trust #WeAreRS

Your team just spent 9 months building a critical project. Right before launch, one engineer speaks up: "We can't ship this." Do you force the launch to save your ego, or pull the plug and face the executives? When Raffi Krikorian (now CTO of Mozilla) faced this exact scenario while working with Twitter's engineering team, he chose the hardest path. He didn't fire the engineer. He didn't force the code into production. Instead, he stood in front of the entire company, delivered a massive mea culpa, and took the blame to protect his team. What happened next is the ultimate lesson in leadership. Because Raffi provided that shield of psychological safety, his team didn't panic. They rose to the challenge. Free from the pressure of a forced launch, they were able to say: "Okay, we can keep this part, we trash that part, and we re-architect the rest." The result? They eventually shipped a system so resilient that when the massive traffic spikes of the World Cup hit Twitter, the platform didn't crash once. As Raffi said: "No one noticed." That moment fundamentally shifted how he viewed his role: "My job is not actually to be the architect. My job is to provide the framework, the vision, the protection, the funding, the people, and to make the environment so all these people can do the best job of their lives." The transition from expert to leader is painful. You have to stop building the product, and start building the environment. 🎧 Catch the full epsiode on leadership, trust, and scaling with Raffi on the Positive Leadership Podcast (link in the comments!). 💡 Question for you: How do you create an environment where your team feels safe enough to tell you a hard truth? 👇 #PositiveLeadership #Management #TechLeadership #PsychologicalSafety #GrowthMindset #Culture

I didn’t become a public speaker by accident, I stepped into it because I had something to say. As a chemical engineer, I was always comfortable contributing, whether that meant questioning assumptions in design reviews or challenging how decisions were being made. What I wasn’t comfortable with… was silence. The kind that hangs in rooms where people don’t feel safe to speak. Where brilliant ideas go unshared, and concerns stay buried beneath hierarchy or fear. Early on, I realised: engineering didn’t just need technical leadership, it needed human leadership. Voices. Values. Visibility. That’s what pushed me beyond the spreadsheets and process diagrams. Not to leave engineering, but to shape the culture around it. Over the years, I’ve spoken to thousands, on stages, in boardrooms, through workshops and mentoring. Always with the same mission. To make engineering safer, more inclusive, and more human. That’s what led to developing the SAFE Leader framework. Not as a theory, but as a tool, one rooted in practice, designed for engineers who want to lead with clarity, courage and compassion. Because using your voice in engineering shouldn’t feel radical. It should feel normal. __ What has your voice helped shift in your team, your culture, or your own mindset?