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.

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?

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.

That was a substantial goal for eManagr. If it was to roll out, it absolutely had to be useful. Not content with reporting, a modern management system needs to be a manager. That’s especially true in the current economy, where managers can and should be pressed into service where they can do the most good (most of them in my field want to get their hands dirty, too).

How do we do it? Yes, there are some minor algorithms and formulas that help with dispatching, but we also spread out the burden to where it can be resolved most easily.

The “Web 2.0″ world calls it “crowdsourcing” and then misapplies it. Where the rest of the Internet asks everybody to contribute whatever they like, eManagr asks workers to supply work estimates. More importantly, long estimates are no good–we want to build all schedules from bite-sized units of labor. Likewise, we ask everybody on the team to vote on features. That information available, eManagr then offers decisions to guide the team most efficiently–short, popular tasks give you the most bang for the buck, so to speak.

However, there’s another important issue, here. By looking at your schedule under a microscope–individual rooms rather than an entire house–everybody is set to thinking about the work in detail. Likewise, the smaller the workload, the estimate will be more accurate.

The result, after we apply the aforementioned formulas and algorithms, is that eManagr can give you a more solid schedule and keep your team on track. That leaves your workers to do their work, and your managers to mentor the team. Leave the scheduling to us and let software work for you, for once.

That should explain everything. You want the actual questions? Picky.

Does the world need another project manager? Does the world need another e-something? Does the world need another quirkily misspelled domain name?

When development started on eManagr, I wanted something special. I wanted a system that would work for us rather than become another burden. In other words, eManagr need to actually manage your team, so that your team can, you know, get to work. It also needs to be a good manager and stay out of your way when you’re working. I’m measuring success only on how well it does that, not how many Microsoft Office features got crammed in.

First things first, eManagr doesn’t waste your time with customization. It looks like a legal pad. Verification takes more time than production. Tasks are more important if they’re shorter and more popular. Live with it, because the hours you spend arguing about how, exactly, to determine importance is a complete waste of time. eManagr might not know better than you, but like the best managers, a good enough decision isn’t up for debate until the real work is done.

Second, eManagr tracks your work. Partly, this is to help you eliminate time-sheets (an upcoming feature). But more importantly, it helps you give a better estimate for future work. Most stakeholders don’t care when something gets done. They really care that you get it done when you said you would, so they can plan around it.

Third, eManagr communicates by e-mail. You know, every time management guru tells you to stop checking your inbox. And you know what? Nobody’s stopping. So as long as you have the bad habit, we make it work for you. Once you create your account, you don’t need to go back to the website for every little thing. Fire off a message, even from your phone on the road, and eManagr will update things for you.

Fourth, we think a project runs smoothest when everybody has a say. Therefore, our priority system is semi-democratic. Everybody on the team can vote on project features, and eManagr will schedule those with the most votes first. However, since dictators can get things done quickly, managers can allow some voters to be “more equal than others.”

Lastly, we don’t know you. You might be the CEO of a multinational corporation. You might be an employee of a start-up. You might participate in Open Source projects. You might be an artist. You might even be a student working on a group project. Because of that variety, our teams use the “Hollywood” model. At any time, you can start a new team and staff it with any other eManagr users. You can ask subordinates, coworkers, friends, family, or consultants to join your team, and immediately assign work to them.

In other words, eManagr directs you and makes suggestions, but above all else, lets you do your job. And that is exactly what I wanted to see.

Is there more work to do? Sure. We have a whole bunch of features that we’ll be rolling out in the coming months. It’s exciting. But it’s also too much material for this post, which is already too long by half.