VPE Survival Guide

Don’t be a VPE. Being an individual contributor is glorious (or was till AI) - you build things, you own your craft, you ship. Being a VPE is mostly other people’s problems, on a clock, with consequences.

If you’re reading this anyway, you probably can’t help it. My litmus test: VPEs are the ones who look at the trolley problem and feel that someone has to make a decision. If nobody else is stepping up, they will.

Survival Guide is closer to how the job actually feels most days.

Who is this for?

• Software engineering leadership: VPs of Engineering, directors, engineering managers
• People who care a lot about process (and aren’t ashamed to admit it)

Many of these ideas apply beyond engineering leadership, but that’s the role I’ve held for twenty years. Even my non-engineering ideas have an engineering bias. It’s hard to get the nerd out of me.

Why listen to me?

Honestly, maybe you shouldn’t. Your context, skills, and biases may differ from mine, and what I have to offer might not apply. Plus, I could be delusional - you’re reading the ramblings of someone on the Internet.

But. I have a solid record of being effective and finding solutions. I’ve mentored engineers and other VPEs. I’ve consistently either (a) solved the key problems that were unresolved or (b) found the problems that needed attention and then solved them.

Sometimes I fix things on my own. But usually, I get things solved. I do this by:

• Asking the right questions
• Setting the right constraints
• Nagging (I have kids, so I get plenty of practice)

That approach, plus a large dose of luck, has yielded a successful career.

Where to start

Try TL;DR first. Small investment. Then decide if (a) I’m crazy, or (b) you want to read more anyway.