Managing through layers
On paper, I currently manage leaders and senior ICs representing about 25 engineers. The structure has shifted over time. A few years ago we were closer to 40, and there may be more adjustments ahead. I don't manage most developers directly; I manage the managers who lead those teams, so there is already a layer between me and the engineers.
I handle salary, vacation, performance reviews, and I help define engineering direction with the CTO, but operational details flow through my managers before they reach me. That alone adds complexity.
A matrix on top of that
On top of that internal layer, we operate in a matrix structure. Engineers sit under engineering as a discipline, but their work comes from the business units they are assigned to. Their backlog is driven by Product Owners, and validation of delivery happens on the business side.
The structure looks like this: business defines the work, managers coordinate execution, engineers deliver, and I remain accountable across the system. I don't assign daily tasks, yet I'm responsible for how the system performs.
Accountability without direct control
Even without controlling priorities directly, I am accountable for delivery. If a project slips or quality drops, it reflects on engineering, and if stakeholders are dissatisfied, that feedback eventually comes back to me.
I evaluate the performance of my managers and, indirectly, their teams, and a meaningful part of that signal comes from the business side: reliability, communication, ownership, and ability to navigate trade-offs. So I operate at a distance from the day-to-day work, but I'm accountable for both outcomes and people. That distance requires trust, clarity, and constant adjustment.
When engineering and business diverge
Misalignment usually appears around scope, timeline, or sustainability. Engineers focus on long-term maintainability and system health, while business stakeholders focus on commitments, customers, and revenue. Tension often starts at the team level and my managers handle most of it; I step in when alignment cannot be reached or when broader context is required.
In many cases, the issue is incomplete information. A fixed date may already have been promised, an external partner might be involved, or revenue may depend on shipping within a specific window. When those constraints become visible, the conversation shifts: trade-offs become explicit, scope can be reduced, delivery can be phased, and debt can be taken consciously rather than accidentally. Clarity doesn't remove pressure, but it makes decisions more deliberate.
Decision layers and friction
This system becomes heavier as more layers are introduced. There is already a layer between me and the engineers, and when additional decision makers are added above the business units, requirements travel through multiple intermediaries before reaching the team.
The person discussing the project may not have authority to change scope or timeline, so engineers can feel they are responding to abstractions rather than real constraints. Operating in that environment requires more translation and more patience.
Holding the balance
If pressure tilts too far toward business demands, engineering loses control of the codebase, maintenance slows down, and frustration builds. If it tilts too far toward engineering purity, the business struggles to move; a clean system without revenue does not sustain a team.
My role sits between those forces. Through my managers, I try to surface constraints, clarify trade-offs, and protect enough engineering integrity so the system remains healthy while the business can still deliver what it needs.
Accepting imperfection
I don't believe I handle every situation perfectly. Sometimes I fail to uncover the real constraint early enough, sometimes I push for more time and don't get it, and sometimes I have to come back to the team and say we will do it as requested. Those are not comfortable moments.
Other times, the conversation works: we gain a few weeks, we reduce scope, or we protect a piece of the system that would have been rushed. Over time, I've come to see this less as winning or losing and more as managing tension. The balance is not static; it shifts with context, leadership, revenue pressure, and the people involved.
My work is to keep that tension visible, avoid extremes, and make sure decisions are taken consciously rather than by accident. I don't control the whole system, but I work hard to keep it from drifting too far in one direction.
- Patrick