How to free yourself by making your team resilient
If you lead an engineering team in 2019, you are -for sure- feeling the pain of trying to keep it staffed with quality talent. It has always been difficult to keep up with the inevitable attrition, but with the demand for talent as high as it is today, you must feel like you’re just stuck recruiting, training, reorganizing your team, and dealing with personnel issues. For those of us who are growing our teams, it’s even worse:
You might feel right now that all of this people- and process stuff keeps getting in the way of doing your job. When will you ever have time again to focus on building technology and your business?
The answer might be (to skip right to the end):
Not until you give up focusing on tech for a while
As the leader of a growing engineering team, we end up spending a significant portion of our day finding- and managing people, and implementing processes, rather than developing our company’s technology. To most of us, this is a new challenge, and it can be daunting. It can be daunting enough that we seek help and fall into the trap of happily delegating all these tasks.
Don’t delegate building your team. It’s a trap
Sometimes you just need fish, and it’s OK to find someone who will get them out of the ocean for you. This is not one of those cases. In this case, you want to learn how to fish, and get really good at it, by letting everything else go for a while.
Avoiding the trap
If, however, we fully embrace these new responsibilities, instead of immediately offloading them onto team members, recruiters, or consultants, we can embed lasting capabilities into the structure of our teams, and come out a better leader. I more or less stumbled into doing exactly that, when at a past company, for 4 years straight, I was doubling the size of my engineering team.
I had led engineering teams before, but this was a new challenge. Processes and management structures break at a certain size. You adjust them, simply to see them break again,when size and complexity grows. I realized that, unless I was going do manage all of this myself forever, I’d have to help my team evolve by itself; I had to make my team resilient.
6 Principles for a resilient team
Having filled leadership positions within various technical areas, team sizes, and growth rates, I’ve been able to identify -and put to practice- a few principles, which in my experience have always been a great foundation for a high performing -and resilient- team. Making sure your team has built-in resilience is critical to keeping yourself out of fire-fighting mode, and your team’s throughput from plummeting when someone unexpectedly leaves. With built-in resilience, you can (eventually) trust that your team can replenish and reorganize itself, and without much direct involvement from you. If you were hands-on involved in setting this transformation in motion, and I mean heavily involved, you should be able to step out of the engine you’ve built for quite a while, and still recognize the culture you originally instilled in it, even after your team takes on a lot of new talent.
The principles:
Design your organization around workflow & processes, instead of around individuals
This allows you to plan much more easily at scale, and forces you to do the work to make your team a plug-n-play environment. If you structure your team around individuals, a single departure could mean your whole team falls apart. We all try to limit single-points-of-failure in our systems, and we should limit single-people-of-failure just the same.
But make sure you treat your team members as people (with empathy)
If you set the right example, your team members will follow, and empathy for each other becomes a lasting part of your culture. This is what makes people stay on your team (people don’t typically quit their friends), which is really the best kind of resilience. The kind of micro-resilience you probably need every single sprint, relies on people helping out their team members when needed, which can really only happen if empathy is the norm.
Always be succession planning (the what ifs when people leave their current role)
Don’t expect to replace people like-for-like. Make sure you can split up people’s responsibilities, so you can replace them with -partial- other people. You should actively prevent- and address information silos, so others can step in when needed, without months of ramp up time.
What really helped my team in the past, was to split technical leadership, project / product leadership, and organizational leadership. It does put your team in a three dimensional matrix (not for everyone), but it gives you great flexibility for succession planning. I’ll note that this is not going to work in every situation.
Let people work on what they want (and aligns with your team’s objectives)
If you set up ways to understand what makes people tick / excited, and routinely look for opportunities in their day-to-day work, it’s pretty much always possible to let people work on something they actually want to work on. We used to have “draft day”, where technical leads would pitch their upcoming projects, to try and convince other engineers to join them on their team. Everyone got to state their top 3 picks. Some people pick based on technology used, some pick based on who leads the team (looking for mentors), and others pick based on the problem the project aims to solve. In the end, nearly everyone got to work on their 1st pick, and everyone else their 2nd.
Let your team members be part of all aspects of managing your team
I set up our work processes in a way that there were always 2–3 people on my team who could decide and act, as long as they reached consensus. If they couldn’t reach consensus, I’d be the tie breaker, which rarely happened. My team members would do the same, all the way through to individual contributors on a team. This is key to achieving resilience; command and control style management creates artificial bottlenecks, and doesn’t scale well.
Hire only people who will like your culture -and- can code well
Picking one over the other is a mistake; you need both. Hiring someone who wouldn’t thrive on your team, is obviously a bad idea. Compromising on technical skills, is destructive to team morale, because others will suffer from poor design / implementation. If you can’t find someone who meets all your requirements, you can adjust your team structure or recruiting strategy, but don’t ever settle for lesser talent.
No one size fits all
Exactly how you apply these principles, has to be different for every unique situation; there’s no silver bullet. How the details matter, became clear when a CTO friend faced a similar challenge, except that he was tasked to grow his engineering team from 5 to about 45 in only two years. That higher growth rate, and some other minor differences, meant that some of the things that had worked really well for me in the past, didn’t work for him — at all. Fortunately he was able to work through the issues, and the other day he told me that he felt like he finally accomplished his goal:
The team was growing and healing itself
For the first time in 2 years my friend had time to breath, and although this newfound freedom was all a bit weird to him at first, I could tell that by now he felt like he had accomplished something great.
Do I really have to do all of that myself?
You might think that this sounds like something you should hire someone for, because it’s not your top strength, or it’s going to take too much of your time. The truth is, that leading engineers is not easily done by someone, who is not an engineer themselves. Designing an organization around a complex and volatile workflow is really hard. It needs an organizational architect type person to work well in practice, and someone who understands the complexity of how software gets built and managed. If you don’t lead this by example, eat your own dog food, and know what bad dog food tastes like, you’re setting your team (structure) up to fail. Putting it all on someone you bring in from outside your company, or on one of your best engineers, is likely to fail. It requires a combination of people leadership abilities and respect from your team members, which pretty much only you can bring.
So, yes, you have to be hands-on with this.
What success looks like
If you do this well, and you get through the last parts (delegate the things that are working well), you can get back to focusing on “the fun stuff”. And if you put in place some clear markers to tell if your structure is working well, you get early warning signs, and can jump in to correct course at critical times.
For me, the main markers answered these questions:
How often does my team need me to be the tie breaker?
How often does my team inform me of a decision, made by consensus, with which I don’t agree at all?
Are we delivering as expected?
Are people quitting our team, and why?
As long as things are working well, you can focus on fun stuff
Fun stuff can literally be anything you want it to be, like a pet project, technical mentoring, whatever. For me, something interesting happened. I actually really liked the organizational architecting, mentoring, and other leadership stuff I was doing. So I started helping out others, and took over some other departments; I doubled down on all of this. The most important thing I learned, though, was that:
By fully emerging myself into all the non-technical aspects of my role for a while, I was able to come out on the other side a better leader, freed of that feeling that “unless I’m writing code, I’m not making valuable contributions”.
Now that my team was resilient, I was free to choose my next path. If you are facing the challenge of maintaining or growing an engineering team today, consider this path as well.
What will you do once you’re free?
