I point this out because in management and scheduling, we often

Confuse which stakeholders are most important to a project

In priority-based scheduling (need I bother plugging eManagr, at this point?), this is extremely important.  If you insist on giving your programmers or your boss more of a say than the client who pays the bills, the project is a failure.  Microsoft has a formal development process that is otherwise unremarkable except for the idea that everybody’s job is to sell the product, from the salesman to the CEO to the worker bees to the poor guy who unclogs the toilet.

Meanwhile, Columbus may have had entirely other motivations than fame and fortune for his clients.

Deal with technologies and rules that only make sense or are fully useful when we know their true, obscured origins

When you see strange requirements or can’t understand what a tool does, always ask.  Often, you’ll find that a requirement is easier to implement once it’s in context and isn’t being followed blindly.  For example, I once worked on a project where the client insisted on being able to change the size of any text.  Why?  A previous software vendor delivered tiny boxes on the screen with enormous amounts of text.  We solved the problem with pop-up screens instead, which were more readable.

Stumble on useful information, but refuse to share it because the route we took to find it exposes ignorance or an error in our judgement

Often, we begin working on a project and, in doing so, find amazing tools and data sources that could help…only to realize that we’ve misinterpreted the project.  In the scramble to get back on track, evidence of the mistaken trail gets covered so as not to distract us or make us look bad.

That’s understandable, of course, but extremely wrong-headed.  For  Columbus, it meant being unable to give a return on his investment, since the Carribbean natives aren’t exactly known for their precious metals and spices…though they have fixed the spice problem.

Find that the people who did the real work miss the accolades and rewards in favor of some bozo with a better press agent

Such is life, really.  Columbus was several centuries too late to be the first European in the Americas.  He wasn’t the first then-modern European to set foot on either continent.  Contrary to popular myth, everybody who cared knew the world was round, and Columbus’s only contribution was to underestimate the size.  And disease.  He and his men spread plenty of disease on landing and mixing with the natives.

And yet, he has the day of celebration.

It happens in every organization.  There isn’t much you can do about that, except to make sure that you credit your own star players whenever you have the opportunity to talk them up.  Eventually, someone will notice.

For example, in most of Latin America, the day is Día de la Raza, the Day of the (Hispanic) Race, celebrating and remembering the (sometimes brutal, granted) combination of the Spanish people and the Native Americans.

So let’s celebrate Columbus Day by refusing to let our teams make the same mistakes.  Some people may find it an acceptable ending to the story, but I’d just as soon avoid spending my dying days decrepitdly writing of apocalypses.

But there’s good news.

First, to my fellows in the United States, happy Labor Day.  It may interest some of you to know that the holiday didn’t originate as a “day of rest” or a counterpart to the Socialist May Day/International Workers’ Day celebrations.  No, it was a reaction to President Cleveland‘s military strikebreaking resolution to the Pullman Strike.

Not that you’d ever know it from the Department of Labor‘s version of the story.  Not even a mention of Congress rushing the legislation to prevent a nationwide uprising.

Today, Labor Day is different, depending on who you are:

• Back to school for the kids, teachers, and retailers,
• The “unofficial end of summer” for parks departments and the media,
• An unavoidable day off for employees, and so forth.

I’m pretty sure that nobody marks the passing of those killed by the strikebreakers, though.  Like Mothers Day, the origins of the day are lost on most people.

Moving along, this blog has slowed to a trickle because we’ve been moving around behind the scenes, which leads to a couple of minor announcements.

• First off, eManagr will soon have a baby sister of sorts.  It’s too soon to release any details, but you might expect some major news (and a discount) at the end of September or early October.  If you love your social networks, keep your eyes peeled.
• Some corrupted data in the blog database has been cleaned out.  If you wondered why you couldn’t read certain articles for a few days…well,  we still don’t know why, but a few odd characters snuck into a table.  If you didn’t notice, ignore me.
• We’re testing some new enhancements to the blog.  If they pan out, we’ll offer up another article soon to credit the extensions and point interested parties their way, as in our Under the Hood article from the spring.
• Most importantly,  we did some work on the eManagr internals.  You won”t see any changes to the interface, but some bottlenecks have been widened and things should be more efficient.  Slowdowns no more…we hope.

Here’s hoping everybody’s pleased with the rollout of the faster eManagr,  the blog gets back on schedule, and you’re all having holiday burgers instead of staring at a computer screen.

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.

It’s not that the entrepreneurial spirit is too great among American graduates.
Is it about money?  Or entitlement?  Or attitude?
I’ve had several parents (make that helicopter parents) ask me to help their children get jobs….
Why would anyone hire an adult who’s still using a parent to get them a job?  Why isn’t the grad taking the initiative? Does this point to where the problem lies?  No, we can’t ALL grow up to be president.
Are some American grads unemployable, or just not employable at the level they’re willing to accept?
Babs Ryan
International product developer, global trends forecaster, author
America’s Corporate Brain Drain

Interestingly, I’ve only recently heard the helicopter parent term.  However, in my own past…

• One of my first jobs out of college, we hired someone who looked good on paper.  He did fine work from Monday through Thursday.  On Friday, he left for lunch…and that was the last we saw of him.  The following Tuesday, his mother called me to tell me that her son wouldn’t be returning.  I wasn’t the man’s boss, by the way.  His boss was, however, asked for a job reference a few months down the road.
• At a different job, many years later, I had a boss whose mother would visit regularly and even sit in on our meetings.  We never knew why, since it wasn’t her field and she had no input.  We were a little reluctant to confront the boss about bad ideas, though, with his mother at the table, so maybe that explains it.

As Ms. Ryan points out, it’s impossible to take these people seriously, no matter what their age.

Fitting with the generational theme, I also received  comments from two recent graduates.

As a recent college graduate (May 2009) I thought it was extremely important to get a job quickly after college, no matter how much it paid. I was offered a job in March of 2009 before I even graduated and never thought twice about asking for more money. If he claims American graduates want to get rich quick and don’t have a rigorous enough education, I feel he is generalizing.

Overall, I feel new graduates should learn the ropes of any industry rather than thinking they will immediately get rich quick.
Alison Parsells
Communications Specialist
Tipton Communications

Alison also makes the point that classes in the United States are crammed full of students from the very countries Nayar seems to prefer.

Last but not least for this week:

I believe that an entrepreneurial spirit is common to all Americans, and with the burden of student loans (coupled with the dismal economy and poor employment rate my graduating class has entered into), I find it no surprise that most graduates are seeking to “get rich quick.”  Can they really blame us?

While some may mistake these attributes for pride and disregard for procedure, I believe that American graduates are simply demonstrating the drive and enthusiasm necessary to endure in a competitive economy, a mechanism for survival.

Kristin Davie
Career Quest

Thanks again to all.

Kristin’s thoughts probably mirror my experience best, by the way.  I’ve watched managers hire substandard programmers over better-qualified candidates, simply because the kid sold computers out of his basement one summer and listed it as a business.  Sure, none of them lasted in the job  (and no, no person mentioned above was one), but the initiative and business sense is attractive in a company that needs help.

But I want to talk about that more another day, and this is already running long.

Oh–also in the generational vein, several indignant people (I assume young) gave me the standard media line that Generation Y is superior because they’re ambitious, impatient, and technically savvy.  None of them seemed to realize that the first two points were Nayar’s complaints, and the third (especially in a technical industry) isn’t particularly relevant.

Such is life, I guess.

In the coming weeks, I’ll come back to that idea, though, and talk some about initiative and business sense on a résumé.  I’ll also return to the management dissection series.  And who knows?  Maybe I’ll get back to the “smaller, more readable articles” idea.

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.

Oh, right.  We’re also experimenting with Twitter.  And Facebook.

Right now, you should be able to see an announcement for this post @emanagr.  If that works out, we’ll investigate using Tweets as an interface to eManagr like many of us are using e-mail right now.

I assume that you can also see us on Facebook.  This isn’t my field at all, so I’m curious what this does. Stand back:

Anyway, it turns out we were in the Dark Ages with our version, so much so that we’re wondering how nothing has blown up in our faces, but we’re now at 2.8.1, just in time for the 3.0 announcements, I guess.

Upshot:  If anything looks broken, scream.  I think everything’s back where it’s supposed to be, but may have missed some things.

In the “credit where credit is due” department, we’ve added WP Greet Box.  Presumably, most of you won’t see it, but if a major content provider directs you here, the blog acknowledges it.  I find that sort of interaction helpful and hopefully you will, too.  Also, the aforementioned Twitter interface is handled via Twitter Tools.  Unless it doesn’t do what we expect, in which case we’ll be replacing it very soon with something else.

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?

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.

Always remember, eManagr isn’t Facebook.

Keeping in mind that communities aren’t competitions, if you wanted to think of community websites as a competition, then generally, you “win” when you have collected more connections (friends, followers, or similar) than other people you know.  That goes for Facebook, LinkedIn, Twitter, and dozens of social media websites.

For eManagr, it doesn’t matter who claims to be a friend.  We don’t record your communications and don’t prominently announce how many members are on your teams.  Most people wouldn’t even notice if half their so-called friends vanished into thin air.

We also don’t give you a “reputation,” like eBay and many bulletin boards have.  Measurements like that are artificial, because you don’t know how the person earned their five stars, seven thousand karma points, recommendations, or other representations of brown-nosing.  It may have been reciprosity or just good nature.

So, eManagr ignores those things.  Instead, we focus on what makes you unique and a potential candidate for a project.

We ask you who you are.  This is typical and unavoidable.  A solid overview of your experience tells a potential employer what kind of job might interest you.  It also gives you the opportunity to display basic communications skills and brag a little about your abilities.

Note the self-rated skills.  Our experience has been that interviewers want to ask for such self-assessment.  Lacking the means to test your abilities and honesty, this is on the honor system.  However, since we track your estimates (see below), it will be quite obvious if you’re good or bad at your job.

Second, we (not you) keep track of and talk about what you’ve done.  As an impartial third party, we can show an employer exactly what kinds of projects you have been involved with during your time using eManagr, and your role in the project.

Third, we provide up to the minute information on the number of tasks you currently have in the air.  This number might be misleading in fringe cases, but it will generally indicate your engagement; a small number of open tasks suggests that you are near the end of the project, while a larger number suggests that you will be busy for the forseeable future.

Finally, we show the accuracy of your estimates to date, using an average weighted more to the present.  History shows where you have been and number of tasks shows where you are, but your accuracy tells people how well you’re likely to perform.

As mentioned, this serves as a statement of how good you are at your job, based on how well you hit your scheduled deadlines.  Mediocre and bad workers rarely hit their marks.  Excellent workers already know where the project will end up.

That’s the basic tour of what you see on the profile pages.  To a great extent, our goal was to have a “living résumé.”  It’s not quite finished yet, but it seems to get the job done.

Feel free to point people to your profile as a résumé, in fact.  Anybody with an eManagr account can visit:

http://www.emanagr.com/users/yourloginname

to visit your profile.

We’re currently planning on adding to the profile.  Please contact us and tell us what works for you and what does not.  At the top of our list is an optional public profile for Professional users, but we’re understandably curious as to what our users think.