Leveraging the Frog in the Pot
Everyone has heard of that metaphor of a frog in a pot of water: put the little guy in hot water and he’ll jump right out, heat the water gradually and he’ll just hang out there. The gradual changes are too subtle for him to perceive them and do anything about it. This explains why a lot of team environments are the way they are, and might even give us an idea about what we can do about it.
Despite many team’s attempts at defining what their approach is, either by building up volumes of guidance or templates or by distilling it down to a couple of key practices, the bottom line is that their approach, for any team, is an accumulation of the things they do every day. A mix of the effective things and the problematic things. Some that are precisely as documented, some behaviours that might go unnoticed but can have a significant impact on the results of the project. In most cases, any correlation to what is prescribed or declared as the official process is accidental at best.
Correlation to what is documented, though, isn’t all that important most of the time (unless you are talking to a savvy auditor). What is important is the correlation between what you do and how well you can deliver value on your projects. The process or methodology that you have at the moment is precisely what the team does every day, with all of its templates and variability and special cases and heroic efforts and dysfunction. There are probably a few keystones that are holding everything in place, with a wide range of interpretations by everyone on the team of what is good and not so good. Add outsourcing or remote teams or cultural diversity to the mix and this wide range is virtually guaranteed.
It’s the approach you have, for better or for worse.
And in most cases, to bring us back to the frog metaphor, you are getting the product built, but are completely unaware of the inefficiencies and the problems your approach is causing, and completely unaware that the temperature is rising.
Because the temperature has risen slowly, imperceptibly, over time. Dealing with an emergency fix for one customer and not quite restoring the fidelity of the system afterwards has slightly reduced the quality of your configured system. Overriding the ideas of the new gal on the team as too radical to try before really hearing her out has sent the message that maybe this isn’t the right place to be innovative. Telling the customer that you know what’s best for them has left them wondering whether they’ll be able to do their job when they get the product.
Nobody intentionally designs an approach to product development to be inefficient or ineffective. It happens that way unconsciously.
Most importantly, because it happens unconsciously, we don’t see it happening, the changes are too subtle for us to perceive them, we haven’t characterized the points along the way that have eroded our performance. It is just our status quo.
Contrast that to the pushback that is a standard part in almost any organization’s attempts at getting better. We’re all hardened against change, we abhor it. We’re the frog, screaming blue murder if anyone tries to get near the thermostat to turn down the heat.
Perhaps the right approach for getting better in our teams is to take a lesson from that frog. Not to change its behaviour or to its ability to perceive things, but to use those very attributes in a way that works to our advantage.
Just as subtle changes or events can go unnoticed even as they ‘raise the overall temperature of our pot’, we can seek out these subtle changes that can do the same, but in the other direction. We can start to make things better, changing things right under the noses of the team.
Got a tough challenge? How about asking for ideas from the people on the team that you rarely hear from? You will likely be pleasantly surprised by the variety and innovation that you get, and these people are going to feel that much more comfortable about coming out of their shell next time.
There are all sorts of things you can do:
- start a discussion about what the key differentiator is for the product you are building now (there’s a good chance you will be surprised at the responses)
- find an area of the system that has been nagging your team with ongoing issues, and work out ways to eliminate them
- celebrate the holidays of the cultures represented by everyone on the team
- sit down and work through a conflict that has been simmering between yourself and one of your teammates
With a little thought, you can probably come up with hundreds of small things like this: subtle, not a game changer in itself, but likely to lower the temperature, just a little bit. They might impact the relationships, or the approach you apply, or the product you produce. You don’t need a big change initiative, you don’t need permission, you won’t even need to schedule most of them in. Feel free to add your favourites as a comment below!
None of these are going to generate any pushback, but if you start to build these practices into your habits, you may soon find that the temperature has stabilized, and might even lower a bit. Talk about this approach with other team members, and you might start a movement: imagine people intentionally doing little things to make things better on your team.
And nobody pushing back that the temperature has suddenly changed. – JB