Many teams have the same fear when it comes to a new manager: they fear the process monster.
Process monster (n): a manager for whom the answer is always, always ‘process’. The process monster will add more and more processes to the team until the team collapses under the weight of them. Eventually, the monster will move to another role, and the failure of the team will be explained as ‘resistance to process’.
I’m sure you’ve encountered process monsters in the wild before. Some have enough empathy and are in the right roles to be successful, while some have the effect of strong glue: slowly grinding a team to a halt under the illusion of improving efficiency that never materializes.
When I take on a new team, I understand that they fear I am a process monster. And I know that fear, because I, too, have encountered these kinds of poorly-deployed managers. Out of this understanding of the fear, and a reluctance to be seen as a monster myself, I used to be slower to deploy process change. I would pick my battles very selectively, focus on outcomes, and let people get there by themselves. Overall, it worked well enough for the things I considered important, but eventually, I got to see Emily Webber’s framing of ‘experiments’ for team delivery. Her approach to delivery is to help teams agree on areas for improvement and propose ‘experiments’ designed to address them. Learning this set me on a different path.
Now, instead of ‘process changes’ I talk about ‘team experiments’.
The first team experiment I ran was on a team that did all their communication in private channels. This wasn’t great for the perception of the team and it had made the folks within it a little insular. Our experiment was to talk only in public for a week. Of course, no-one wanted to do that long-term, but doing a more extreme experiment allowed us to very quickly shift the balance of team communication. We put the work chat in public where it needed to be and kept the private channel as a safe space for personal chit-chat. A big win! Without this ‘experiments’ framework, I would have spent months of more tactful efforts to reach the same outcome.
What are the benefits of experiments?
Experiments dispel the fear of the process monster
Process monsters dictate, overprocess, and they come with a playbook and a goal of 100% adoption. Framing things as experiments is an equalizer. It gives the suggestion that you, as a manager, don’t have all the answers and that nothing is set in stone. An experiment is an invitation to everyone on the team to participate.
Experiments improve buy-in
Presenting an idea as an ‘experiment’ rather than a ‘change’ frames it as needing far less commitment and makes people more likely to be willing to give it a go. This framing also makes people more open to giving feedback and making their own suggestions, increasing the participation of people on the team.
Experiments reframe solving problems as learning
When we institute change, it’s often with a problem in mind that the new process is meant to address. I have seen managers do many bizarre things, such as ask people to track their time in 15-minute increments (I’m still not clear what that was supposed to solve…) or institute vast quantities of work on top of everyone’s regular job in the name of developing them. This leaves people to question what was more important – the needs of the teams they worked with or the ‘extracurricular’ requirements? Resistance to such efforts often obscured the problem that the manager was trying to address. The processes inevitably failed, and months – or years – later, the same problems remained.
When you start with an issue, the first thing to do (that many people skip) is to get buy-in from your team for solving it. When you frame this as an opportunity for your team to learn, you are more likely to get them on board.
Of course, sometimes the problem really is clear, and the answer really is process, and experiments are not a suitable model when you know what you need to change; people will see through an approach that asks them to guess what you have already decided. However, for the most part, especially when trying to make an ok team good, and definitely when trying to make a good team great, continuous improvement and team engagement have a much larger benefit than top-down process implementation.
What are good times to use experiments?
During onboarding
Onboarding is a great time to experiment because onboarding needs to evolve as your team does. On our team, every new hire conducts an ‘experiment’ on the next hire – typically adding something to onboarding that they would have found interesting or useful. This has included collecting a piece of advice from everyone on the team for the new hire, as well as having each person on the team share a project and a learning from it with the new hire. Often these experiments have involved everyone on the team and focused on the more distinct aspects of company culture, which has been a nice way for the new member to start building connections and understanding the way we work.
During periods of high growth
When teams are relatively stable, processes tend to be the same. However, during periods of higher growth, processes may break down many times as the system adjusts to the influx of people, traffic, and everything else. This is a great time to experiment and learn, because realistically, a lot of what you might be inclined to do will have to change as circumstances change.
During periods of high unknowns
The leadership team is having a complete changeover again, and this creates uncertainty on teams as to how they will be affected. In the worst case, some engineers are developing some sort of a victim mindset. (‘How can we know what to focus on when we have a new director every six months?’) Experiments can give teams a sense of control amidst chaos and can give them a healthier inward focus compared to events outside their control.
Ahead of problems
When you see problems coming, but they haven’t actually arrived yet, it’s a great time to experiment. For instance, your next hire is in a far away timezone, so the time to experiment with adopting more asynchronous communication is now, not on their start date that’s two months away. Another example: the team will be split across two projects next quarter, so now is a great time to try things that might help support that, before it’s needed. Asking the team, ‘What can we try before X happens?’ can help prepare your engineers for the change in advance.
For observed trends
Sometimes there’s a common theme of feedback or concern on the team, but it’s not quite concrete enough to make a recommendation in response. Experiments are a great way to get team input on what they think is happening, and what they think would help. When I joined my current team, there was a theme of a lack of community in some of my early 1:1s. Bringing this theme into the framing of our early experiments allowed us to try a number of things (such as a watercooler channel, sharing more personal updates in our team meeting, and more peer 1:1s), and we saw a clear improvement within a couple of months.
Conclusion
Experiments are not suited to every situation. When there’s a process being forced down upon you, or if the team doesn’t have baseline functioning, you will need to address that first. Managers can feel pressure to have all the answers, but we don’t, and inviting our teams in can build agency, collaboration, buy-in, and creativity – making for a stronger and healthier team. Once teams are engaged in this process, they will keep suggesting and iterating on things, freeing you from the position of ‘team improver’, and allowing you to embrace a role of facilitator or focus on other things.
A crucial thing to keep in mind as you experiment is that it’s not the goal to keep all of them. In fact, if you do, you’re probably not being ambitious enough! Dropping experiments is an important part of being willing to suggest more creative or extreme experiments – which are more likely to not last long-term. Now that experiments are more deeply embedded into our team culture, we’ve made two changes. The first one is being willing to just adopt ‘obvious improvements’ without feeling the need to experiment on them. The second is an experiment around Monty Python rules, which means that if one person thinks it’s a good idea, we all have to give it a try.
I think it’s safe to say, the fear of the process monster is gone.
