Being a leader, not a micromanaging editor: 3 patterns to avoid
As a manager, big company or small, the opportunities to lead are everywhere. Too often though we can fail to lead and fall into the trap of editing the work of others–critiquing, tweaking, or otherwise mucking with what is discussed or delivered, rather than stepping back and considering if we are truly improving on the work or just imprinting upon the work, or if we are empowering or micromanaging.
Please don’t forget to try the new poll for this post here.
Every manager faces a constant struggle as the work expands and time shrinks—it seems faster to just say “the answer” rather than let “discovery” happen organically. Finding this balance and challenging ourselves to lead not edit is difficult but key to the long term strength of the team and ability to scale as a manager.
The challenge gets to the core responsibilities of management. Management, at every level, is about the effort to frame challenges, define end states, and allocate resources to navigate between them. If the work requires smart, talented, creative people, then more than anything you want to enable folks on the team to create. When people create, they want to show off their creation and keep creating more. Redoing, reworking, and revisiting can not only drain resources and energy, but sap creative people of their desire to create.
Micromanaging by editing
Most would probably agree that the easiest and most damming insult directed at a manager is the dreaded label micromanager.
Looking beyond the rhetoric, the term editor does more to explain the dynamic. Editing the work of those you manage disempowers the team, removes accountability, and in general reduces motivation. Editing the work of others is easy—it seems like anyone can change the UX, add a feature, rewrite some text, or tweak a slide. The creative effort is coming up with the work in the first place from a blank sheet, so to speak. Of course there is a role for editing (which itself is a noble profession), but in the complex works of product development there is a great deal of context. In reality most everything follows an iceberg principle, with far more than meets the eye—the complexities and realities that came to light during creation might not always be visible once the work is packaged up for management.
For a variety of reasons theorized in this Wikipedia entry on micromanagement, managers might resort to an excessive focus on details or dive into details arbitrarily. A common element is the manager taking the work of a team member as a starting point and substituting a flawed process of editing for what could be helpful, insightful, and valued interactions more defined by proper feedback or coaching.
From the perspective of the manager, there are a number of common patterns that arise and are indicative of management needing improvement.
- Receive and rework. You glance at your mobile and that updated specification shows up. While there is an expectation to read the spec and provide feedback, the sender was probably hoping for a job well done reply. Instead, your message back is a quick “did you think of X” or “I don’t like the way you say Y”. This gets even worse if the feedback is about the presentation of the information rather than the information. You hope to be improving the work but inadvertently spin up a PowerPoint or Excel workshop session. There might very well be mistakes or significant missteps in the work. Step back and deliver a clear and focused message on those and just skip the easy adds or tweaks. Suggestion: Make a simple rule for yourself like “never suggest a different format of a report” or “never add more work unless you also take away work” or “save feedback for the critical or strategic elements”.
- Delegate and tweak. When you delegate work to the member of the team, your job is to clearly frame success and describe the objectives. Delegation of work can be as simple as scrubbing the feature list or as complex as asking someone to take on a group-wide stretch assignment. No matter what the scale of delegation, getting out of the way after delegation is key. When the results are in, keep in mind not the results free of context but look at the results in the context of how you delegated the work. If you see mistakes or missteps, ask yourself if you were clear or your delegation caused the problems. Editing the work that ignores the context will tend to alienate folks as they keep thinking “would have been nice if you told me that up front”. Leading is actively taking responsibility for the lack of clarity and triaging the real marginal gain from tweaks at this later stage. Suggestion: Delegate challenges and define success, but don’t delegate the intermediate steps or detailed output, making it clear where creativity is expected.
- Fetch and edit. The best work for creative folks on the team is when the problem is big and the solution escapes everyone. In these cases, as a manager you don’t know the answer. That’s stressful for everyone. The way to increase the stress is to ask a member of the team to build or create an answer for “review” or for a list of options and recommendations. We all know how this process can really go haywire. When one potential solution to an unknown is offered, the next step is to go back and rework it with the new learning, or “no not that rock, a different rock”. We also know that with a big unknown and a list of n possible choices, after a brief dialog the next step is to pick option n+1. Suggestion: Asking creative people solve vaguely defined problems can be the most rewarding work of the team, so don’t drain the energy by thinking you will know the best answer when you see it, driving folks a bit loopy in the process.
Leadership is more than editing
These patterns and others all share a common result—the more you do them, the less creative and engaged your team will be over time. Each time your employ the tools of editor, rather than leader, you encourage people to stop creating and focus their energies on trying to predict your editorial reaction.
Leading is contributing data and experience–share your related experience and let the allegory and discovery do the work.
Leading is coaching–share your observations and offer pros and cons.
Leading is walking through the action/reaction decision tree—share the path, not just the destination.
Leading is reiterating accountability in so many cases.
Leading is knowing when the potential for learning and growing outweigh the risk of failure.
Leading is realizing there a few perfect answers and many great answers.
A goal of leading is to amplify your skills and experience while also growing new leaders. If you’re not giving people room to uncover their own way and ultimately solutions, then you’re creating a staff organization for you, not the next generation of leaders. As valuable as your experience is, don’t forget that the minutes or hour you spend editing compare to days and weeks often spent getting the work into a consumable format. The bigger the investment the more expert people are, even if they would benefit from coaching and experience.
Over time as you work to keep focused on leadership rather than editing, the team grows stronger and more self-reliant. Members of the team worry more about getting the best answers and work and less about wondering what management might be after. More work gets done. Members of the team are more empowered. This positive feedback loop continues to improve every aspect of the team.
Three questions – insights from readers
In the post, Combining guessing and planning in product development, our resident big data researcher at Stanford proposed a few questions in order to reflect what those reading this blog have to say. Considering the overall clicks on posts, we’re seeing about 1-2% of readers participate in this “for entertainment purpose only” poll.
The poll on this new post can be found https://www.surveymonkey.com/s/VLHQSBJ, please participate and share your perspective.
Thanks to those of you that took a minute to answer our three questions. We saw a few noteworthy points from the results:
- Roughly half of you have had skip level meetings in the last six months.
- On average, you spend about one fifth of your project schedule planning.
- Over half of your plans are represented in your final products.
- The most popular planning tool was ‘Short Product Plans’ (61%) and the least popular was ‘Market Requirement Documents’ (31%), though a few of you also mentioned ‘customer stories’ and ‘prototypes’ as key planning tools.
Watch this space for results from the next survey!