There is a familiar idea that as engineers move into leadership, they should gradually move away from the product. Their calendars fill with planning meetings, hiring conversations, performance reviews, status updates, and architecture discussions. Distance from implementation begins to look like evidence of seniority.
Some distance is necessary. A leader who remains involved in every technical decision will eventually become a constraint on the team. But distance from implementation should not become distance from the product itself.
Engineering leadership is a product role because the consequences of leadership ultimately appear in the product: what gets built, how well it works, how safely it operates, and whether it creates meaningful value.
I have learned this while leading engineering teams, building products, working in regulated environments, and founding FortyOne and Complexus. The contexts differ, but the underlying responsibility is consistent: turn the organisation's intent into a product that can be trusted.
That requires technical judgment, but it also requires product judgment, commercial awareness, communication, and a serious understanding of people.
The output changes
The transition into leadership can be disorienting because the work becomes less tangible.
An engineer can point to a feature or a difficult problem they solved. A leader's most important contribution may be a decision made earlier, a risk removed quietly, or enough clarity for someone else to do excellent work.
The output changes from personally producing most of the implementation to improving the conditions under which implementation happens. The team needs a clear problem, a sensible sequence of work, explicit ownership, appropriate standards, and honest communication about uncertainty.
This work can be difficult to measure because its value often appears through problems that do not happen. A team does not spend a quarter building the wrong capability. A security requirement is addressed before launch rather than after an incident. An engineer makes a strong decision without waiting for permission because the intent and boundaries were already clear.
A leader creates the conditions for good decisions to happen quickly across the team.
Start with the product problem
Engineering teams are naturally good at turning a request into a plan. That strength can become a weakness when planning begins before the problem has been understood.
A request such as “we need a dashboard,” “we need AI,” or “we need a mobile application” already contains an assumed solution. If engineering accepts it exactly as stated, the team may execute well while solving the wrong problem.
Before discussing architecture or effort, I find it useful to ask more basic questions. Who is experiencing the problem? What are they trying to accomplish? What happens today? What should become easier, safer, or more reliable? How will we know the change was useful?
These questions are the shared foundation of responsible product development. Engineering may know that a small workflow change creates most of the desired value, or that a proposal carries more operational risk than anyone realised. Bringing that information forward is part of the role.
Product, design, and engineering should work on the problem together, with each discipline contributing its own perspective instead of passing the work between functions.
Strategy must reach daily work
Organisations express strategy in broad language: improve retention, enter a market, reduce operating cost, or create a better experience. Teams work with requests, designs, stories, dependencies, and deadlines. Engineering leadership sits between those two levels.
A strategy is only useful when it influences everyday decisions. If a team cannot explain why its current work supports an important outcome, the connection between strategy and execution has weakened.
The leader connects the outcome the organisation wants to the problem preventing it, the product behaviour that could change it, and the work the team has chosen to do now. Without that line, a roadmap can look full while the product remains directionless.
Prioritisation is therefore an engineering concern. Reliability, accessibility, security, and maintenance compete for the same capacity as visible features. A leader should make those trade-offs legible. “We need to fix technical debt” is less useful than explaining which outcome is constrained, which risk is increasing, and why intervening now is worth the opportunity cost.
Quality is part of the product
Quality is sometimes framed as the thing engineering asks for while the business asks for speed. That framing overlooks the customer. A product that ships quickly but loses data, confuses its users, or creates recurring operational work has still delivered a poor experience.
Quality has to remain proportionate. A prototype designed to test demand needs less operational investment than a financial workflow that moves money. The appropriate standard depends on the consequence of failure, the maturity of the product, and how easily the decision can be reversed.
Engineering leadership therefore involves defining what “good” means for the situation. The standard should be deliberate rather than inherited from habit.
Useful speed combines delivery, learning, and the ability to keep moving without repeatedly paying for avoidable mistakes.
Strong foundations matter, but they should earn their place by making valuable work safer or easier. Otherwise, engineering can become very busy while the product stands still.
Stay close without taking over
Staying connected to the product does not require a leader to remain inside every implementation detail.
Constant involvement may feel helpful at first. Over time, however, it teaches the team that important judgment belongs somewhere else. People wait for reviews or avoid decisions that may be questioned later. The organisation gains consistency at the cost of ownership.
I prefer to stay close by using the product, participating in selected discovery conversations, reading customer feedback, reviewing important decisions before they become expensive, and looking carefully at incidents and recurring friction. This provides enough context to ask useful questions without taking the work away from the people closest to it.
There are moments when direct involvement is appropriate. The question is whether it increases the team's future capability or simply solves the immediate problem through authority.
When the same decision repeatedly requires the same leader, the team has developed a dependency.
Autonomy is designed
Leaders often say they want teams to take more ownership. Ownership cannot be requested into existence. It depends on whether people have the context, authority, capability, and safety required to act.
If priorities change without explanation or decisions are routinely overturned, waiting for permission becomes rational behaviour. Useful autonomy needs boundaries. A team should understand the outcome it owns, the decisions it can make independently, the standards that are non-negotiable, and the risks that require wider review.
When a leader delegates a task but prescribes every important decision, the team is still being controlled remotely.
Within those boundaries, leaders should leave genuine room for different approaches. A strong review tests whether the reasoning is sound and the result meets the agreed standard; it is not an opportunity to make the work resemble what the leader would have produced.
Teams scale when many people can exercise sound judgment in the same direction.
Delivery is a system
When delivery slows, the easiest response is to increase pressure. That can create short-term movement, but it rarely fixes the underlying system.
Sustainable delivery depends on the quality of intake, the size of work, the stability of priorities, the availability of decisions, the management of dependencies, and the amount already in progress.
Many problems that appear technical are actually problems of unclear ownership or unresolved expectations. A team may be described as slow when work entered development with an unanswered product question, or a deadline may be missed because several groups assumed someone else owned a dependency.
This is why I value short written decisions, explicit owners, clear success conditions, and visible trade-offs. Writing gives people who were not in the room a fair chance to understand the reasoning. Clarity is not bureaucracy; done well, it allows a team to move without asking the same questions repeatedly.
The interpersonal environment matters just as much. When people are afraid to challenge an assumption, risks remain hidden until they become failures. The strongest teams care about the work, communicate directly, and do not confuse urgency with chaos. That environment forms part of the product development system.
Leadership is visible in the product
My view of engineering leadership comes down to a few principles:
- Stay close to the problem. Distance from implementation should not become distance from customers or the product.
- Create clarity before urgency. Pressure cannot compensate for unresolved decisions.
- Make trade-offs visible. Every commitment consumes capacity and displaces another possibility.
- Match the standard to the consequence. Quality should be deliberate rather than performative.
- Build ownership, not dependence. The team should become more capable of making good decisions without the leader.
- Use technology in service of an outcome. Technical sophistication matters only when it helps create a better, safer, or more sustainable product.
These principles are simple to state and difficult to practise consistently. Real organisations contain competing priorities, incomplete information, commercial pressure, legacy decisions, and people with different perspectives. Leadership happens inside those conditions, not outside them.
An engineering leader may spend less time writing production code, but the product remains the clearest expression of the role. Can customers accomplish what they came to do? Does the system behave responsibly? Does the team understand why its work matters? Can people make decisions without waiting for a single authority?
Those outcomes are influenced by architecture and implementation, but also by priorities, standards, communication, trust, and decisions made long before development begins.
The work of engineering leadership is to turn strategy into shared understanding, shared understanding into responsible action, and responsible action into a product that earns people's trust.
That is why I consider engineering leadership a product role. Technology is one of its essential materials, but the responsibility is larger: helping an organisation decide well, build thoughtfully, and deliver something genuinely useful.