Chaos Engineering Your Team
Mountain Goat Software runs possibly one of my favourite blogs at the moment. This recent post “Should Your Team Adopt No-Meeting Weeks” really resonated with me.
I read an article while back, but of course I cannot find now, about how you might want to consider applying Chaos Engineering, not only to your technology, but also your people. A random person gets selected maybe once a week, to take the day off. Simulating a sick-leave like situation.
I’m a huge proponent of the idea that no single person should be critical to your business, and in fact they become a massive risk to your business that is only realised once they leave. It also creates an uncollaborative working environment because you will have a lot of different pressures from different people on one person. This is covered a lot in The Phoenix Project.
Using the principles behind Chaos Engineering you can build in expectations in to your team that you should be able to survive the loss of a person.
What I like with the experiment mentioned in the post, taking a random person out of meetings, was that this it is similar to Chaos Engineering your team, but at a smaller scale. In the situation where the person, who is critical to your meeting, gets unceremoniously booted out of said meeting, you have identified a process that doesn’t account for the loss of one person.
The other issue is that if people learn they’re not necessary for a meeting they stop coming, which I assume is the intention. However now, you start kicking out important people from the meeting, such as the executive authoriser who was there specifically for that meeting.
In the post these issues was explained as the experiment failing. I would look at it from the other direction, it’s a failing of the processes to have a dependency in a single person.
As CGP Grey often says, one is none.
Now don’t get me wrong, I’m not saying you need two (or more) executives in the meeting. I’m taking the broader picture. Does everyone really need to be in the same room at the same time? In my experience I would say 90% of the time the answer is no.
Instead the major discussions should happen before the meeting, on your preferred collaboration tool. Any reading material can be distributed before hand and consumed at your leisure. If someone has a vested interest, such as an executive authoriser, they can raise any concerns before anyone steps in the room.
The meeting becomes a formality to say “a decision needs to be made by this date and time”. It’s more like that cliche moment in weddings in movies where the vicar says “Speak now or forever hold your peace”. The meeting should be 5 minutes tops.
The only other time people might want to meet at the same time is if something was being presented, such as a town hall or a sprint review. In those situations you should ensure that those meetings are recorded and published so that others can view and ask questions later if they were interested, but weren’t able to attend.
This leaves everyone free to work on what’s important, when it’s important. Not spending their entire day in meetings being presented material they could have accessed at any time. Or using time less efficiently because they’re winding up to a meeting.
But, as the original post admits, this may only work in a Google-eque business process utopia.