Photo by Chris Fuller on Unsplash
“Hire people who are better than you are, then leave them to get on with it” - David Ogilvy
Buster: Boss, can we chat a second in private?
Project Manager (PM): Sure. What’s up?
Buster: This team is amazing—you really have world-class engineering talent that can be unstoppable if unleashed. I am glad I am on the team. But…It would be better if we could find a way to increase the level of trust you have for us so we can do great things together.
PM: <<Pause>> I trust you. You’ve done everything I asked. What do you mean?
Buster: The problem is we are doing everything you ask precisely how you want it done with significant oversight and external control. The team can’t breathe, much less invent.
PM: But you know I need insight into what the teams are doing.
Buster: Okay we can help you find the complete data set you need, but right now in status meetings we are answering your $5,000 questions while there are $1M questions in our teammates’ heads that remain unaddressed. We are consistently pulled down into the weeds with program leadership and we’d like a shot to crush your objectives from the bottom-up. Let us own it and I promise we will find a way to both win and keep you informed.
PM: Let’s go through each specific example where you think I did this in detail, and I can explain what I am doing and why.
Buster: <<Chuckle>> <<Silence>> Oh, crap…you’re not kidding.
“I am going to have to fix you, manage you two on a more personal scale, a more micro form of management. Jim, what is that called?” – Michael Scott, The Office.
Somewhere between complete anarchy and soul-crushing micromanagement is your team’s sweet spot; although I don’t know where it is exactly, I know it isn’t at either end of that spectrum. And, unless both your hiring and developmental planning processes are completely broken, the fulcrum will be found a lot closer to anarchy than to Michael Scott’s “management on a more personal scale.” My conversation above was a real experience, and was the start of chronic, acute pain in my team’s relationships on that project. We never succeeded in finding the right balance between insight and oversight (oversight always means control) and it is not a project I ever refer to as a success story. The last act, that the PM wanted to go through each of my grievances in context and in detail, just illustrates how difficult it is for some leaders to keep themselves from swooping down from 30,000 feet to look at the single inch you are working on. The thought of leaning the team toward anarchy really terrifies some leaders, but the team’s success depends on shared ownership of the objective. You must let go as much as possible. You must uncage the beast.
Further on in the same project I found myself trying again and again to move management to higher altitudes. Later, more metrics, more reporting, more controls, which led to more stress, more turnover, and in fact more failures. This led to more metrics, reporting, controls, and misses. Enter the self-fulfilling prophecy—once we start down the path it will be almost impossible to give ownership back to where it belongs. Uncaging your team members is a necessity because the magnitude of the job is too great for any one person to get his or her arms around; in addition, it is unlikely that a single person will have the perfect lock on how to even achieve the objective, so we have to share ideas and rumble about them. On other posts I have put this in the context of the Industrial Revolution: that we need division of labor AND division of ideas. The fear is real, however, and there are many reasons people talk themselves out of delegation and these all culminate with the statement:
“It will just be easier/faster/better if I do it.” - you
This is the great trap. Every time this statement is said out loud a micromanager gets her shackles. If the work truly is too much for you to do, and you convince yourself that what you do and how you do it are the most effective and efficient ways to get the job done, then you are on a path to crushing souls. You are at risk of being the micromanager. The problem is that you, as the leader, are accountable for the deliverables your team will create; it’s risky, then, to let go, especially if you have had a string of successes at lower levels. When you have seen what and how to win, lived through the pain, and emerged as a clear victor, then you will be tempted to move the team before your single data point. Here some humility is required—your way isn’t the only one, and the team has had their own experiences of success to draw on. You want those different perspectives, I promise. I have found that the most effective ways to strike a better balance are to set and enforce expectations for the endgame (aka the vision); overcommunicate; and choose controls carefully. It is a nontrivial activity to plan the opening of cages.
What do you want the beast to do?
“Nobody succeeds beyond his or her wildest expectations unless he or she begins with some wildest expectations.” – Ralph Charell
The military has a concept known as the commander’s intent and it is a core tenet of strategic, operational, or tactical planning. A plan is known to never survive first contact with the enemy, so when the “shooting” starts, the team must be able to adapt to unknowns and STILL progress toward the single main objective—without the commander’s direction or even communication. In business circles, this is known as the vision or sight picture—where we are to see ourselves at the end of the activity. The commander’s intent describes such a desired end-state, and those in software development will see a lot of parallels to the user story: who benefits…what is wanted…why is it wanted. Why is so vital, because there may be times where the who changes midway, or the what cannot be achieved; when the teams must pivot during execution, understanding the why means they can still have forward momentum. We want a vision, an intent, or a user story so that we can convey how the world, or a small part of it, changes with our action. Your team needs a common understanding of the desired end state and a lot of ideas and flexibility on how to pull it off with or without your help.
In the paragraph above that starts with “this is the great trap” there were two elements we considered: what needs to be done, and how it should be done. Most micromanagement I have seen is about the how and not about the what. People tend to spend a lot of time, even if their teammates are on the path to delivering a product that is good enough, fighting with them on how they should do it. The vision/intent says nothing about methodology and honestly you should not care as a leader. Communicate the expected outcome, reinforce it when necessary, track it, help when asked, but lay off on dictating how it should be done. There are exceptions to this, such as when the particular deliverable has high process focus due to compliance mandates (aircraft safety, manufacturing repeatability, etc.), but in those cases these processes are written down; reference the process steps and then back off. Although exceptions exist, this is NOT where the fighting generally occurs; instead, it generally occurs when the individual just does things differently than you or I would, we think our way is better (or worse yet, right). Please think of this often: different is not wrong, and a leader must be ever vigilant against that bias. It is also important to talk about so the distinction between what and how are clear when setting team expectations.
Overcommunicate and measure
“The art of communication is the language of leadership” – James Humes
The two-way street on communication in a team sense is much about focus and status. The team needs to maintain its awareness, understanding, and push regarding the end-state; it also needs to know where it sits in relation to the goal. If the team is self-healing, then status awareness is quickly followed by collaboration and course corrections that don’t necessarily require your leadership. If the team is still maturing and not quite to the self-governance stage, then indeed you may have to provide some help to close the gap between where we are and where we need to be. Here is where some readers will say “a-ha!” You are a micromanager just like everyone else. You want people to tell you what they are up to, you want to measure their status and you want to fix them…don’t you trust your team? This is where the distinction between insight (knowing what your team is up to because you are a part of the team) and oversight (knowing what your team is up to so you can control the team) is critical.
Like so many things, your team will see the manifestation of insight vs. oversight as they see your intent play out in actions. Are you listening to learn and help or are you listening so you can steer all the things? Here is the big secret: if your intent is correct, your team will love telling you what they are up to. “Jen thanks for your report. You are killing it. I put your team in for an award.” Then ask how she is making it all happen and write it down as a best practice for everyone. “Sue, it seems as if you are a bit behind. What’s in our way? Is it me? What can the team do to help?” Then shut up and listen; you might just learn something. “Morgan, it seems as if we have lost sight of the prize; can we talk about what ‘done’ looks like? I’d like to understand how you see it.” Then (again) shut up and listen. Help them solve their own issues as any teammate would and pull in other ideas as needed. If your intent is incorrect and you instead want oversight, then the team will see from your actions that you are extremely interested in being the smartest person in the room. All the time. They will then defend themselves appropriately. You have then lost any advantage of having a team.
We all get that our bosses and teammates will need to see how we are progressing on a task, if for no other reason than someone is going to ask them “how’s it going?” In the best of times when a team is succeeding the leader can use the opportunity to send unsolicited positive feedback up the chain about your team and its progress. In the worst of times that data may save you from some micromanagement. To report status requires tacit agreement on the complete set—necessary and sufficient (read sufficient as the minimum amount of data required). Reporting should be noninvasive, so it should leverage as much as possible the processes and tools the team uses to manage its own affairs and should target only those things that really matter.
I HAVE A MAJOR PET PEEVE IN THIS ARENA (okay, two)—when managers request reports in formats that are completely different than anything the team uses to manage its own affairs it drives me batty. If the team is successful using a word document and three excel spreadsheets and is completing the mission, why would any leader make them translate that into a PowerPoint chart? So what if they are writing monthly production targets by stacking bones in a dish full of chicken feathers? Just learn how to use their tools to track reporting—a successful team is clearly measuring what matters and their tools facilitate the right level and kinds of communication. Oh, for number 2, metrics are for your team, and not its leaders, to decide. Leaders tend to measure what is easy to measure or what looks sexy on charts, and these two qualities have little correlation to what matters. Uncage! The! Beast! The anarchy I advocate is to let your team decide what to watch and how to communicate those things to each other and to you. If you need something different it opens a discussion and does not close it. Okay. Back to DEFCON 5. Glad that is off my chest.
Nudge when needed
“Anarchy…that I run!” – Dr. Horrible
I feel uncomfortable with this part because it has the most potential to cross the line where your anarchy/micromanagement balance point is. Honestly, I am not sure I have ever gotten this exactly right. INCOSE and PMI have artifacts that talk about the need to implement controls when the metrics indicate that the team is off track. The word “controls” is just terrible for my purposes here, obviously, as it implies despotism. The word sets up an image that, when your team status comes back with negative performance, or a downward trend, that there are discrete levers you can pull to turn things around. It also implies that you as the leader know what these are and how hard to pull. Forgive me but based on my experience both of those are bullshit. The complexity of what we do as engineers is not this simple. Let’s call controls “calls for change.”
“Okay, we all know why we are here. Let’s get to it” is the best way this tends to work. Your teammates are aware that things are not going well, that there are parts of the project that are slipping, and that our ability to meet our objective is in jeopardy. As a team you review the metrics and trends and try to get to root causes, which should be the things that drive the important metrics (if not, or if things are unclear, then the team should fix what they are measuring as part of this process). Define the problem, agree on the problem statement, and identify root causes, then start designing corrective actions together as a team—you know, systems engineering disciplines. This is where it is MOST important that you do not drive the how—focus on the vision and then contribute as a team member. “What we need to do is…” is the WORST thing you can do as a leader because you will immediately anchor the team to make you happy, which may or may not fix the problem at hand. The nudges/controls need to originate with the team for one reason: we are all in this together, we created the conditions for negative performance, and we will live with the consequences of what we do. In this state you need innovation and invention, so you are no more important than any other team member.
Where’d the word “Empower” go?
The word is gone. Erased from history. I love to bash words in general, but this one implies that my team has no “power” unless I enable them to have it, which is the most micromanagey way to look at the situation I can think of. “Boss, may we go invent and achieve?” “Yes, I am glad you asked. You are empowered. I have spoken.” The meaning is meant to be the same as my completely irresponsible use of the phrase “uncage the beast:” we want to give max responsibility to our team to achieve the objective. The difference is that “empower” implies permission is granted as a positive act; uncaging implies that the team is being held back and down and you need to simply get out of the way with your negative energy. While you must be deliberate about where your team is balanced between anarchy and soul-crushing micromanagement, don’t empower--uncage!