Empowering Engineering Teams

 Is your team stuck in silos, moving like a factory assembly line? 🏭 There's a better way. In Tech Lead Journal episode #224, experienced CPTO Klaus Breyer shares an interdisciplinary approach to building truly high-performing teams. His core insight? We're treating software engineering like manufacturing when it's actually a design process. This fundamental misunderstanding is why: • Agile and Scrum has become a micromanagement tool • Ticketing systems create communication silos • Teams build solutions instead of solving problems Klaus introduced a revolutionary approach: "Move Fast, Break Silos." Here's what resonated most with me: ⤷ Slice work differently Not just into tasks, but into objectives → problems → solutions → delivery. Give teams problems to solve, not just tickets to close. ⤷ Empower small teams Dynamic groups of 2-3 people work best. They own their outcomes, not just their output. ⤷ Break the conveyor belt mindset Software development is creative problem-solving, not assembly line work. Stop treating engineers like factory workers. The most powerful takeaway? When you align small, empowered teams with real customer problems, they don't just ship features—they deliver value. Watch the full episode to discover how to transform your team from a ticket-processing factory into a high-performing, problem-solving team. --- ❓ What's your experience with breaking down silos in your organization?

Two of my strongest engineers disagreed on a solution to a critical project, and the most important thing I did as their manager was stay out of it. Yes, one of the best launches on my team came from a disagreement I refused to interrupt. I remember a case where two strong engineers on my team were working through a system design decision, and both had very different instincts on how we should build it. One wanted a scalable architecture approach that would serve us well over time. The other wanted a simpler path that would get us into production faster and reduce delivery risk in the short term. Both had good reasons. Both cared about the system. Both were convinced they were protecting the team from a bad decision. This is usually the moment where a manager feels tempted to step in, make the call, and move everybody forward. Instead, I chose a different route. I brought both of them together and made the discussion concrete. I defined the success criteria clearly: the system had to meet the launch timeline, stay within acceptable operational overhead, and leave us room to evolve once usage grew. Then I stepped back and asked them to work from those constraints instead of arguing from personal preference. What happened next was better than what I would have produced by forcing a decision from above. 1) They stopped defending positions and started solving for the goal. 2) One borrowed the stronger scalability ideas from the long-term design. The other kept the implementation grounded enough for the team to ship without creating unnecessary risk. What they built was a hybrid solution, and it was better than either original proposal on its own. Empowerment is not giving people space and then taking it back the moment there is friction between them. True Empowerment is creating clarity, setting standards, and trusting capable people to do the thinking. As managers, we add the most value when we shape the frame well: - What does success look like? - What constraints matter most? - What tradeoffs are acceptable? Once that is clear, the room often does the rest.

If I had to pick a single litmus test for a strong product culture, it would be this: Are your product teams consistently prioritizing solution ideas that came from engineers? Marty Cagan has called an empowered engineer “the most important thing” for a team that wants to innovate consistently: engineers know better than anyone else what’s just now possible with technology. I'd add that the existence of empowered engineers is also *the* best diagnostic for whether you’ve fully embraced the product operating model.  Why? Because you don't get empowered engineers unless you're doing pretty much everything else right. Your product leaders have created, and effectively communicated, the strategic context (vision + strategy + OKRs) that both inspires the team and focuses them on the most important problems.  Nobody is dictating a roadmap: the team is given problems to solve, not features to build. Your PMs and designers are truly collaborating with engineers in discovery. And your engineers understand your customers and users at a deep level. The mindset shift, and the corresponding changes in habits, are often significant. It means expecting and enabling engineers not just to deliver quality code with velocity, but also to act as key partners in figuring out what to build in the first place. If I had to recommend one thing to catalyze this change: get at least one engineer into your customer discovery conversations. I've worked with several clients to implement this small step, which can literally happen overnight — invite the engineer! In one case, we had a senior engineer who'd been in order-taker mode join customer calls alongside the PM and designer. The shift was immediate: motivation changed, ideas started flowing, and that engineer went from executing specs to truly collaborating as a trio with his PM and Designer. As long as you've chosen an engineer who's curious about customers — and sometimes even if they're skeptical at first — I've yet to see this fail to shift the dynamic. Having an engineer in customer conversations does several things at once: • It signals that you *want* engineers to be empowered. Otherwise, why would you be spending their valuable time talking to customers versus writing code? • It dramatically accelerates their understanding of, and empathy for, customer problems. When problems are experienced firsthand, solution ideas come fast. • Sprint planning shifts from "we're skeptical about what product is telling us to build" to "we know these priorities were informed by, if not inspired by, an engineer." • Specs get better — since engineering has been involved upstream — which speeds up delivery. What's your litmus test for a strong product culture?

Great engineering teams don't just happen, they're built intentionally. Over my years as an engineering leader, I've found one truth that stands out: The best leaders multiply the capabilities of their teams. It’s tempting for leaders, especially those with deep technical backgrounds, to dive into the weeds and solve problems directly. But true leadership isn't about doing, it’s about empowering. When leaders consistently step in to fix issues themselves, they inadvertently cap the growth of their team. Instead, great leadership involves setting clear expectations, providing the right resources, and then stepping back to allow your team the space to succeed (and occasionally fail). When your team knows you're there to support, not micromanage, trust flourishes, innovation thrives, and individuals grow faster than ever. Actionable takeaway: If you're leading a team, pause before jumping in to solve every issue. Ask yourself: - Am I providing clarity rather than just solutions? - Am I building independence or dependence? Empower your team today, and watch them elevate tomorrow. I'd love to hear your thoughts, how do you multiply your team's capabilities?

If you’re leading a large team or overseeing multiple products, you quickly realize that staying on top of every decision is a near-impossible task. As a data science leader, I’ve learned that trying to manage all the tactical decisions myself only led to one outcome: I became the bottleneck. I’ve made that mistake. During high-pressure moments or tight deadlines, there are times when you may need to lean in and take charge—but making that your standard approach will only lead to two things: you’ll slow the team down, and you’ll put yourself under tremendous stress. The key to avoiding this? Empower your team to make decisions. When I recognized that trying to control every detail was hurting performance, I made a shift. Instead of being involved in every tactical decision, I focused on identifying the right people with the skills and context to handle the day-to-day responsibilities. I laid out clear milestones and checkpoints, along with the criteria for success, but I gave them the autonomy to execute the work. This way, I was able to offer critical feedback at key moments without micromanaging the process. It created space for learning, even failure at times, but in a way that allowed the team to grow while staying on track. Empowering your team to take ownership not only improves performance, but also helps cultivate an environment of trust and accountability. And as a leader, you taking a step back frees up time to focus on the bigger picture. Have you experienced a moment when empowering your team made all the difference? I’d love to hear your thoughts. #LeadershipLessons #TeamEmpowerment #DataScienceLeadership #DecisionMaking #AILeadership

The promise of empowerment feels empty until your team don’t need your green light. Most teams don’t feel empowered. They’re often left to “figure out the details”  on a solution someone else already picked. Want to empower your team? Give them problems not tasks. Here’s the mandate shift that matters: 🔻 “Build this exact feature.”  🔻 “Implement something that does X.”  🔻 “Let users complete Y task.” ✅ “Solve this customer pain point.”  ✅ “Improve this outcome for consumer A.”  ✅ “Move this metric that drives revenue.” The first three tell teams what to build.  The last three trust them to discover how. And that trust? It only works when your team has: 🧭 Context that matters: They understand why this problem is a priority not just what needs to be done. 🛠 Support to succeed: They’re not thrown into the deep end. They have the tools, time, and coaching  to figure things out. 📊 A shared definition of done: They know what success looks like and how progress will be recognized, not just measured. 💬 Room to try without fear: They can test ideas without worrying they’ll look foolish, get blamed, or lose trust. If something flops, it’s a lesson, not a career risk. What does “empowerment” actually look like on your team? ♻️ Repost to help others spot performative empowerment. 🔔 Follow Justin Hills for practical leadership insights.