Scaling Tech Teams, Avoiding the Sunk Cost Trap, and Leading with Systems Thinking
In the world of software engineering, much attention is given to frameworks, tools, and productivity hacks. But beyond the surface lies a more enduring challenge: how to design, lead, and scale teams that deliver value consistently, while remaining resilient in the face of change.
Whether you’re leading a team of 10 or 300, the challenges don’t just multiply; they shift in nature. And the answers lie not in micromanagement or metrics dashboards, but in systems thinking, organizational design, and a deep understanding of human motivation.
Here are some core principles that shape modern, effective engineering leadership.
Think in Systems, Not Silos
Organizations are complex systems made of humans. Yet too often, leaders try to optimize individual teams or roles in isolation, hoping the whole will magically improve. Guess what? It doesn’t.
Leadership at scale requires designing the organization the same way one would design good software: with high cohesion, low coupling, and well-defined interfaces. This includes clear responsibilities, autonomous teams, intentional communication flows, and a shared understanding of how each part contributes to the whole.
It’s not about rigid control — it’s about architectural clarity. The most successful leaders are those who treat the organization as a living system, not just a reporting hierarchy.
Don’t Build a Shiny Cog in a Rusty Machine
Even the most high-performing team will struggle if the environment around them isn’t designed to support their success. A brilliant backend team can’t deliver outcomes if product leadership is disconnected. A streamlined deployment pipeline is useless if go-to-market alignment is broken.
Optimizing locally without fixing broken interfaces with the rest of the org leads to what I consider a “shiny cog in a rusty machine”, a technically excellent team delivering minimal business impact.
To scale effectively, leadership must focus just as much on cross-functional conditions as on internal team dynamics.
Remote Work Needs Deliberate Architecture
Remote work is here to stay. But simply declaring a company “remote-friendly” doesn’t make it functional.
While remote setups often boost focus and autonomy, they also reduce osmosis, serendipity, and shared context, especially for early-career professionals or newly-formed teams.
The solution isn’t swinging blindly between “remote-only” and “back-to-office.” Instead, it’s about deliberately designing when and how face-to-face interactions matter — for example, kickoff workshops, quarterly summits, or critical alignment phases.
Remote work works well, but only when designed well.
Be Wary of the Obsession with Individual Metrics
Leadership often seeks simple answers to complex questions. And nowhere is this more damaging than in attempts to measure individual engineer performance.
Lines of code, story points closed, or pull request frequency are seductive numbers. However, they rarely reflect true contribution, and often penalize those doing the hardest work: enabling others, resolving ambiguity, mentoring teammates, challenging flawed assumptions, and thinking.
Effective leaders know that:
Team-level metrics are where delivery success lives (DORA metrics, lead time, change failure rate).
Individual development should be evaluated through competency frameworks, coaching conversations, and growth trajectories, not arbitrary throughput stats.
Measuring contribution is important. Reducing it to a single number is a mistake.
Assumptions Decay, Revisit Them Often
Many projects begin with strong intent but crumble over time because the original assumptions silently become invalid.
Perhaps a customer request no longer exists. Perhaps a dependency is no longer relevant. Perhaps a key engineer has left. Yet the project rolls on, powered by inertia and status reports rather than real business sense.
This is the sunk cost fallacy at work, and it’s a hidden killer of engineering ROI.
The antidote is not just “agility”, it’s deliberate assumption management. At every phase of work, teams should:
Make assumptions explicit
Periodically review and challenge them
Be empowered to stop, pivot, or reframe efforts when context changes
Revisiting assumptions isn’t a sign of weakness. It’s a sign of operational intelligence.
Psychological Safety Is a Strategic Asset
To encourage experimentation, rapid learning, and honest retrospectives, teams need psychological safety, the belief that mistakes can be admitted without fear.
But psychological safety isn’t just a team issue. It starts at the top.
If leaders themselves aren’t safe, if they fear being blamed, overridden, or publicly contradicted, they’ll pass that fear downward. And the result will be a culture of silent failure and brittle decision-making.
Building a culture that tolerates course corrections, uncertainty, and humility isn’t soft — it’s foundational to adaptability.
The Role of AI: Raising the Floor, Not Replacing the Craft
With AI now able to generate code, write tests, and scaffold full applications, many wonder what’s left for engineers.
The answer? Everything that matters.
AI is excellent at accelerating implementation. But it cannot define the right problem, design resilient systems, or align technical decisions to business strategy. Not yet, and perhaps not ever.
The future of engineering isn’t typing less, it’s thinking more. It’s about defining better problems, making sharper trade-offs, and ensuring that every line of AI-assisted output contributes meaningfully to real outcomes.
Engineers may become less like builders and more like architects, curators, and reviewers. That shift will require new practices, but also a renewed focus on clarity, domain expertise, and strategic alignment.
Modern Leadership Is a Craft, Treat It That Way
Scaling an engineering team isn’t about applying templates or copying what worked at another company. Every org is different. Every system has its own constraints.
But some principles endure:
Design your org like a system
Empower teams with autonomy and context
Kill assumptions early, and revisit them often
Measure what matters, not what’s easy
Build psychological safety before you need it
Use tools like AI to elevate, not eliminate, craftsmanship
And perhaps most importantly: treat leadership as a craft. Not a checklist. Not a race. But a discipline worth studying, evolving, and practicing every day.