I collected all mistakes that you can imagine.
That’s how I describe my first VP of Engineering role. The project died. The team burned out. And I worked “25 hours per day” trying to save it with code.
Here’s what nobody tells you about jumping from technical lead to VP.
Mistake #1: I Thought Code Could Fix Management Problems
I was hired as technical product manager, and when the team grew, they promoted me to VP - seemed logical at the time.
First red flag? I was still the key code contributor.
I became a bottleneck. Every decision went through me. I reviewed all code, sometimes just rewrote it. Fixed bugs at 2am after meetings all day. Team members were burning out, but I thought I was helping by taking the hard technical work.
The results were chaos. One sprint we’d deliver huge feature. Next two sprints - nothing.
I didn’t understand the difference between technical lead and people manager. Technical lead writes code and guides technical decisions. VP of Engineering builds teams and creates conditions for others to succeed. Big difference.
What actually works:
Stop coding production features. Period. Your code becomes a bottleneck and undermines your team. If you must code, work on tools, prototypes, or investigations - never on critical path.
Trust your team with technical decisions. You hired them for a reason. If you don’t trust them, that’s a hiring problem, not a coding problem.
Mistake #2: I Let Others Control My Team Composition
Outsourcing company sold developers directly to C-level. I just “ate it.”
Some people took salary and did nothing. I had no time for proper onboarding. Didn’t delegate onboarding to team members because I thought it was my responsibility. And I was afraid to show I couldn’t handle everything.
So what did I do? Covered all problems with my “free time.” Worked those 25-hour days.
The fear of looking incompetent made me accept terrible hires. The business burned money on people who made things worse, not better.
What actually works:
Own your hiring process completely. Fight for it. If C-level wants to hire without you, make the consequences clear - in writing. “If I don’t vet engineering hires, I cannot guarantee delivery.”
And here’s the thing about showing weakness - admitting you need help is not weakness. It’s leadership. Say “I need support with X” early, not after everything collapses.
You shouldn’t be the smartest person in the room. Don’t be afraid to ask team for help.
Mistake #3: We Had Fake Scrum
We thought we had Scrum because we had 2-week sprints, but that was literally all we had.
Tasks changed mid-sprint whenever someone whispered “investment” to C-level. “This feature is game-changer and MUST be done by day X.” Every. Single. Sprint.
Time to time I tried to say no. Got overruled. Sometimes I implemented the new feature without even telling the team. Just disappeared and coded it myself. Sometimes I tried to explain why we needed to change scope. Sometimes C-level accepted my reduced scope proposal.
Team stopped caring about commitments. Why care when everything changes anyway?
What actually works:
Real process protects the team. If you can’t protect sprint commitments, don’t pretend you have Scrum. Be honest - you have a priority queue that changes daily.
Document the cost of context switching. Show data: “Last month we changed priorities 8 times. We delivered 20% of planned work.” Make the invisible visible.
Learn to say no with alternatives: “We can do X, but it means dropping Y and Z. Which would you prefer?” Put the trade-off decision back on them.
Mistake #4: I Hid From Strategic Discussions
Big disadvantage - my spoken English sucked. Couldn’t discuss with management at needed level.
So I tried to cover it with technical skills.
Result? No 1-on-1s with CEO (we had no CTO). Skipped investor meetings. Excluded from strategy discussions. Only brought in to execute promises already made.
I was VP who became senior developer with fancy title.
Never even asked for meeting notes.
What actually works:
If language is a barrier, prepare written communication. Send pre-meeting thoughts. Request written summaries. Use async communication as your strength.
But let’s be honest - language was partly an excuse. The real problem was avoiding confrontation.
Force yourself into strategic discussions. If you’re not invited, invite yourself. “I need to be in investor meetings to ensure technical feasibility.” Simple.
If there’s no CTO above you, congratulations - you ARE the technical strategy, so act like it.
Mistake #5: I Forgot People Need Growth
I had no time for learning and no mentor - it was pure survival mode.
About team development? Didn’t even cross my mind.
I assumed my years of technical leadership experience covered people management. Wrong. Completely different skill.
Team members need career paths. They need mentorship. They need to see a future. I gave them nothing but chaos and overtime.
What actually works:
Block time for your own learning, even in crisis. Especially in crisis. You can’t lead from empty.
Find a mentor, even informal. Someone who’s been VP before. Pay for coaching if needed. The cost of not learning is project failure.
Schedule regular 1-on-1s with team members about their growth, not just tasks. “Where do you want to be in a year?” matters more than “What’s the status of ticket X?”
If you don’t develop your people, they leave. Or worse - they stay and stop caring.
The Real Lesson
The project failed. But failure is expensive education.
My biggest mistake? Thinking I could handle VP role by working harder instead of working differently. Technical skills don’t solve leadership problems. More hours don’t fix wrong priorities.
You know what would have helped? Someone telling me these truths before I burned out a team and killed a project.
So here it is - learn from my expensive mistakes.
Being VP of Engineering isn’t about being the best engineer. It’s about creating conditions for others to be their best. And sometimes that means admitting you don’t know what you’re doing and need help.
That’s not weakness, it’s actually wisdom.
Just wish I’d learned it cheaper.
Need help transitioning to engineering leadership? Let’s talk about avoiding these expensive lessons.