“Who’s got the monkey?” in IT and the other side

In this post we are going to talk about “Management Time: Who’s Got the Monkey”: how it applies to IT and what can be done by those who are not in the management side.

The article “Management Time: Who’s Got the Monkey” was originally published in Harvard Business Review by William Oncken, Jr. and Donald L. Wass. We are going to do a recap about the article, but I recommend to check it some time as it is a great article.

“Who’s got the monkey”

Time management is a daily issue for managers, even with full agendas and issues to solve, why does it feels like that amount of work is not reflected in the end goal?

If we check at the agenda, we can separate the work into 3 different kinds.

• Activities requested by the boss.
• Activities requested by peers.
• Activities chosen by themselves (managers).

That’s a normal agenda, but the problem comes when time that was not scheduled tries to makes room, and that time frequently comes from others' requests.

Imagine the scenario when a peer comes to the manager to report an issue.

It is possible that the manager doesn’t have an answer in that moment so, the manager compromises to come back with one. At that moment, the monkey has moved from the peer to the manager.

Now the responsibility to take care of that monkey is in the shoulders of the manager and the manager needs to make room in the agenda to take care of it.

Working in a team means having several people coming to you with requests, questions and issues.

And the manager needs to find time to take care of all of the monkeys that were passed by their peers.

Trying to manage time in an already busy agenda is stressful and, to add insult to injury, now imagine having to find time to take care of others issues and questions.

This will eventually have an impact on your own productivity and personal time.

At this point, I think you get the idea of what is a monkey and the consequences of accepting one or many at once.

Let’s stop for a moment and think about it: I don’t mean that managers shouldn’t help others since the intention of working as a team is that everyone can work together in order to achieve a common goal; it’s not a problem about doing it or not about a problem of finding the best way to do it.

The next time a peer comes with a question or an issue ready to pass that monkey...

... stop it!.

If there is no answer at that moment, the best thing to do is to schedule a meeting with that peer.

The difference between taking care of that monkey and scheduling a meeting is that the point of the meeting is not just to get an answer but also to teach that peer to take care of that monkey. At first, it won’t be that different as it will take time from the manager’s agenda, but the difference will be in the future: your peer will be able to take care of that monkey on their own.

Monkeys in IT

The original article was published in 1974 and, considering how we can relate to the content nowadays makes you think about how this issue is repeated in each generation.

If we talk about the IT industry and project management, you will find countless methodologies, models, and different topics created to help you achieve your goals but, in the end, you will be facing the common scenario that produces this issue. The moment you have a question that needs answers you have just accepted a monkey.

If you are in school, you might have questions for your professor, your classmates, or anyone that you think might be able to help you and, as a consequence, you are passing monkeys to others.

Once you become a professionist, doesn’t mean you stop having questions and issues; I actually think is the opposite since it becomes a daily thing with business questions, project questions, requirement questions, new technologies, best practices and an endless list of topics to have doubts.

Does that mean this is an endless issue? The short answer is yes, but the positive answer should be that we can do better.

“Who’s got the monkey” talks about the management side or the side that gets the monkey and the answers but, what happens with the other side? what can we do in order to improve and minimize the amount of monkeys we pass to others? With that question in mind, let’s talk about the next topic.

The other side (I’m not a manager)

The moment you have a question that needs answers, you have just accepted a monkey. I don’t think is bad to have questions, but what you should consider is if you already did everything in your hands before passing that monkey to someone else.

Let’s try to come up with some ideas to handle this in a better way.

Planning

The first way to fix the monkey issue is to avoid it from the beginning: before starting any work, make sure you have all the information available to finish your work by asking questions and making sure you understand everything you need to do.

Ask, verify, and research

By passing a monkey, you rely on the other to find the answer and there is nothing wrong with asking if they already know: that might actually be the quickest solution. Ask if they know the answer, but don’t pass the monkey yet in case they don’t.

Double, and triple check the requirements: sometimes the answer is already there, it happens that, sometimes, we missed it.

If the answer is not there, research, look for previous related work, documentation, on the internet and anything that might help you get that answer.

Pass the monkey, but provide alternatives

Passing the monkey is expecting others to make your job but, if you did all the previous steps, it is possible that you already have enough background to pass along with the monkey so the other person, by using just the information you provided, might be able the give you a quick answer in that moment, or at least, that information will be helpful to find the answer.

There is always something to do

Even though you have just passed the monkey, it doesn’t mean you should just wait for the answer. There are plenty of things to do in a project: finish other things related to your work, ask your peers if they need some help, or even work on the documentation.

Conclusions

While the original article is heavily focused on the relation managers and subordinates, I tried to be a little more open in that area, mostly because I think this is something that is replicated not just in that scenario.

I already mentioned this, but I think is one of the most important points: working as a team means to work together to achieve a goal. As a consequence, we find ourselves asking questions to each other: peers, developers, managers, clients, and quality team because, while it is the same project, not everyone has the same knowledge and abilities.

While others might have the answers, it doesn’t mean we need to rely on them for everything: having knowledge should not be burden and we should make the compromise to learn as well and, when the time comes, help others achieve that knowledge.

It is a great topic and, once again, I invite you to look for the original article since it has even more detailed information and there are even more articles related to the topic.

And that’s it! see you in the next post.