Are your engineering teams busy but not productive? Do you feel like you're constantly pouring resources into improving developer experience, only to see the same bottlenecks and frustrations persist? This is a common struggle, and it often stems from a fundamental disconnect between how leaders think engineering works and how it actually works.
Thanos Diacakis, a fractional CTO and engineering coach, has spent his career diagnosing these disconnects. According to him, the solution isn't just another tool or process; it's about adopting a new set of mental models. This article explores Diacakis’s key frameworks for identifying bottlenecks, reframing technical debt, and using metrics to build happier, more effective teams.
Investing in technical debt
One of the most common challenges is a misaligned mental model between technical and non-technical stakeholders. As Diacakis explains, "One of the most common things that I see is people outside engineering think of engineering as some kind of feature factory. I put engineers in the process. I give dollars to hire engineers, and I get features out the other door."
This "feature factory" mentality fails to account for the full spectrum of work engineers perform. In reality, engineering work encompasses four distinct types of activities, described in the Flow Framework:
- Features - New capabilities for users
- Bug fixes - Addressing defects in existing features
- Investments - Improving tools, processes, and capabilities
- Risk management - Addressing security, compliance, and operational concerns
When teams over-emphasize features, problems arise. Allowing bugs to accumulate leads to customer complaints; neglecting investments slows productivity; and failing to address risks exposes the organization to serious operational failures.
Diacakis advocates reframing technical debt as a positive investment in future productivity. "I don't really like [the term] tech debt," he says. "I think of it more as investments. You have to invest in your team, whether this is the processes, the tools, technologies that you use, cleanups, refactorings. All of these things... will help you go faster in the future."
He draws an illuminating comparison to bridge building to highlight the double standard in software: "When you go and you build a bridge, you're going to do some design up front... In software engineering, somehow we tend to skip that sometimes." These so-called "shortcuts," he notes, are rarely shortcuts in practice, as their negative consequences often become apparent almost immediately.
Focusing on one bottleneck at a time
When trying to improve performance, many teams mistakenly try to fix too many problems at once. Diacakis recommends focusing on one constraint at a time. "If you improve to the left of the bottleneck, you're going to jam that machine... And if you improve to the right... they're going to be starved for work."
This principle, from the Theory of Constraints, suggests that improving any part of the system except the bottleneck won't improve overall throughput. Diacakis advises teams to identify what is acting as the bottleneck and focus all their efforts there, warning that spreading efforts too thin leads to a loss of focus. A common bottleneck is overplanning—teams often stuff 30 items into a sprint but complete only five, creating unnecessary context switching and diminished morale.
Building the foundation for predictability
Diacakis outlines a four-phase approach to engineering improvement that builds progressively:
- Iterations - Establish the ability to go from idea to deployed software quickly, with proper tooling like linters, CI/CD pipelines, and automated tests.
- Quality - Once iterations are established, focus on ensuring that customer usage matches expectations, metrics are accurate, and feedback loops are functioning.
- Complexity Management - Address architectural, team, and procedural complexity that accumulates over time.
- Planning and Predictability - Only after the first three phases are solid can teams realistically plan beyond the immediate term.
The progression is somewhat linear, but organizations may need to jump back and forth depending on their maturity and specific challenges.
"A lot of people try to reach for [planning and predictability] first," he notes. "But if you couldn't plan a sprint... you're not gonna be able to plan a six months or a year ahead."
Using metrics as debugging tools
When it comes to metrics, Diacakis offers a refreshing perspective. Rather than seeing them as punitive, he views them as debugging tools to improve processes.
"I often say, make metrics that people want to game," he explains. "Because you make a metric because you want to affect behavior. And if the question is, 'what if people game it?' It's like, 'well, game it. That's what I want. I want this metric to move.'"
He cautions, however, that using metrics to punish individuals erodes trust and discourages engagement. The most effective metrics support cultural changes and help teams eliminate entire categories of errors through better processes.
From friction to flow
The path to a high-performing engineering culture isn't paved with more features or faster code generation. As Thanos Diacakis illustrates, it’s built on a foundation of shared understanding and systemic thinking. It requires moving past the "feature factory" mentality to see the whole system—balancing new work with the crucial investments, bug fixes, and risk management that sustain long-term velocity.
By identifying and resolving one bottleneck at a time, you create focused, measurable progress. By treating metrics as debugging tools instead of punitive weapons, you build trust. And by reframing tech debt as a necessary investment, you empower your teams to build for the future. Ultimately, these mental models work together to create an environment where engineers can do their best work, leading not only to better products but to happier, more resilient teams.
Listen to Thanos Diacakis' Dev Interrupted episode:
