I have coached engineering leaders through a transition that derails technically strong people more often than almost any other: moving from being the person who solves hard technical problems to being the person who creates the conditions for others to solve them. (see also: how to develop strategic thinking skills)
The dynamic is common and rarely named directly. A technically strong leader gets promoted because they are the best engineer on the team. Their instinct in every technical discussion is to solve the problem themselves - because they can, and because it is faster in the moment. Six months in, the team has stopped developing technically because the leader is consistently in the way. The leader is exhausted. The team is frustrated. Nobody knows quite why.
The skill gap is not technical. It is about what you optimize for when you walk into a room.
Engineering rewards direct problem-solving. Leadership rewards building capability over time. The feedback loop is slower and the satisfaction is less immediate.
The Shift From Solving to Enabling
The hardest thing for technically strong leaders to accept is that the right answer to a technical question from a report is usually another question. Not because you do not know the answer. Because the goal is not to solve this problem - it is to develop a person who can solve this class of problem without you.
This requires a different kind of patience than most engineers have trained for. Engineering rewards direct problem-solving. Leadership rewards building capability over time. The feedback loop is slower and the satisfaction is less immediate. The leader who learns to find satisfaction in a team member's growing competence rather than in solving the problem themselves has made the transition. The one who has not will continue to be the bottleneck.
The practical test: when a direct report brings you a problem, do you primarily experience it as a problem to solve or as an opportunity to learn what they already know and where they are stuck? The first instinct reveals the orientation. The discipline is holding the second orientation even when the first is faster.
Influencing Without Authority
Technical leaders frequently need to shape decisions they do not control. An engineering leader working with a product team that is underestimating technical risk. A CTO trying to slow down a board that wants to move faster than the architecture supports. An engineering manager trying to get resources from a CFO who sees the team as a cost center.
The leaders I have seen do this well share one habit: they translate technical risk into business consequence before the conversation happens. Not 'this architecture decision will create technical debt' but 'this architecture decision will cost us six months of velocity in Q3 when we need to scale for the new market.' Same fact. Different framing. Different outcome. (see also: product risk management)
The framing shift is not spin. It is actually more accurate. Technical debt is an abstraction. Six months of velocity cost is concrete. The person you are trying to influence can evaluate the concrete version. They cannot do anything useful with the abstraction.
At TripAdvisor, the most effective technical leaders showed up to business conversations already speaking the language of the business. They had done the translation before the meeting. They were not asking product and business leaders to care about technical concerns in the abstract - they were showing them why this specific technical decision affected this specific business outcome.
What Strategic Thinking Looks Like in Engineering
Most technical leaders are good at solving the problem in front of them. Strategic thinking requires holding the current problem and the problem two years from now simultaneously - and making the current decision in a way that does not close off good options later.
Some of the most consequential technical decisions are made when a product is still small, before the scale implications are visible. The engineers making those decisions cannot know exactly what the product will need to handle later. But the ones who make better decisions are thinking about optionality - choosing approaches that keep future options open over approaches that optimize narrowly for the current state.
The question that develops strategic thinking in technical leaders: 'what does this decision make harder later?' Not 'what are the downsides' - that question produces a list. The strategic question forces engagement with the second-order consequences of a technical choice, which is where the real cost usually lives.
Building Technical Credibility Without Being the Technical Authority
There is a specific trap that technically excellent leaders fall into: they remain the technical authority on their team because they are genuinely the most capable person in the room, and this prevents the team from developing the technical depth it needs at scale.
The transition requires building credibility through judgment rather than through technical execution. A technical leader who can accurately assess which technical risks are real and which are theoretical, who can ask the right questions without needing to know the answer, and who can make a call on a difficult architectural decision with incomplete information - that leader has technical credibility that does not depend on being the most technically skilled person present.
This is a harder form of credibility to establish and a more durable one. It survives the team growing past you technically, which is the right outcome.
The Honest Conversation About Career Progression
Not every technically excellent person should become a technical leader, and the ones who should do not all want to. The career path that takes your best individual contributors and makes them managers is not the only path, and it is not always the right one.
The dual-track model - separate IC and management tracks with equivalent compensation and status - solves this in theory. In practice, it requires an organization that genuinely values senior IC contribution as much as it values management. The test is whether a Staff Engineer and an Engineering Manager at the same nominal level are treated as equivalent in practice - in whose input is sought in planning, who is included in leadership conversations, whose career trajectory is actively managed by senior leadership.
The organizations that get this right explicitly track senior IC development and make it someone's job to create the opportunities that develop it. The ones that do not tend to see their best individual contributors either take management roles they did not want or leave.
The dual-track model requires an organization that genuinely values senior IC contribution as much as management. The test is whether a Staff Engineer and an Engineering Manager at the same level are treated as equivalent in practice.
Developing Technical Leadership in Others
The most scalable investment a technical leader can make is developing other technical leaders. The practices that work: give direct reports ownership of problems slightly beyond their current capability, stay available for questions without solving the problems for them, debrief on what went well and what did not after significant technical decisions, and create visibility for their technical judgment by including them in conversations where that judgment can be demonstrated.
Technical leaders develop through exposure to the kinds of decisions they will need to make. A senior engineer included in architecture conversations before they are formally a technical leader is developing the pattern recognition they will need. An engineer who only sees the final decision never builds the reasoning process that produced it.
