There is a version of this transition that sounds clean in retrospect: developer writes code for years, gets good at it, moves into a leadership role, advises companies. The narrative arc is obvious. What gets left out is the part where you spend a significant period feeling like you're no longer quite useful — because the thing you were best at is no longer the thing being asked of you.
I've gone through this shift twice, in different ways. First when moving from individual contributor to engineering team lead. Then again when moving from team lead into a client-facing advisory role at Proxify. Each time, the adjustment was less about learning new technical skills and more about learning a new frame for what "useful" means.
The first thing that changes: your value is no longer legible
When you're a developer, your output is visible. A feature ships. A bug is closed. A piece of code is committed, reviewed, and merged. You can point at things you did. The feedback loop is short and relatively clear.
When you move into an advisory or leadership position, the output becomes diffuse. You influenced a hiring decision that prevented a bad hire. You framed a technical constraint in a way that the business could actually understand, which avoided an expensive misalignment two months later. You asked the right question in a requirements meeting that surfaced a hidden dependency.
None of these are things you can point at. They either don't show up at all, or they show up much later, and by then the causal link is invisible. This creates a strange period of adjustment where you feel like you're doing less, even though — if you're doing it well — you're having more impact.
The most important things you do as an advisor rarely leave a trace you can point to. That's not a bug. It's the nature of the work.
Technical depth becomes a different kind of asset
The misconception I had going into team leadership was that my technical knowledge would be primarily useful for reviewing code and making architecture decisions. It is useful for that. But it turns out the more durable value of technical depth in an advisory role is something different: it lets you know when you're being told a half-truth.
When an engineering team says a feature will "take three months," a non-technical person has to take that at face value. When someone with a development background hears it, they know which follow-up questions to ask. What's in scope? What's the current state of the codebase? Is this estimate including testing and deployment? What are the known unknowns?
This doesn't mean assuming bad faith — most estimates are honest attempts. But it does mean you can have a real conversation about complexity rather than just accepting a number. That's a significant part of what makes a technical advisor different from a general manager.
The same principle applies in hiring conversations. When I'm talking with a client about what kind of engineer they need, I can hear the difference between a well-specified technical requirement and a vague wish. "We need someone who knows microservices" is not a technical requirement. It's a phrase. Getting from that phrase to an actual profile — the language, the kind of systems experience, the seniority level — requires knowing enough to ask the right questions.
The communication shift is harder than it looks
Most technically-oriented people underestimate how much the communication requirements change when you move into advisory work. Not just in terms of using simpler language — that's the obvious part — but in terms of what you're actually trying to accomplish in a conversation.
As a developer, most communication is about precision. You're transferring technical information from one brain to another as accurately as possible. A well-written ticket, a clear PR description, a precise function name — these are all precision exercises.
As an advisor, precision is still important, but it's in service of something else: getting to a shared understanding that the other person can act on. That often means deliberately sacrificing some precision. You're not trying to give someone a complete technical picture — you're trying to give them enough of the right picture to make a good decision.
This distinction sounds simple. In practice it requires real recalibration, especially if you spent years training yourself to be precise. The instinct when someone asks a technical question is to give a complete answer. The better instinct, in an advisory context, is to give the right answer — which is often shorter, more directional, and specifically shaped to the decision at hand.
What you actually learn from the transition
Looking back at the progression — developer to lead to advisor — the clearest thing I can say is that each step required me to re-examine assumptions I didn't know I had. I didn't know how much of my sense of professional value was tied to the visible output of writing code until that output was no longer my primary contribution. I didn't know how differently business-oriented people think about risk and uncertainty until I had to consistently bridge that gap.
The technical foundation matters — it continues to matter in every conversation I have. But the transition teaches you that technical capability is a starting point, not an endpoint. The engineers I respect most aren't the ones who know the most; they're the ones who have figured out how to make their knowledge useful in a broader context. That's a learnable skill, but it takes time and a willingness to be uncomfortable while you're developing it.
If you're somewhere in the middle of this shift — feeling less certain than you did when you were writing code full-time — that's a reasonable place to be. The feedback loops are slower, the outputs are less visible, and the definition of doing well is genuinely harder to read. That doesn't mean you're doing it wrong. It probably means you're doing it right.