Over three and a half years, I managed about 25 people across three teams. I inherited one of those teams. I built the other two almost from scratch: one started with a single transfer, the other with two transfers and an acqui-hire. Both grew to eight engineers.
- 3.5 yearsThree teams: one inherited, two built from scratch.
- ~25 peopleEngineers and two managers.
- 6 promotionsFrom SE2 to SE3 all the way up to Staff to Senior Staff, plus one Staff engineer who moved into engineering management.
- 1 departureAn engineer who left to follow his passion.
That didn’t happen by accident. Here’s what I did.
It starts with the interview.
Many hiring managers treat technical ability as the main thing to hire for. That can get you the most technically capable team, but it tells you nothing about how well that team will work together.
By the time a candidate gets to me, a panel of engineers has already tested their technical skills. So I skip the pop quizzes and hypotheticals. My job is to learn who the person is and how they work with others.
I tell candidates up front: no quizzes, no hypotheticals, we’re just going to talk. That usually lowers their guard, and I get to meet the actual person instead of their interview personality. We talk about their past roles, how they work, their team dynamics, how they felt about their previous manager, and what it was like to be part of that team.
A casual conversation isn’t the same as hiring on gut feeling. I don’t know of any pop quiz that tells you more about someone’s character than how they talk about real situations from their last job.
The hire the panel rated a level lower.
We had a candidate, I’ll call him John, interviewing for an SE3 role. He was technically solid, but the engineering panel rated him at SE2. When I talked with him, though, it was obvious he was hungry for a chance to prove himself, and his personality would fit right in with the team.
We hired him as an SE2. He was a breakout almost immediately, performing beyond his level and making friends and mentors along the way. About 14 months later, he was promoted to SE3.
The candidate I passed on.
I asked another candidate about a disagreement with a previous manager. He paused, then described an argument over architecture. He told me he’d said to his manager that he was “just a figurehead” and that engineering decisions should be left to the engineers.
I partly agree with that. Engineers should have a real voice in engineering decisions. But the confrontational way he handled it, and the fact that he thought it was fine to repeat in an interview, told me enough. I passed.
Choosing who stays after an acquisition.
The same approach mattered when we acqui-hired a team. They had built a product good enough that we bought the company, so technical ability wasn’t really in question. What I needed to know was whether anyone was bitter about the acquisition, and whether they had the ambition and drive to succeed in a new environment. Those conversations decided who joined the team.
Every hire needs a mentor and a mentee.
When I hire, the first question I ask myself is: who will this person mentor, and who will mentor them?
As their manager, I’m always part of their mentorship. But who handles the day-to-day? If no one on or near the team can mentor a new hire, I have two concerns: they’ll feel like they’re on an island, and they won’t have the right opportunities to learn.
The next question is whether they have room to grow. For junior engineers, if there’s nowhere to go, there’s very little to work toward. I hire for ambition as well as character, and it’s tragic to hire an ambitious junior engineer knowing they’ll never get to be more than that. For senior hires, growth looks different: the higher you go on the ladder, the less of the job is coding and the more it depends on the soft skills I’d expect from a manager.
In an industry where most people change jobs to get promoted, I’d rather keep the talent and offer the growth here.
Pairing people up.
I pair engineers as mentor and mentee. Depending on the team, senior engineers may have more mentees than mentors. This matters most on remote teams. It builds camaraderie, gives senior engineers a real sense of leadership, and gives junior engineers a structured growth plan and someone to go to when they’re stuck.
It helps the mentor as much as the mentee. One of my SE3s regularly got caught up in his own head. Whenever a new idea came to him, he’d rethink his approach and rework what he’d already done. Once I paired him with a mentee, he had a somewhat forced chance to talk through his plans and explain them to another person. His task paralysis started to fade. He was later promoted to Staff engineer.
Making the work visible.
Celebrating the team means making sure everyone’s work is seen, and that each person knows they’re valued in their role.
Regular demos.
Each person shows the team what they’ve been working on.
Knowledge-sharing sessions.
The team learns and grows from one another.
One-on-one check-ins.
We talk about how the mentorship is going and whether they feel they’re growing.
Visibility matters most at promotion time. I work with each person on a promotion document that lists their accomplishments and shows they’re already working at the next level. We go through how they’ve worked with coworkers and collect as much positive feedback as we can. Then I make the case in calibration.
Sometimes there’s no budget for promotions. When that happens, we keep adding to the document anyway, and I make it clear that as soon as budget and opportunity come back, we’ll be ready. My goal is to keep hope alive. If the promotion window stays closed too long, the company has bigger problems than losing one engineer.
What happens when you skip this.
At a previous organization, which I won’t name, I watched a hiring manager hire almost entirely for technical ability and seemingly ignore soft skills. His team ran mechanically. There was little to no camaraderie, and they often disagreed in public. Working with them from the outside was painful, partly because of their people skills, and partly because the turnover made it hard to know who to go to for what.
The one who left.
The one engineer who left my team did so to pursue his passion for geospatial engineering. There wasn’t much I could offer to compete with that. We still keep in touch on LinkedIn and check in from time to time.
That’s the whole approach: hire people for who they are, give them someone to learn from and someone to teach, make their work visible, and fight for their growth.
Most of them will stay. The ones who leave will do it to chase something they love.
Over to you
- What’s the one question you ask in every interview that isn’t about code?
- Who on your team is ready for the next level, and does their promotion case already exist?