A couple of years ago, the owners of a company stuck in a no-revenue-growth and high G&A environment for the previous five years, asked me to work with the company executives to figure out how they could renew themselves and start growing again.  One of the things I do, part of the Ideasphere diagnostic process is to look through a collection of e-mails between the Sr. Executive in charge and his operating managers (selected and provided by the Sr. Executive himself) and sit through a few executive and other meetings as an observer, again selected by the Sr. Executive.  Within a day or two I can usually find the initial root causes of the problem and outline some immediate steps to take.

The Sr. Executive graciously agreed to the process and provided me with access to a few e-mail chains to review as well as invitations to a couple of “critical” meetings.  As I started reviewing the e-mail chains, the old adage “God is in the details, so is the Devil” kept running through my mind.  I know it’s a cliche, but it’s been drilled into my head from early on in the military and in my development as an executive so after reading the initial set of e-mails I was extremely impressed at the level of detail this Sr. Executive was involved in.  After all, hands-on involvement and attention to detail is a characteristic of successful leaders from executives like Jack Welch, Steve Jobs, and Bill Gates to military leaders like Patton, Nimitz, Schwartzkopf, and Petraeus.

But then something funny happened.  As I read through more e-mails, my admiration turned to surprise and finally disappointment at the level of micromanagement behavior this Sr. Executive displayed.  The result of the micromanagement behavior was one of the main reasons this company was stuck and the change had to start with the top managers.  Having been in the position to give feedback on micromanaging a couple of times over the years, I knew the immediate response would be “I am not micromanaging, I am paying attention to detail,” and since micromanagement is a negative term when used around other managers, I thought it would be best to explain the term through specific examples.  Below is an edited version of my talk along with real examples from this company. Please read on and decide;

Are any of these examples playing out in our company or the organization you lead?

As always, feedback is welcome both private via e-mail as well as public through comments on this blog.

Attention to detail is not the same as micromanagement.  The former is a behavioral pattern individuals display while the latter is generally a leadership disease.  One can be a micro-manager without actually being a person who pays attention to detail and vice verse.  The former, when properly leveraged, is a desired attribute for a good leader; the latteris the characteristic of an ineffective leader.  Let’s face it, if a leader is not trained and conditioned to empower, mentor and allow her staff the latitude to make honest mistakes, or generally lacks the desire to do those things, she is probably already a micro-manager.

Rather than focusing on the important things in need of the leader’s attention (Steve Jobs was legendary for driving every detail of the user experience), micromanagement behavior is often a tool used by insecure or incompetent managers to abuse people over minutia and to shift the focus of conversations from the leader’s responsibility to the employee.  Micromanagement is the tendency of executives to manage minutiae they are comfortable with across the organization regardless of their position and role, or the people who are available or responsible to handle the actual work.  To cure the disease leaders must shift their thinking and support behaviors like Teamwork, Mentorship, Skill Development, Empowering, Trust and Verify, and Responsibility instead.  Leaders must believe their people want to, and can, be valuable, and they want to matter.  But it has to start at the top.  If the Sr. Leaders do not demonstrate the right behavior, the rest of the organization, taking their cue from them, will not do it either.

For example, the Sr. Executive wanted to know the status of various initiatives every day at a detailed task level and demanded to be copied on all timeline reports from dozens of projects across the company.  Then at random intervals he would pick a random report, search for and find a task that was behind schedule, and call the project managers to verbally abuse them for being behind schedule, most of the times without any context on why the deadline was missed, or changed, and some times from a report that was three or four days old and no longer relevant to that task status.

Now don’t get me wrong, I understand the need to keep to timelines; it is a core principle of the SMARTT religion (Specific, Measurable, Achievable, Relevant, Time-bound, and Trackable) of which I am both a preacher and disciple; but, timelines time-bound against what?  There is S.M.A.R. before T.T.  A list of all the major activities the organization is pursuing and all the tasks that are late in every project is a sea of data that adds no value if the late tasks have not been identified as critical, prioritized against the myriad other initiatives with timelines, and pursued through the people that own them rather than based on a simple report.  Besides, depending on what the executive team agrees the priorities are, and what resources are or can be made available, the level of commitment to deployment, etc. every single timeline can be, and will be at some point be changed.

Even though he talked about Quality, this executive had an obsessive belief that to get things done they had to be done quickly, so he pushed artificial deadlines regardless of the complexity of the challenge or the impact on quality.  Of course, as I have observed repeatedly at many companies, without the right context, the “get it done now” approach does not always solve the problems.  More often it has the opposite effect.  Rushing the launch date of a product feature to meet a client’s immediate need, does not solve the fact the company does not have a consistent Product Development methodology or follows a roadmap.  It just delays the inevitable failure of the overall approach for a little while, and then it simply returns with a vengeance.  The pattern was consistent.  A project manager, a software development team leader, and a QA person would provide an estimate on a feature; then the Sr. executive would cut it half, or sometimes by two thirds and tell the project manager to enter that into the plan.   Then when the date was missed there would be an all-hands-on-deck meeting so the Sr. executive could berate everyone involved.  Being a big believer of the Agile Methodology myself, observing this approach to determining deadlines just made me cringe.  Of course the plan never worked and the inside joke was that the dates were there simply to be missed so the Sr. Executive could come in and exercise her right to scold the team for missing deadlines and to tell them they did not meet expectations.

Again, not to be confused with the need for organizations to move faster in a global competitive environment, but there is a reason nine pregnant women can not give birth to a baby in one month.  Some things are just not results of an arithmetic exercise and have to go through a process of development and maturation.  By not being patient (or understanding it for that matter) with the process of software development, the executive contributed to the chaotic environment the division operated in.  Product releases were frequently missed, or introduced new bugs because of unintended consequences, leading to increasing customer dissatisfaction and the reluctance of any customer to be a reference.  To compound the problem, most employees, after the initial valiant attempt to meet the deadlines, resorted to cutting corners or simply just ignored the project plan and worked at whatever pace they thought was “fast enough.”  That, in effect, made any attempt to hold people accountable for deadlines almost impossible.  Eventually the good employees just got tired of being berated and left.  The employee turn-over was so much higher than the average that recruiters were cutting their rates to have this company as a client.

And then there were the all-hands-on-deck meetings…

This executive would call meetings and summon entire project teams to his conference room so he could “personally fix the problem since no one else seems to care about deadlines or knows what they are doing.”  I sat in a couple of those meetings and it was painful.  The reason the problems kept coming back was because crucial conversations and real teamwork never took place, and this Sr. Executive continually rejected the input of his most valuable resources, his employees, in favor of his own personal opinions.  Just like what I found reviewing the e-mail chains, in many cases people jumped to providing a quick solution to look good in front of the executive before they knew what the real problem was, without asking people with expertise for their input, or ignoring the commentary of any one who disagreed, regardless of the validity of the response or the depth of knowledge of the people contributing.

In every one of the meetings I attended, the perceived or designated “leader” mimicked the Sr. Executive’s behavior and proceeded to drive decisions and dates without framing the problem, or asking for others’ views of it.  The leader did most of the talking, rather than most of the asking and listening, and when the people in the meetings attempted to provide a well thought out answer to questions, they were dismissed, and rather dis-respectfully if they could not complete their sentence in a few seconds. The meetings went on for the prescribed period, minutes were taken, and a status report was created for the Sr. Executive to read, and everyone left them satisfied something was accomplished.  However, to the outside observer, none of the root problems were really solved; some information was exchanged; the superiority of the leader was confirmed; a superficial victory was declared; and the troops were dismissed.  Until the next time (which usually came every couple of weeks).

I am all for teamwork and collaboration and meetings are a great way to do that.   I write often about effective meetings and frequently prescribe collaborative and cross-functional projects as a means to solve some vexing problem.  However, if every problem could be solved in a one hour meeting, or by pushing through it with strong opinions, devoid of facts, or a view and analysis of the root causes, I and other change agent executives like me would have been out of a job a long time ago, and the team this Sr. Executive had in place would have solved them as they came up never to be seen again.

I can’t share what happened next but here is a hint.  Maybe I am just old school, but if this was a company I was the owner of, observing those meetings would have been the proverbial straw that broke the camel’s back.  I would have called the Sr. Executive into a meeting and would have held a meaningful conversation about his “I am an executive therefore I am a GOD who needs no input from you peons,” attitude.  Not a nasty conversation, but rather a crucial conversation in the spirit of renewal, growth, and transitioning the company to the next level.  Then I would ask the management team to define no more than a half dozen projects across the company that demanded their complete attention and make discussion of those projects part of their weekly staff meeting.  All other projects would be assumed OK, unless a project manager or project sponsor escalated an issue to the executive team based on a predefined Risk Management Assessment matrix.

But that’s just me!