Tech: Turnover and tenure

It’s no secret that attrition in tech is a bit of a problem right now. The hiring market is extremely competitive and everyone seems to be moving on to the next big opportunity. I mean, what else can we expect in an industry that offers massively competitive wages as new offers but offers measly 2% to 3% bumps every performance review for existing employees? People will go where they can maximize their value, and that often means leaving for a new role after a year or two at an existing role. I’ve done it myself. I’ve been very happy with my jobs and have left simply because a new job was offering some 40% to 50% higher compensation. I’ve never regretted it.

What I find fascinating though, is what an employee leaving does to the existing team at the company. Like, yeah, everyone congratulates you for getting a new opportunity and wishes you the best, and then you’re gone. You’ve moved on and the rest of the folks are still working on the stuff that they need to work on. How does the dynamic change when you leave? What things that couldn’t be accomplished by you can now be accomplished by whoever replaced you? How does the absence of your specific personality archetype impact the mood and wellbeing of the team? What initiatives were you pushing forward that are now left in some sort of limbo, put on the backburner to favor the other newer initiatives that your teammates have had but never got the chance to showcase?

Let’s explore a scenario where a Product Designer joins a pod in a company that has an existing Product Manager and an Engineering Lead. As the new Product Designer, you’re first spending some time with the people to learn about how they work as a team. How have they shipped in the past? What product development methodologies are effective for them? How does the PM work with design? How does engineering build designs? What’s the QA process? All of that fun stuff. And then you actually get to work on features, relying heavily on the institutional knowledge of your Product and Engineering partners. You propose designs, they give feedback, you refine, they provide more feedback, and you keep iterating. You’re the newbie and take all of the feedback seriously because these folks have been in the trenches for much longer than you have. They’re more immersed in the problem space and have achieved a level of domain expertise that you’re nowhere close to. Often, you might find that you take a suggestion they have and just use that to override your own design decisions. You’re questioning your own judgement because you’re not sure if you have all the context you need to make the right calls (and you can’t exactly ask for more time because features need to get shipped).

Give it a year. Now, you’re more experienced because you’ve shipped more features and have learned more about the interpersonal dynamics of the team. You feel comfortable coming up with new designs and getting them built. You have a good rapport with the Product Manager and the Engineering Lead, and you all gel really well together as a team. Then, the Product Manager decides to leave for a new opportunity at a startup. You’re sad but happy for them. They move on and a new Product Manager joins to replace them. Now, you’re the person with the domain expertise who the new Product Manager is leaning on to learn the ropes (along with the Engineering Lead). So you inform them about what you know, perhaps even subconsciously improving the Product <> Design working relationship by suggesting best practices (based on what did and didn’t work well with the previous PM, since the two of you never officially discussed best ways of working). Even in meetings to discuss the roadmap or prioritize features, the PM is always consulting with you, the designer, to ensure that the team is working on the right things simply because you’re more tenured in the team and have a level of expertise that they don’t. So the product development process becomes a little more design-led in this scenario as you build and ship features. If the Engineering Lead is significantly more tenured than you are, it might even become an engineering-led process, depending on how involved the Engineering Lead wants to be in the early scoping and designing phases of product development.

Say another six months pass and the Engineering Lead also moves on. A backfill is hired, who then relies on the Designer and Product Manager’s expertise to guide them as they plan sprints and work on improving the technical reliability of the product. They frequently consult with the Product Manager and even more frequently with the Product Designer to understand why things are the way they are, and slowly build trust amongst the team. Now, you as the Product Designer are the most tenured member of this squad. As a result, you have quite a bit of leverage to override decisions, question priorities, advocate for shifting our focus, or identify new initiatives. The Product Manager and the Engineering Lead will gladly side by you, since they see you as the person more familiar with the problem space and the one that has been immersed in the problem the most deeply. So you get to have a very design-led process where you’re able to prioritize crucial design efforts and greatly improve the design pipeline in the product. And then you leave on for a new opportunity. A new designer joins the team and the cycle continues.

I hope my point is clear by now. Every time the most tenured person in this three-person squad is of a different discipline, the entire product development process biases to be more geared towards that discipline. This is a perpetual cycle. The only way it could really be equitable is if all three people — the Product Manager, the Product Designer, and the Engineering Lead — started on the same day. But since that’s rare and almost unheard of, we end up with this ever-shifting process where we constantly keep moving the focus around. The team ultimately suffers for it as a whole since they’re not able to establish a constant steady state and are always thrashing. They’re always stuck in the forming and storming stages and are never quite able to stabilize into the norming phase. The high rate of attrition in tech means that this will continue forever until companies learn to correct for the drastic differences in compensation rates that can be achieved by leaving versus by staying. And that’ll only work for the folks that are financially motivated. A sudden change in direction from leadership or the work just not being as exciting can also cause team members to look elsewhere.

So what can we do about the problem at an individual level if the companies refuse to solve the real root cause? Well, for starters, identify what the product needs at that moment in time and decide if it needs to be biased a certain way or not. Then work with the team to prioritize accordingly. For example, a team of three working in a product-led fashion (due to the nature of turnover and the most tenured person becoming the de facto leader of the crew) could come together to discuss the state of the product and what the most pressing user needs in the moment are. If it turns out that most users dislike the product because of how slowly it loads, how often it crashes, or how unsecure the encryption is, then it’s a sign that the technical issues plaguing the product need far more attention than the design or the product offerings. So you can collectively decide — willingly this time, as opposed to just settling for the discipline of the most tenured person — that you’re going to have an engineering bias in the roadmap for the near future. Once you’ve established this, it’s far easier to go along with it. And six months later, you can revisit this and decide what part of the product needs the most attention and repeat the process.

This type of higher-level organizational self-prioritization is quite rare in tech today because of how swamped everyone often is just to do the basic work of shipping features, which when everyone’s remote is already challenging enough. Everyone also has too many on their calendars, so the natural state is to avoid any more planning or sync meetings with people that you already work with. It’s the whole “Well, I’m already working with these people and things seem to be going fine, right? Why would I want to shake things up? I think people would tell me if something wasn’t working…” attitude exhibited by everyone that causes the issue to boil and fester in the background while everyone’s busy doing the work. So until we can convince companies to treat existing employees and new hires equitably, forcing these conversations across disciplines might be the best path forward for now.