The internet is largely a highlight reel. We see the best of the best, and we see the most exciting things. It's easy to get caught up in the notion that success and innovation come easily. However, behind every success story, there are countless hours of hard work, dedication, and often, a lot of boring tasks.
Retention is a by-product of a long term investment in somebody. It's not something that happens right when someone has a foot out the door.
Here was the situation, from a few years ago:
An engineer on my team messaged me off-hours asking to schedule a meeting for the following day. Since the timing was odd, the request vague, and since I had some time, I offered to jump on a call immediately. They deferred and so we agreed to chat first thing in the morning. I was expecting a resignation letter to land in my inbox and a short conversation about 'timelines' and 'transition'.
The next morning, we get on a call.
Hey man, I just wanted to let you know that I've been talking to another company and they've made me an offer for 40k more than I'm making here.
Okay, wow. This may as well have been a resignation letter. There's no world in which I would be able to convince the company to part with that type of money for a counteroffer. That said, I figured that what might be happening is an attempt to get a counteroffer. You know, bump up the current salary by a bit.
I knew that if the number was closer, maybe we could do the dance. But this gap was too far to bridge, no chance.
On a personal level, I was thrilled for them.
That's huge, congratulations! You should take that. We thought you were good when we hired you, we love having you on the team, and clearly someone, some other company, saw that too. You're a great add to any team, so, congratulations.
I don't think he was expecting that.
As an engineering manager, you want to keep your team happy. And if your team's performing well, you want to keep the band together. But ultimately, each individual does have the ability to move to greener pastures and if that's legitimately the best thing for a teammate then I'm really happy for them.
Look, you're a big part of the team and it's gonna hurt. But on a personal level, you know, I'm proud of you. You should take that deal.
I also made clear that there would be no counter-offer. We're not gonna match it, there's no way.
But, as a courtesy, I did tell him I would ask, just to confirm. You don't get what you don't ask for.
As expected, my director said, "Yeah, that's not happening. Let me know when his last day is".
So, with the engineer having until the end of the week to accept their offer, all I could ask was for them to prepare their transition out.
At the end of the week, the engineer messages: "can we have another call?".
I've declined the offer.
My turn to be surprised.
I would love to know how you came to that decision.
I knew it couldn't have been an easy decision to make.
He shared that it came down to the position he held at our company. He was getting cool projects. He was working on tech he enjoyed. He also saw the path towards management/leadership, and that we had been actively working on that plan. There was more money elsewhere, but he would have been at the bottom of the ladder there, with less influence and responsibility that he craved at this point in his career. So, he stayed.
I think that about that a lot.
I've been on the other side of 'retention', and I know what it feels like to work at places where you feel valued, and where you don't.
That's why I think retention is a long term game. It's the culture that's built that surrounds the team. It's the interaction and the relationship that you have with your team. It's having a legitimate growth plan. Answers to: Where do I go next? How do I get better? What are you gonna do to help me get to my next career goal?
Those things matter and I didn't realize how much until that moment.
An engineering manager asked me, "What do you do when you notice that your team is shipping more and more bugs?"
"More and more of the work that's going out is coming back with regressions, with user complaints, with crashes, and the like. What do you do in that situation?"
As with most advice, the answer is it depends. You have to figure out what the underlying reasons could be, as well as the context in which they are happening. What we do know, is that humans are going to make mistakes. Programmers are going to ship bugs.
The first thing that's notable to me about the scenario is that there is likely a perception from leadership (or anyone above our protagonist) that there are increased bugs and they're more severe and people are complaining and so now it becomes a critical issue that needs to be investigated by the engineering manager. Fix your team!
Let's dive in.
So if we take it as a understood that people are going to make mistakes, and that bugs are currently in your production code, then where can we look to minimize the rate of occurence of these bugs? Here are a few I can think of:
Most companies have a code review process. At places I've worked, it looks fairly standard. Someone makes a change, someone different reviews it, approves it, and then it can go into main if the test suite passes. Usually it then gets deployed to a preview environment, where folks poke at it until it's deemed fit for production. At this point, take a step back and consider: if a bug getting through all of those layers, I don't think you can blame any one person or step.
Well... As the EM, it's your responsibility to own it and to figure out how to improve the situation. So you might end up taking the heat here. ...Congrats?
Anyways, tactically it is very tempting to focus on each piece of the process. You might actually have major strides to gain there! Don't have a test suite at all? Adding one will help. Have one, but it's always flaky/red? Getting it to green will help. Etc. So definitely evaluate the process.
Another aspect to investigate is the culture, pressures and health of the team. The human side of our development equation. This can be overlooked by the clear solutions we can make on the process side!
I'll start with pressures, since it might be the easiest to identify. You may
have experienced some flavour of this: "Yeah, ordinarily we would
[fix this first | test it more | etc] but we're shipping this because
[of our deadline | we're going to land a client | etc]. Let's call it a 'known
issue', but we'll come back to it later". Most often this is culture set from
the top-down during sales pushes.
This behaviour accrues known technical debt, and sometimes, that's super valid. You don't want to be perfect to roll something out. That doesn't make sense - you'll never get anywhere. On the flipside... going to far on the other end might lead to the titular situation.
Now, sometimes this ship now, worry later vibe is actually the culture of the team. You might find this in younger companies, where iteration speed and the short feedback loop is paramount. For a company trying to mature as an engineering organization, this mentality can be hard to shake. Determine if your team's current culture is a product of one they've been used to, and if a tone shift is required.
Finally, reflect on the team's interpersonal relationships and role dynamics. Perhaps a senior engineer is getting their changes greenlit by juniors who are afraid to bother or challenge them. Someone could be letting a team priority slide while they work on an initiative that benefits them personally. In the worst (beyond rare, in my experience) case, someone could be actively trying to drive another person off the team by letting their bugs through.
Ultimately, to generalize the problem, as an engineering manager you're trying to figure out:
in this case, within the context of code quality and delivery.
If you zoom out, From there, you can form a plan of action, and do the necessary expectation management and communication in every direction. This is a process that you can (and should) repeat over and over!