Hiring for senior tech leadership is tricky. You don’t do it often, so building experience takes longer, and when you do it’s hard to test!
From what I’ve seen, many people with years in the field can easily give an acceptable answers to most interview questions. They all know the “textbook answers” and have the communication skills to sell them.
Because of this, I walked out of quite a few interviews feeling like a CTO, Director or VP candidate answered everything correctly, but I still didn’t know if I should hire them or not.
Example Question and Answers
To better understand the problem, let’s take an example question for a potential VP of Engineering with a few different answers. The different approaches all have their pros and cons, but none are plain “wrong” as you’ll see.
Question: We have two senior engineers late on delivering a significant architectural decision.
They managed to boil down the problem down to 2 options. After a quick look, it seems like they are both completely acceptable given the context. However they are structurally different and each engineer feels strongly about the option they brought forward. The reason for disagreement seems to mostly be about personal preference. There is no interpersonal conflict, but they are stuck in an endless debate loop and nearby teams are feeling the delay.
→ Answer 1: I would sit down with both engineers and have them explain the options in details. With my new perspective andtechnical expertise, I’ll try to either find a third option or have one option come out on top. If I can’t get them to agree, I’ll pick one myself and deal with the disappointed engineer by making sure to lay out my reasoning.
→ Answer 2: I would remind them about the deadline, add more context regarding why this is important and encourage them to reach an agreement before the end of the week. I’ll also make sure they understand that teams are getting impacted by their lack of decision. If the two options are valid, they should be able to pick one, and move forward. If they don’t, I’ll give them a heads up that I’ll pick one of the two options after a coin flip… which is not optimal, so they better figure it out together!
→ Answer 3: This seems like a complex decision if two senior engineers can’t agree. Since other teams are delayed, I’ll pull a few other engineers from there and add them to the discussion. This will add overheads, but incorporating different perspectives might break the tie. To make sure I’m not making things worse, I’ll timebox the discussion to an additional 3 days.
→ Answer 4: We don’t have time for debates like this, especially if it slows down other teams. I’d just pick one of the two options and remind them both that we are here to deliver value to customer, not get into personal preferences. As senior engineers they should know this, so I’ll make sure to reinforce this in future discussions with them.
Placing Candidates on a Range
The way I see interviewing senior leads now, is that I need to figure out where the candidate stands on important topics.
In the previous example, we can see a few “sliders” being adjusted. For instance the first answer is more hands on, and answer 3 is more hands off.
While all answers would get the work done, and I’m not seeing any red flags, not every style would work for every team. As a matter of fact, you probably have one or two answers not sitting well with you already! You also probably know which one you would have given.
As someone hiring you need to know what is acceptable and what is not in terms of value for those “sliders”. For instance, you could decide to approach it like this:
In this situation, you want someone that will not be too hands on, and rely on the team. However if this person absolutely won’t get their hand dirty, this won’t be a match.
Usual Ranges
Here are some sliders that usually important to set for your organisation and then check candidates against:
- Consensus driven ↔ Decisive. Do they get everyone on board, run brainstorming sessions… or just pick what fits best and run with it, saving the time and making the right decision most of the times.
- Process heavy ↔ Bias to action. Do they create a solid framework that will help long term with onboarding at the cost of speed, or will they get things done even if it feels a bit chaotic at times.
- Protects team ↔ Pushes team. Do they make sure their team is safe from pressure so that they can do their best work, or will they show them the realities of the business, including the stressful parts, to get them to perform better?
- Technical depth ↔ Strategic abstraction. Do they stay close to architecture and code, or operate mostly at systems / org / roadmap level?
- Long-term optimization ↔ Short-term pragmatism. Do they favor durable foundations, or quick wins that keep momentum.
- Risk averse ↔ Risk tolerant. Do they work hard to minimise uncertainty, or do they embrace bets?
You might not care about all ranges, but you probably have strong opinions about some. Figure it out before interviewing candidates and make sure to test for them.
Looking at Candidates
Now let’s look at different candidates to see how this could be used.
Candidate 1
This seems like someone who would create a very clear and stable environment, and then leave their team autonomous to figure out how to deliver value. This is perfect for a company who wants to stabilise things, or in an heavily regulated industry.
Candidate 2
Here it looks like someone better fit for an early stage startup. They can probably code features or handle ops, which helps when the team is smaller. They also don’t mind risk and will move faster. This might not be perfectly sustainable or scalable, but if you don’t have product market fit, it’s probably fine.
Adapting
The best candidates will have a “default” value for their sliders, but will be able to adjust depending on their environment. If someone can’t reasonably adapt for a position, this is probably a red flag.
However, I’m convinced that if one goes too far away from how they prefer working, they will end up either burned out, unhappy about their work or they’ll just switch back to what they prefer. For instance a CTO who loves writing code and being close to their teams could lead a team of 300 people through multiple layers of management for a while… but they will eventually leave to go back to a smaller company and have a better time, or just start to randomly push code to production and make their team mad.
Because of this, during the interview process, you need to not only understand what their default is, but also where on the slider they could operate sustainably.
The Average Textbook Leader
While interviewing tech leaders, I’ve seen a more global “slider” governing all others:
- Opinionated: “Here’s how I’ll do it, it worked in previous companies and I’m sure it will work for you too.”
- Adaptive: “Everything could work, and I could make everything work. I’ll look at how you do it here and take it from there.”
I personally have troubles believing that someone could be so adaptive that they could get great work done regardless of the context. For instance building Jira processes for a team of 200 inside a fortune 500 company one year, and debugging a crash in production on a weekend for a seed-stage startup the next.
I’m not saying that it can’t be done. I’m saying that the person would be much better at their work in one of these two situations.
It’s just like senior engineers saying that all technologies are interchangeable, and they don’t really mind. This is the “official” textbook answer senior engineers have to give during interviews, but they obviously have preferences and technologies they will be more productive in.
To make sure you get helpful answers, push the candidates with questions, try to find commonalities between their previous experiences, make clear that there are no right answers to your questions. You need to get a genuine answer, and not just a very well formulated “it depends”.
Don’t let them hide behind adaptability. You want to understand how they would act left alone with real business pressure, and then map this to your expectations.
Takeaway
In this article I’m assuming that candidates are giving valid answers. Obviously some candidates are going to give responses that are just plain wrong or incomplete. This is the simple part, you can easily dismiss candidates! Going back to the example Q&A, let’s add:
→ Answer 5: I’ll just pick the option pushed by the engineer I like the most personally. I don’t like to make things awkward and I really value personal relationship as it builds loyalty, so this is the simplest solution and keeps us moving as a family. We would then debrief over beers, like I always do with my guys… so if the other person is unhappy, I’ll buy them a round or two! Overall I think it’s more about connections like this than figuring out architecture.
I hope it’s pretty clear why you shouldn’t hire this person.
Hiring for senior leadership positions is tricky because most senior leaders don’t make clear mistakes like this. You still need to test for it, but figuring out if the person can do the job is just one part of the equation. The biggest challenge is finding someone whose way of operating fits your company’s current and future reality.
Since you scrolled this far, you might be interested in some other things I wrote: