Negotiating for a VP Role

Post contents

I remembered some time ago — when I started getting into consulting — being given some guidance by someone who'd done consulting for many years:

"If you do well in a contract, you'll be offered a full-time job."

Never more was this more true than my opportunity with the company I'd been working with for a week or so. I recall being floated the idea by my in-house connection for the project, Obi, during our wrap up code review.

"You know, they'd probably hire you full-time if you wanted"

"They couldn't afford me," I said jestingly. I wasn't looking for another full-time job, and this was my humorous out.

"I'll bet they could. I'll bet they'd even match your pay for three days of work. You could spend the rest of the time doing consulting or anything else."

This was interesting enough, but didn't align well with my personality. I'm the kind of person that wants to really sink my teeth into any given project I'm working on.

I told Obi I'd be up for talking with them more, but that I was more interested in management positions, not being a part-time contributor.

I remember the initial hiring conversation with their CTO vividly. He reiterated their joys with my work and that Obi had recommended having me on full-time. To my surprise, they were ready to offer a healthy pay increase from what I was currently making.

I was nervous when I made my tentative proposal; "I think that's a number that would work for me, but for that much money you'd want to have someone join you as a VP, not just an IC."

"I'm glad you think so; I've been looking for someone to join me as my right-hand man with a more technical focus." He went on to explain that while he had worked at major tech firms, that he himself leaned more towards project management and business solutions; less towards the code or architecture itself. It's a common refrain I've heard from many CTOs who join their respective companies early on; they're often technical enough to find the right solutions and people, but may not be technical enough to scale the code beyond initial implementations.

And with that, I was officially in the races for a VP role.

Interviewing for the Role

Leadership interviews are weird. They focus less on raw technical chops and more on how you'd handle given scenarios. It's a far cry from the kind of invasive leetcode questions that you either fervently love or hate. Maybe it's because I had already demonstrated many of my technical skills during the contracting phase, but I've heard similar from many of my leadership peers since.

A majority of my time in the interviews was spent through a conversation with their CTO. Two hours of back-n-forth, answering a question only to ask a clarification on the business itself. I have a habit of going for walks around my neighborhood during meetings where I can afford to be away from the screen. I must've looped the park nearby my house half a dozen times during that call.

While there was a barrage of questioning, one stands out in my memory of this walk:

"What is a guiding principle of your leadership style?"

I stopped for a moment to think and recalled a mantra I had adopted as a manager in the past: "My job is to take the responsibility personally when something goes awry, but when things are going well to disperse that credit to the team."

I then recalled a story that I thought would best embody this quote.

"I once led a team of engineers working on a mobile app." I posited.

"One day, while working on debugging an issue with publishing an update, one of my staff uploaded our keystore to a third-party service to try and read the value inside." This was a huge problem; it meant that we had just made it easy for this third-party service to sign a fake version of our application. This fake version could then be distributed to our customers with malware inside much easier.

"It wasn't until long that my team member realized the problem with what he had done. Rather than try to hide this fact, he came to me immediately, apologizing profusely along the way. I told him it would be okay, tried to understand the problem he was looking to solve, and explained what the better route would have been."

"When I disclosed this to my management, I delivered the information with a caveat: I would not disclose which of the team members had done this. After all, it was my fault for not training that employee better or implementing more stringent security protocols. Luckily, they understood, so we were able to move past this quickly."

It was a long-winded answer to my future CTO's question, but it came with a closing statement:

"I work in teams where trust is paramount. Had I harshly chastised that employee, he would be less likely to disclose mistakes in the future. On the other hand, had I not established a strong report with my management team, we would have been lost in a meaningless game of cat and mouse. Trust is earned in both directions at a company, both up and down the chain of command."

He seemed happy with this response. The next thing I knew, I was being offered the role.

Learned Lessons

I learned a lot in this pipeline into becoming a VP:

1. Don't be afraid to make radical proposals.

   I was being incredibly bold by proposing myself for the VP role. This could have gone poorly, but I learned early on in my career that it's often better to ask for forgiveness rather than permission. Many organizations want you to take ownership over your work, even if it means the occasional misstep along the way. While there's nuance to this — especially for marginalized individuals, where this advice can sometimes lead one to being ostracized for being "too forward" or whatnot — it's worked out well for me.

2. Personal experience is a powerful tool to lean on.

   Like many of my most high-profile interviews, my time spent talking with my CTO was based on my personal experiences. Being able to articulate my judgment calls in real-life scenarios has taken me incredibly far in being able to prove my knowledge that I've ascertained over the years.

3. Guiding principles can differentiate you from others.

   Whether we're talking my early "Humans behind the screens" focus or my more recent mantra of "taking ownership when things go wrong but praising the team's success," these principals helped differentiate me against other candidates. It tells the hiring manager that I'm likely to follow principals that point me in the right direction. Moreover, not only do they help frame my thought processes, they help guide my decision-making and allow me to stay on-brand when facing a question with multiple paths to solve them.