The title of this post is one of my wife’s favourite sayings.
It’s her justification for not wanting to get pulled into a situation that didn’t concern her.
The saying is based on a Polish proverb that actually states it the other way around,
“Not my circus, not my monkeys”
I prefer my wife’s version.
“Not my monkeys, not my circus”
Leading with the monkeys 🐒 reminds me of a 1974 Harvard Business Review article, “Management Time: Who’s Got The Monkey?”
An oldie but a goodie.
Written at a time when Taylorism was alive and well as a command-and-control management philosophy, the article focuses on
- Time management concepts for managers: Why managers never seem to have enough time.
- The “monkey-on-my -back” metaphor representing subordinate-imposed time on managers: What managers can do to keep those monkeys off their backs.
Looking at the article through an Agile lens, I can see how its concepts and mitigation approaches can be extended to embrace 21st century realities.
Extended beyond the classic top-down management initiated actions to bottom-up team initiated actions aligned with Agile ways of thinking and working.
Here are a few examples.
Empowerment and The Missing Piece
- Stephen R. Covey’s 1999 reboot of the 1974 article recognized how the employee empowerment movement of the 80s and 90s had interesting implications for the original article written 25 years earlier.
- Empowerment and the accompanying trust that it depended upon between management and employees, are an easy bridge to today’s Agile ways of working with its decentralized decision making and collective accountability.
- A less obvious but more powerful connection with Agile is the role that the readiness of subordinates and staff to accept empowerment, plays in effective delegation and empowerment.
- In the 90s, I referred to empowerment of subordinates or staff who were either not ready or not even willing as “reckless empowerment”. To me, staff readiness and willingness is the missing piece in the original article.
- Covey raises the possibility of this missing piece by questioning the belief that it would take less management effort to simply push back and give the monkey back to a subordinate than it would take to keep the monkey and solve the problem for the subordinate.
- His point being that teaching subordinates how to solve their own problems was no easy feat back then under a command and control regime. A regime marked by learned helplessness on the part of subordinates and an unwillingness to give up any control on the part of managers.
- Fast forward past the 70s, 80s, and 90s into today’s world where continuous learning and personal development are the norm with Agile ways of working and the missing piece is no longer missing.
Collective Accountability and Ownership
- The original article and the Covey reboot both focused solely on management alone trying to keep monkeys off their backs.
- In reality, monkeys don’t discriminate whose back they jump on to. Managers, non-managers, team leads, team mates, other teams. They’re all fair game for monkeys.
- With Agile ways, the job and responsibility for corralling monkeys can now evolve from management to the entire Agile team and include the Scrum Master as well if the team is using Scrum.
- No one likes to have a monkey on their back. Not just managers.
The Disintermediation of Information
- Back in the 70s, information was power. The more information you hoarded, the more power you had. Managers monopolized access to information so that they could retain power.
- The lack of information amongst subordinates required to make decisions or solve problems was probably a key contributor to passing their monkeys to their managers.
- With the advent of the Internet in the 90s, access to information had a path to liberation. The genie was out of the bottle.
- Couple that with Agile’s preference for transparency and self-management and you have additional impetus and ways to keep monkeys off everyone’s back.
During a recent coaching session with a Product Owner (PO), I had the opportunity to introduce it to the PO who was struggling with having enough time in the day to get “all her work” done. Even putting in many 11-hour days was not enough to deal with everything on her plate.
As we dissected what “all her work” was, it turned out “her work” was not only “her” work but also much of the individual “team members’” work. She was spending much of “her” time solving “their” problems for them.
I suggested she read the HBR article.
A few days later we were in a virtual team meeting together. At one point, the team’s software architect asked the PO if she could take on a piece of the work that he was unfamiliar with. A monkey was getting ready to jump on her back. She suggested an alternative approach right away that kept the monkey firmly on the architect’s back when the meeting ended.
Right after that, the PO messaged me over chat,
“Did he just try to give me a monkey?”
To which I responded,
“Nice job keeping the monkey on his back 😃”
We both agreed that was a GREAT article.
