Anyone who works with me will know that I believe the solving problems quickly with the most immediately obvious solution (or perceived best practice) will more often than not lead to long-term damage being done.
I’m talking here about managers, consultants, coaches, leaders etc. generally people without any skin in the game, but I’ll come back to that later.
The reason behind this fear are well documented. Peter Senge called it the Shifting the Burden archetype. Dave Snowden talks about complacency leading to catastrophic failure (the boundary between simple and chaotic).
However the point of this blog post is to explore where the burden of proof must lie with respect to the work done by managers. Assuming of course that the work managers do (and the others listed above) is largely based on intervening on a group of people in an effort to make things better without doing harm.
So the choice for me becomes simple. Does the burden of evidence lie on people to prove that the work the manager is doing has done them harm before the manager will stop doing it or is it that managers should assume all work will do harm (in the long term), and they must work to prove something is safe before doing it.
It is the kind of argument Nassim Nicholas Taleb uses about global climate change (in the book Antifragile). Should we wait for scientists to prove climate change or rather assume it is true until someone can show the effect of our CO2 emissions is harmless in the long term.
Back to our discussion about managers. What this means is we don’t have to wait to prove something is or isn’t causing harm. If there is a risk it will do harm, then we need to reduce the impact of that risk now.
In a recent management team retrospective we talked about some feedback from a team. That team felt that we often didn’t follow up on promises of things we would do for them. From our perspective this was due to changing priorities. So it was clear we were failing to properly set expectations and communicate well with that team. This was leading to a long-term problem with the trust they had in us to help them.
Following this insight we started to look at what other stuff we were doing might be causing the teams confusion. The discussion moved to a newly created Trello board that contained a list of items that we may or may not do to help one of the teams. Now there was no direct evidence that by listing these items on a board that we were setting expectations that these things will be done. However equally there was no evidence that this wasn’t the case. So what should we do?
The answer I propose is rather than debate whether something is the case or not. We accept that as a team we don’t know and instead manage the risk. In this case we look at the worst case i.e. the team has an expectation that everything on the list will be done by us at some point and act to remove that doubt with a simple conversation with the team.
So let me try and summarise my thoughts.
- As a manager, coach, consultant, leader, scrum master etc. the burden of proof lies with us to show how the work we do causes no harm in the long-term.
- We can avoid debates about whether something does or does not cause harm. We accept we don’t know and instead work to reduce the impact of the worst case outcome.
- Without skin in the game i.e. unless you share the risk with the group of people you are working with, then you should reduce the impact of the worst case to zero i.e. make it “safe to fail”.
- The gold standard for all managers, is that you own the worst case outcome, i.e. the intervention you make only has a positive outcome for the people involved and that you take all the worst case risk yourself.
The last two points are a bit of a jump. So let me explore with a quick example.
If you have a team working on a project with a deadline for completion. For example a non-moveable deadline related to a specific seasonal sale. Then as a manager, your aim is to give the team the best possible environment to achieve this goal, while reducing the impact of failure. That’s not to say you can reduce the chances of failure, just the impact that failure would have. Giving the team the message “do your best with the limited resources available” is a good thing. Making sure the team can have a minimum viable product in place well in advance of the deadline helps reduce the scale of the risk i.e. we can still meet the deadline we just don’t launch with one feature. Taking the pressure off the team, giving bad news yourself etc. etc.
For me you can derive a lot of agile from this basic principles of what it means to be a good manager. The irony of which isn’t lost on me given the generally negative perception of managers by the agile community.