Imperfect Leader #1
On the proper care and feeding of monkeys
When sports players retire to become team coaches, it’s torture for them to watch their teams struggle. They have the knowledge and the experience, and could easily step in and help. But of course, they can’t.
There are physical obstacles: from not wearing regulation kit, to not being registered as a player, to just being old or out of shape. No matter how badly a team is losing, their coach isn’t stepping into the pitch with five minutes to go to score the equalizer. They are forced to watch and take notes, to turn losses into lessons, to do better next time. A coach earns their keep by being a force multiplier: helping the whole team get better over time. Not by solving individual problems themselves.
When programmers become managers, there are no such barriers.
Failure modes
As a new engineering manager, especially without good guidance, and even worse in a hero culture, there can be a lot of pressure to keep solving tactical problems by stepping into the coding arena.
See if any of these sound familiar:
A developer has been stuck on an issue for several sprints. You know the codebase inside out and decide to help out by taking over some of their tasks.
A legacy service is unreliable. You ask the team to loop you into every code review until the situation improves. Nothing ships without your approval.
The team decided to try an approach that’s new to them. You’ve done it before. You agree to write code “in the beginning” to get them off the ground.
A deadline is looming and the team is behind. You join the coding effort.
Something is really poorly implemented. There’s so much wrong with it, you can’t even begin to explain. You go home and code a better version, then bring it to the team so they can see what good looks like.
As a person who’s done all of the above, I believe they’re all wrong most of the time. Four reasons:
The more time you spend coding alone, the less time you have for your team and peers.
The more you do individually, the less opportunities for your team members to learn and grow by doing it themselves.
Your solutions may not be, in fact, any better.
There’s a good chance you’re busier than you think, and struggle to finish the task on time. That makes you a blocker for your own team. Rather than helping them be faster, you’re making them slower.
Under pressure
I mentioned pressure before. Sometimes, it comes from within. As a new manager, your biggest skill is probably still coding. It can feel wasteful to not use it so you seek out opportunities to code impactful things. But sometimes it comes from outside. Your reports may actually ask you to participate, or to solve other things for them. And that’s tricky because it is your job to help them. But you may end up with work on your plate that doesn’t belong to you, depriving your reports of growth opportunities. Fishing for them when you could be teaching them how to fish.
Monkey business
I read an old article that uses monkeys on backs to illustrate work. There’s a limit to how many monkeys one can carry on their back, and by taking other people’s monkeys one easily buckles under all the weight. How does this happen? How to identify the precise moment when a monkey jumps from one back to another, and how to keep monkeys where they belong or get rid of them altogether?
To quote the article:
Let us imagine that a manager is walking down the hall and that he notices one of his subordinates, Jones, coming his way. When the two meet, Jones greets the manager with, “Good morning. By the way, we’ve got a problem. You see….” As Jones continues, the manager recognizes in this problem the two characteristics common to all the problems his subordinates gratuitously bring to his attention. Namely, the manager knows (a) enough to get involved, but (b) not enough to make the on-the-spot decision expected of him. Eventually, the manager says, “So glad you brought this up. I’m in a rush right now. Meanwhile, let me think about it, and I’ll let you know.” Then he and Jones part company.
Let us analyze what just happened. Before the two of them met, on whose back was the “monkey”? The subordinate’s. After they parted, on whose back was it? The manager’s.
That manager couldn’t help themself but put on their sports gear and step onto the pitch, back crawling with monkeys.
The article shows its age, with hints of authoritarian management, but it does a great job outlining the importance of keeping monkeys where they belong as a means to keep the manager from becoming a bottleneck, and to help reports grow through caring and feeding their own monkeys.
Here it is, it’s not a long read and it changed how I approach work with my reports. I share it with leads and managers that I manage and mentor, and hope you find it useful too:
Management time - who’s got the monkey?
Thank you for reading, and until next time!