What could possibly go wrong?

First off, business managers have some clear advantages over their technical counterparts.  They

• Appreciate the severity of deadlines
• Base loyalties on the individual rather than the position
• Can speak for the customer

But, because they’re not “part of the team,” they frequently introduce new problems on a scale  larger than the technical managers we saw last time.  They fall into a handful of categories.

• Poor Specification
• Mistrust
• Over-modeling

The specification problem stems from the fact that business people and technical people tend not to share substantial language.  When most people talk about management, this is where they focus most of the time:  Ensuring that everybody communicates effectively.

Because of the difficulty in communicating ideas as activities, trust erodes on both sides.  The workers avoid dealing with the manager because “he just doesn’t understand,” diverging further from the goals of the project.  Likewise, the manager pushes the team into draconian workflow, where everybody needs to clear actions and submit an unending series of progress reports.

Lastly, we all tend to focus on what we’re worst at.  So, when a business-side manager does involve himself in the process, they’ll often obsess over details and want every last issue resolved before anybody gets to work.  While this sounds like an exciting way to work, it’s usually a waste of time to, for example, explain how many nails will be used to hang panelling or how the Java runtime sorts its arrays.  They’ll often question things out of everybody’s control, delaying everything.

Like the technical manager, everything will get done.  But it frequently feels as if it’s in spite of leadership rather than because of it.

Now, next week, I’ll continue discussing the better comments I’ve gotten from Nayar’s issues with American graduates.  After that, I’ll return to this topic to sort of wrap things up (for now) by talking about what good management tends to be about (and, unsurprisingly, how eManagr frees you up from dealing with a lot of it–we do have a service to sell, after all).

Meanwhile, in anticipation of adding Twitter to our communications repertoire, some of  you have noticed that these Monday posts are now joined by a Thursday afternoon Twitter roundup.  It’s experimental.  I doubt the team here will Tweet live updates except possibly some tests.  On the other hand, we are experimenting with automatic features that may interact with Twitter.

If you’re interested in seeing it as soon as it happens, obviously watch this space and follow @emanagr.

There are people who understand what their team does well enough to keep tabs and smart enough to manage rather than interrupt.  If you have such a manager, ignore this post and do everything it takes to keep that job.  The rest of us see our primary facilitator make our jobs more difficult.

By looking at bad management, we can hopefully see how important a good manager is, and find a path to good management along the way.

When it comes to technically-oriented managers, there are two serious problems, one at each end of the spectrum:

• Micromanagement
• Neglect

Micromanagement is probably the more irritating of the two issues, the nagging need to spell out every part of a project in painstaking detail and then to see continua status reports to ensure that everything is done exactly as demanded.  This, of course, leads to some serious problems in turn:

• Collaboration benefits are lost.  The saying, taken to heart by the Open Source community, is that “all of us are smarter than one of us.”  Unfortunately, under micromanaging policies, none of us are smarter than one of us.
• Overhead increases.  The project loses valuable time that is now taken up by waiting for the manager to consider, explain, verify, and approve every step of the project.  Not only is time wasted, but often money as well, by asking well-paid, talented professionals to effectively sit on the sidelines.

Neglect, assuming that professionals neither want nor need guidance or set expectations, seems like a safer bet.  However, there are significant dangers here, as well.

• Teams idle:  Let’s be honest, here.  Yes, there are some purely self-directed workers out there.  However, the overwhelming majority of people, without guidance, will tend to wander the depths of the Internet rather than stay ahead of the schedule.  After all, there’s always time later.
• Goals mismatch.  Unsurprisingly, when a manager leaves the team to “just do the job,” invariably the team members not only don’t know what their priorities are, but also don’t know each other’s priorities.  This wastes time
• Help is late.  The team has slacked off and doesn’t quite know what parts of the project are important to the consumer.  When do we find this out?  That’s right, not until it’s time to integrate or check the results, usually close to when the final product needs to get out the door.

So–big surprise–the project is late.  As they say,

There’s never time to do it right, but there’s always time to do it again.

There are our (exaggerate) technical managers.  Next time, we’ll look at the (exaggerated) outside managers.  In the meantime, as the joke goes, “don’t do that,” because there actually isn’t time to do it again.

The article grew and I want to move towards smaller, more readable articles.  So, the big article is now a series.

Before I get started, though, I definitely need to tip my imaginary hat to the fortieth anniversary of the Moon Landing.  With few tools and less hard data than most of us take to the supermarket, plus more than a few wonderfully demented mishaps, a bunch of civilians and military men managed to organize themselves well enough to get human beings to the Moon and back, and invent a few great technologies along the way.  Just…wow.

Anyway, my view has long been that management roles are difficult because managers frequently come in one of two varieties.

• On the one hand, you have a manager promoted from within.  She was probably good at her “real job” and enjoyed it, and now misses getting her hands dirty.  Management certainly wasn’t her career goal.
• On the other hand, you have the young MBA who knows nothing about the industry and cares even less.  Projects are projects, people are people, so he can apply theoretical models to get everybody in line.

Both of these approaches are dismal failures every single time and annoy the people trying to get their work done.  The technical manager does whatever she can to avoid managing in favor of getting down in the trenches with “her people,” while the MBA is using models that assume that all the world is Henry Ford’s assembly line and that knowledge of the product is irrlevant to the task.

Sure, this is an exaggeration, but a mild one.  And it’s from these archetypes that we’ll learn what traits we find in bad managers and so, eventually, be able to build an image of a good manager.

See?  Short and digestible.  I hope, anyway.  If anybody has feedback on the  new approach, the Reply button is down yonder.

Stay tuned.  Next time, we’ll talk about where the technical manager goes wrong.

(Psst.  Of course–and here’s the obligatory cheap plug–these mismanagement styles are exactly what drove us to get eManagr on the road.  Take the complexity out of management and the technical guy can go back to helping out while the MBA makes himself and his team look good for the next round.)

I guess it’ll be too late for the celebration, but once this series is done, I may investigate some part of the Moon Landing from a management perspective.  That they were so phenomenally successful suggests that they had the very “good managers” we’re looking for, here.

Now, my original plan for this Monday was to talk about what managers actually do, and start some discussion over time about what distinguishes a good manager from a bad manager.

That piece wasn’t coming together and I was on the verge of scrapping it completely when somebody coincidentally reminded me of a favorite gem, Bill Swanson’s “Unwritten” Rules of Management at AllBusiness.

Further background is available at this article at USA Today focusing on the “Waiter Rule.”  And indeed it is foolproof, in both business and personal relationships.

For eManagr purposes, obviously #17 is near and dear to our hearts, and it’s good to know that Bill Swanson agrees with us on the point.

You can’t do much better than to cultivate these habits, no matter where you are in the business hierarchy and in your personal life.

Meanwhile, this has reinvigorated the originally-planned article, so expect to see it soon.