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.

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.

Repeat after me: The quality of a project and its schedule are directly related to the quality of estimates.

Of course, there isn’t a problem with this. There are many problems with it. For example:

• Projects are too big to estimate;
• Workers can’t give solid estimates, because they don’t have experience doing so;
• Even when they can, workers won’t give solid estimates, because it’s more comfortable to tell people what they like to hear; and
• Even when they can and will, estimates will often be wrong because, well, nobody thought of that.

Regardless of why, the result is that we learn we can’t trust the schedule.

No big deal, except that somebody made a commitment based on the schedule, turning it into a deadline. No matter what your field, you have experienced this. However, if you’re in software, you have a name for it, thanks to Ed Yourdon’s book: It’s a Death March.

Sidenote #1: If you work in software, and probably even if you don’t, give the book a try. It supplies good insight into where these projects come from and where they end up.

Sidenote #2: As Yourdon himself points out, this is not to compare a couple of weeks of staying late at work to the Prisoner of War march during the Second World War. It’s pretty rare that releasing a product involves war crimes and thousands of deaths.

So, how do we avoid this?

First, if you can answer immediately, then you have a guess, not an estimate. Stop and rethink, because a guess is very probably wrong. For everybody involved in a project, it’s better to be disappointing and right than people-pleasing and wrong…especially when your part of the project has gone careening off the rails.

Second, have a model. If you have done similar work before, that’s a good start. If you haven’t, you need to build the model, which leads us to…

Third, work small to large. How long does it take to build a seven story office complex? How long does it take to design a truck engine? I certainly don’t know, and I doubt that many people do. However, at some point, you need to fasten sheetrock into place or decide on the placement of fuel or power lines, and those are tasks we can estimate. If you can divide a task into smaller parts, then do so.

Fourth, do it again. People are optimists. Unfortunately, an optimistic schedule ends with missed deadlines. So once you have your estimate, introduce Mr. Optimist to Mr. Murphy. For each of your tiny little tasks, what can go wrong? If those things go wrong, now how long will the task take? Look at the difference between the best case and the worst case. Guess which one is more likely.

Fifth, bulk up. Remember that you don’t work in isolation. Even in the sheetrock example above, you don’t just drop into position and start hammering. You need to retrieve the sheet and the nails and be extra careful on placement. That means every task needs a little extra time built in for “warm up” or “context switching.”

Sixth, remember the lifecycle. While there are certainly exceptions, most tasks become less reliable when someone “Just Does It,” to paraphrase the ad campaign. Instead, every task is actually three. You need:

• A plan of action,
• The work, and
• Verification that the work is right.

If they’re honest, most people will tell you that the actual work is the fastest part and good testing is both vital and time-consuming. The numbers that I’ve seen kicked around are 2:1:3. That’s right. The enlarged number you just got is probably only a mere sixth of the actual time to completion.

Seventh, track your credibility. Look, we’re all wrong. Always. The reason that some of us look right is that those people learn how wrong they are and compensate. The railroads understand this: If it’s discovered that most trains are five minutes late, there are two solutions. First, you can declare “on or close” to include those five minutes. Second, you can change the schedule so that the riders don’t expect anything for those five minutes.

So, if you always overrun your schedule by ten percent, add ten percent to your estimates.

Eighth, vote early and often. In other words, don’t be afraid to change your estimate (and notify the project’s stakeholders about it) when you learn new information that changes the schedule. The earlier you can make a change, the easier it is for the team to keep on track overall.

Here’s where we get to the hard sell, because I can actually say, “you could do all that…or you can use eManagr.” Our task and estimate system is designed around these very principles.

Our model is to build an estimate from the smallest parts possible. In fact, eManagr will encourage you to split up any task taking more than a few hours, because that’s around the point where estimates become less reliable. We don’t (yet) have a “worst case” feature, but do feel that, when encouraged to look at work in terms of smaller tasks, the optimism will fade.

We silently add a small percentage of time to handle switching between tasks, so you don’t need to worry about it. We also impose a Plan-Do-Test lifecycle on every single task.

Likewise, the time you spend on tasks is saved and statistics generated. Those statistics then feed back on your estimates, allowing even unreliable people to have solid schedules. Additionally, you can change your estimate at any time until completing the task. This doesn’t actually change your statistics, however; we track both the initial estimate and final estimate in comparison to the actual time spent.

Hopefully, this gives a feel for the eManagr schedule model, and if you’re just passing through and not an eManagr user, I hope it helps you plan out a project without us (though we’re free for a single project and only six bucks a month for full access). “It’ll be done when it’s done” isn’t good enough for the corporate world (especially today), so a good estimate and a good schedule will take you as far as good skills in your field.

Two down, one to go. Next time, we’ll talk about the eManagr profile, including what it does today and what it will do in the near future.

What’s the big deal?

Teams fluctuate. Organizational charts change frequently. Workload is shouldered through various outsourcing firms. People come and go. In other words, your team is very likely fluid, and if we can help you form and organize your team faster and better, then that’s one distraction we’re happy won’t worry you.

The Hollywood model is about precisely this. Rather than attack a problem in terms of “resources” to be used, eManagr thinks in terms of tasks to complete and the people qualified to complete the task.

When a producer creates a movie, she starts with a writer’s script. Often, she has directors with whom she enjoys working, and brings one in who has the time. The roles in the script may also suggest actors these managers have already worked with, and so the cast and crew is built from relationships. Where there isn’t a relationship, the producer wants people with the best reputations.

And that’s all there is to our model. Relationships come first and foremost–you already know how to get in contact with your associates on eManagr. If your circumstances don’t permit any further recruitment, that’s it. If they do, though, you can search for someone with the skill you need and get the people who have the best objective records for getting their projects done reliably.

But that’s a story for the next post.

Meanwhile, today is Memorial Day in the United States. Whatever your politics or belief in any particular war, remember that those who give their lives for their respective countries do so with honorable intentions. Take the opportunity to remember their sacrifices and, as importantly, take time to comfort those who have lost loved ones to wars.