You're responsible for the team, not the code. That's a harder job.
The skills that made you a great engineer or engineering manager are not the skills you need now. The transition is real, and most people underestimate it.
The VP of Engineering role looks like a promotion. And it is — in title, scope, and responsibility. What it actually represents is a career change. You move from a domain where you can measure your own impact directly (code ships, tests pass, velocity moves) to one where your impact is entirely mediated by other people. That is a much harder feedback loop to work with.
The VPs of Engineering who scale well through their first year are the ones who find that feedback loop quickly — who build the habits, the relationships, and the perspective that the role actually demands. That usually requires someone outside the company who can see what you can't yet see about yourself.
What we work on
The six transitions that define your first year as VP Engineering.
These are structural challenges of the role, not personal failings. Everyone hits them. The question is what you do when you do.
- Letting go of the code Your instinct is to jump in and fix things. You're often right about what needs fixing. But every time you do it, you undermine the engineers who should own it and stay dependent on you rather than growing. How to redirect that instinct without losing your technical edge.
- Scaling from 10 to 50 engineers Everything that worked at 10 people breaks at 25. The communication patterns, the onboarding, the way decisions get made, the way trust accumulates. How to redesign the org incrementally rather than waking up to a broken team.
- The technical debt conversation You know the debt is real. You know it's slowing everything down. Getting the business to allocate time and budget to address it requires a different kind of argument — one that speaks in risk and velocity, not architecture. How to have that conversation without losing credibility either way.
- Hiring senior engineers You need people who are better than you at the technical parts of the job. That means hiring people who could do your old job better than you did. How to attract them, assess them honestly, and build a relationship where they stay.
- Managing the CTO relationship If you have a CTO above you: how do you stay in sync without being micromanaged, build your own authority without creating turf wars, and position yourself for the next move in your career? This relationship shapes everything, and most people don't invest in it deliberately enough.
- Building engineering culture deliberately Culture is not what you say you value — it's what you tolerate and what you reward. Someone once challenged me because a member of my team answered "Nobody" when asked who their boss was — they meant it as a criticism; I took it as the highest compliment. How to build a team that runs on trust, not on you being in the room — and how to know when the culture you built is the wrong one for the next stage.
I have hired and led over 200 engineers across six companies — scaling from zero to a full R&D organisation at Jolla, and building a financial services engineering unit from zero to MVP in nine months at Utopia Music. I know what this transition asks of you, and I know what it costs when it goes wrong.
Weekly or fortnightly 1:1 calls · 6-month engagement · One spot currently available
Book a free 30-minute call →Also relevant: First-time CTO mentoring → · CPO and VP Product mentoring →