There are three for you now: you, the VPE and the baby.
The Moment: You Need a VP Engineering
So the moment comes: you have traction, people are buying the product, and you’re hiring engineers. Maybe your team is ten, or fifty, or a hundred. Up to now, it’s been fine — things got done, perhaps with a few rough edges, but the system got built. But now something’s not working. Perhaps it’s missed deadlines, or endless quality issues, or just a frantic, close-to-burnout sense from whoever is managing the engineers.
It’s that time. You have to hire an Engineering VP.
You need somebody to make the trains run on time, figure out the “people issues”, finally deal with all the compensation weirdness you accumulated as you scrapped and fought to build the team, add some (although you speak the word cautiously) process, maybe sort out a career ladder.
So you do the search. It takes forever, usually. Who can you trust? Who is going to take this incredible thing you’ve built, and continue to grow it, without smothering it with rules and roadblocks and managerial blandness? Fifteen years of experience, or three with a brilliant track record? Strategic visionary or management expert? Technical brilliance, or people skills? There’s a lot to worry about.
Finally, you find the right person. Now things get interesting.
Your Baby Grows Up
The thing you (and “you” here might mean technical founder, or very early CTO, or just The Person Who Wrote Most of the Code), have built is deeply personal. You knew it when it was an idea, maybe a wireframe mockup, and a couple of hundred lines of code. You grew it, and remember the first time it did the thing it’s supposed to do — the thing unique to itself and to you. It was just some of what you’d imagined — a beginning, but there it was, working. You remember the demo where the first customer leaned back, smiled and said yes, they’d use it, and they’d pay for it.
You spent time with it in the early hours of the morning as the first customers figured out how great it was and how much was missing and what was broken. You showed it to a couple of people you’d worked with before. They got it. They signed on. You shared it with them, in a basement, or a desk in an incubator space, or a coffee shop, and they helped to make it really work.
It began to become real. A product of your imagination and creativity mapped into code, and living in the minds and work of customers, sales people, growth hackers, investors. It occupied (and still does!), your waking hours, your weekends, your four o’clock in the morning realizations. It dominated your personal life and your thoughts of the future.
Your thing, your baby, the thing that had occupied such a massive part of you for years, becomes a toddler. Precocious, full of potential, but feisty, unpredictable. It’s growing fast. You’re not sure how to handle it, exactly.
So you invite somebody in to help. And now you have to share.
Co-Parenting
You know about your toddler. The VPE knows about raising kids. You’re in this together.
You think your toddler is unique. The VPE has seen other toddlers, and has some ideas about what yours needs.
You are very worried that your toddler will be taught to be boring, bland. The VPE doesn’t want that, but also wants to get the toddler potty-trained, so it doesn’t crash, maybe has a consistent UX, actually responds at the speed it’s supposed to.
It’s tempting to try and manage these tensions through rules. Perhaps you are responsible for “new features” and the VPE is responsible for “the release track”. Or the VPE is responsible for everything, and you get to overrule him or her a few times a year. Or the VPE reports to you! (Don’t do this, just don’t). Or you both report to the CEO, but you’re on the Board, so can overrule the VPE once a month at Board Meetings (I’ve been VPE in this situation. I wasn’t happy).
Needless to say, none of this works if the relationship isn’t there. You wouldn’t try and raise a kid with a partner solely through rules (although people do). It’s too chemical, organic, creative a process.
You have to trust each other.
To The VPE
You (the VPE) are taking over something very precious. The founder (CTO, Person Who Wrote the Code), has put a huge amount of themselves into this thing, and they are gifting its growth to you.
You can’t just grab it. It needs to be entrusted to you. You have to take it as it is given to you, carefully. You have to be very aware of the biases you have learned from your history. You have to learn about the new thing, read the code (yes!), find the engineers who love it the most and listen to them. Hear the stories about how it was built, and understand their meaning (“we stayed up two days straight to do XYZ, and then shipped it!” — which is why that piece is a little wonky).
Find the places where it can be better with a little application of experience and process, and make your first marks. Celebrate them.
Make a difference quickly. But expect that the toddler won’t ever be totally yours. In a year, it’ll have a bunch of your mannerisms. In five years, it’ll look like your teenager. But it will never be completely yours.
Know that the founder is dealing with a loss because you showed up. When they tell you that “the engineering team isn’t as intense as it used to be”, or “I don’t get why we have to refactor XYZ”, or “I’m worried about the new hires we’re making”, understand that the founder cares, a lot, about the toddler, and is mourning their loss of connection to it, and wishes they could get right in there and fix stuff.
Also, see that the founder is brilliant, will always know the kid better than you, and can sometimes just cut through things with a razor. Don’t fight the brilliance. Use it.
And sometimes (sometimes!) put your foot down. Nobody raises a kid without having an argument or two (or three). Choose your moments. Argue the big issues, the ones you know will affect the kid for years. Stand your ground. It may be tricky to sort out which ones to fight your battles on. You’re a VPE, you get paid a lot to figure it out.
If there are a lot of battles, something is not aligned. You need to talk. Rules won’t help. Talking, carefully, about this tricky journey you are both on, might.
To The Founder (CTO, Person Who Wrote the Code)
You have to let go. Won’t be easy or necessarily fun, but that’s your job now.
You are an advisor, a coach, a mentor, a cheerleader, but you’re not in charge anymore. But you also have the history, the knowledge, and the insight. Make that work for you — it’s what you have. Pass it on.
You have operated on personal brilliance up to now. Your instinct is to fix everything through your own insight and energy. That won’t work. The kid is too big. It will grow because a team of experts will grow it. The VPE is an expert in leading experts. That’s why you hired them. Listen to them, give them space.
A good VPE will hear the brilliance and filter it well, using it judiciously, carefully, injecting it into the team at the right time and the right way. You will want to go around, head straight to your favorite engineers directly, maybe in the evening when the VPE’s gone home, and dazzle them with new ideas, better ways of doing things. Don’t. The relationship between you and the VPE will suffer, and it’s that relationship which will get your kid grown up, an adult you can be proud of.
You will never quite let go. Ten years from now, you will still wake up and wonder how the kid is doing. That’s fine. With a good VPE, ten years from now, you can call them and tell them what’s on your mind. There will still be more to do.
Getting It Right
I mostly got this wrong, early in my career. I was an engineering manager/director/VPE, a bit hot-headed, and prone to working with founders who were visionary, passionate but deeply impractical. We had confrontations, fights in front of the kid (if you don’t mind me stretching my metaphor as far as it’ll go), walkouts and nasty meetings.
It took a while to understand the depth of feeling, and the complexity of the relationship necessary to make this work (and, sure, raising a difficult kid with my wife helped clarify a lot). I got better at it.
It takes both kinds of parent, and a depth of subtle, nuanced understanding between them to make it work.