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.

Ready?  Basically, since:

• I’m an American programmer,
• The criticism doesn’t really apply exclusively to programmers,
• eManagr is about removing the burdens of process, and
• Everybody else is screaming about these comments,

I might as well gripe, too.  At least admit that it’s better than another Michael Jackson tribute.

So here’s the key part (paraphrased), more concisely:

Americans looking to enter the tech field are preoccupied with conceiving the next big thing and getting rich, Nayar maintains. They’re far less willing than students from developing economies like India, China, and Brazil to master the “boring” details of tech process and methodology–ITIL, Six Sigma, and the like. [here]

All right, first of all, someone should explain to Mr. Nayar that this is about as classy (and correct) as announcing

• the Chinese are great at math and playing the violin,
• Blacks are strong and run fast, or
• Jews are greedy.

Yes.  I’m going there.

Do you feel that knot forming in your stomach?  Good.  Then I’ve cleared the air enough to talk about something more productive, processes.

I have to admit, I’m somewhat torn when it comes to processes, because so many of them are harmful and even more are misapplied. When we have them, we also tend to treat processes more like religion than tools.

The technical term for most processes is scientific positivism, the idea that technological miracles will reliably appear wherever proper procedures are honored faithfully, regardless of the talent of the participants.  This is the principle that Vineet Nayar espouses, even though he has probably never heard the term.  As Auguste Comte put it (in French in the early 1800s), “from knowledge comes prediction; from prediction comes action.”  Later, that “action” became more knowledge.

Depending on your field, I’m sure you’re familiar with these processes-as-life approaches.  Off the top of my head, there’s

• Agile Development,
• Six Sigma,
• ISO-9001
• …obviously, I could go on.

What interests me most about processes is that they all derive from simply documenting how successful people work.  Somehow we assume that they must apply to every situation, and that they free management from the burden of needing intelligent, self-guided employees.  Unsurprisingly, especially when you consider that the Agile creators and their ilk are rule-breaking geniuses in their fields, this doesn’t translate to the real world.

Worse, these proccesses also represent overhead for employees.  They now follow (and document their following of) the process.  They must document deviations to the process.  Team members must coordinate to approximate continuity in the process.  And to facilitate the communication and coordination, we need managers and managers of managers.  I can’t find the reference, but I’ve read that nearly one quarter of American workers have some managerial responsibility!  As I like to put it, we end up feeding the machine, and it’s awfully expensive and tiring, as Freder shows us.

However, despite all these problems, you also can’t get much accomplished as a cowboy or a prima donna.  It’s certainly harder to manage a project with such people on the team, because coordination is substantially harder.  We’ve all worked with them (or been them) and wondered how they stayed employed.

As you might guess, I believe that the solution lies between the two extremes, as it often does.  There’s a kernel of truth in the positivist approach, after all–while The System won’t ever be smart enough to replace the judgement of live workers, processes make each of us less error-prone.  Builders use jigs; artists use stencils; programmers use languages.  Those tools exist to make work more consistent and precise.  Likewise, many of us use checklists as we work to avoid making stupid mistakes.

Lightweight processes can automatically resolve the easiest mistakes to make, but need not be slavishly followed in cases where they take more time/effort than they save. That frees the worker up to, well, work, rather than manage.

In addition, measurement and tracking can turn most jobs into a predictable science. Instrumenting a process so that its speed, quality, and effectiveness can be measured is very useful.  Further, tracking that information over time makes a project easier to manage, as long as it’s useful information.

And hey, what a great opportunity to plug the main site!  Pure coincidence, I assure you.

This is exactly what we do at eManagr.  We provide you with a minimal process.  You tell us:

• How long tasks will take and
• When you’ve started and stopped work.

That’s your process.  The rest is up to us.  From that, we handle the metrics and analysis:

• Prioritize work,
• Predict project completion, and
• Predict performance on upcoming projects.
• Bug-tracking and
• Stronger team interaction are upcoming, as well.

The goal is to handle that process, so that you can get to work.  Be creative or a detail guy.  Since I already brought up Metropolis, I’ll paraphrase Thea von Harbou‘s epigram.  The mediator between system and intelligence must be a good manager (cough–or eManagr).

[Now I'm going to really go back to that management piece, probably rewriting and springboaring off of many of these ideas.  Unless something new comes up.  In case it runs late, go read some comics that won't disappoint you.]

So, what does everybody else think about Mr. Nayar’s disinterest in American programmers?  Have you faced similar issues in your field? Most importantly, how do you think we should fix them, if at all?