This past week, I had the pleasure of hosting my friend, Admiral Brian Hurley in my graduate Salesforce CRM solutions class at the University of Texas at Dallas. As we sat in our round table discussions, Admiral Hurley brought up a particular article that had not crossed my mind in many years. It happens to be one of the best-selling Harvard Business Review publications of all time. “Management Time: Who’s Got the Monkey” (original article here).

This HBR essay discusses the three types of management time. The first is boss-imposed time “used to accomplish those activities that the boss requires and that the manager cannot disregard without direct and swift penalty.” The second is system-imposed time “used to accommodate requests from peers for active support.” Finally, Self-imposed time “used to do those things that the manager originates or agrees to do.” 

As managers, we are constantly challenged with the simple fact that there is just not enough time in the day, but our teams seem to be running out of work to do. The idea is that there’s a metaphorical monkey, the problem, and people tend to trade off this monkey to others with no real solution. The article specifically tracks the relationship between manager and team member (in the original article referred to as the subordinate). “Subordinate-imposed time begins the moment a monkey successfully leaps from the back of a subordinate to the back of his or her superior and does not end until the monkey is returned to its proper owner for care and feeding. In accepting the monkey, the manager has voluntarily assumed a position subordinate to his subordinate.” The issue is that the team member is handing off a problem back to their boss when they should be solving it themselves. 

So how do we take on the task of getting the proverbial monkey off our back? 

Here are my main takeaways from the HBR article for my own daily business operations:

  1. Triage problems. Does it take a quick 5 second web search to figure out the answer or is it going to take a few hours to solve? A quick 5 second Google search can be redirected to team members but a problem that takes a few hours to solve might be a worthy learning opportunity for me and my team. 
  2. Encourage incorrect solutions.  I don’t mean to encourage bad programming. Rather, it’s okay to make a mistake. I would much rather have someone present a wrong solution to a problem than no solution at all. It shows drive and initiative. It also aids in the learning process. Students remember a question they got wrong on a test longer than the question they got right. It means the student will internalize how to solve this problem and the ethos that surrounds the topic for the problem at hand. They will be much more in-tune with the program and ready to tackle the next (similar) challenge. 
  3. Facilitate Q&A. Often people are unsure of what they don’t know. Sometimes people are afraid to ask questions out of fear that they will appear unintelligent; but that feeds the cycle. If they don’t ask questions, they never learn. It’s vital to the project to encourage our teams to ask questions and to not penalize them when they get something wrong. It is our turn to share the knowledge.
  4. Demand excellence. There is a difference between someone who knows how to arrive at the correct solution and tries but fails, and someone who doesn’t try. Demand excellent attempts. 

Despite the outdated reference to mail , I feel that these rules are still valuable today. In my graduate class, I strongly encourage leadership. Nothing is more powerful than a good leader who pushes team members to take the initiative to solve problems. Managers’ days are consumed with solving rudimentary issues that should not be on their desk. And I hear this from many of my colleagues. We want to foster a learning environment, but struggle with keeping others’ tasks from becoming our own.