The Tale of Two Managers

Is the company you work for serious about software development? How can you tell whether your manager is susceptible to the "Death March" management style you ask? Let's discuss a negative case and go from there.

I have a new definition of 'Chaos Theory'. Those who don't understand how to develop software will never free themselves from the chaos caused by operating in constant crisis mode.

Have you ever worked for a boss who liked to give direction and expected their group to start running around doing anything because action == progress regardless of direction? Did we do stuff we didn't need to? So what, at least we're doing _something_. is their mantra. Imagine what would happen if we let modern skyscrapers be built this way. The financial backers would revolt because they'd have to write the check for all the re-work; the engineering team would go AWOL because their carefully evaluated design wasn't being followed; the workers would go on strike because of the unsafe work environment caused by the activity-for-activities-sake. If your manager never wants to discuss process (current or future) they might be trying to manage the chaos by dictating constant activity. My theory is those managers feel like they are having to flail like the dickens just to keep their heads above water because they don't want their team to know just how out of control they feel.
Let's call this manager "Suzy Spur" for her penchant for 'spurring' her team to action; her idea of effective management is making sure her cattle-prod has freshly charged batteries.

Now, let's switch gears to a large development project that has it's head on straight. While Eclipse is also a tool that Java developers use to create applications, it also has sprouted a mature project management template for coordinating large-scale (in number of apps involved) software releases.

The Eclipse organization has created a process that is rational, consistent, and repeatable. By thinking through the process beforehand, they do not have to make things up as they go. They release on-time and with high-quality even if that means leaving features behind. Here is a quote from the site

Ganymede is about improving the productivity of the developers working on top of Eclipse frameworks by providing a more transparent and predictable development cycle; Ganymede is about developers helping developers serve the whole Eclipse community

When the executives are clamoring for results, what they really are asking for is predictability. They want to know when they can plan on the next version of their application will be ready for release so they can plan their trip to Jackson Hole (for those without spouses) or Orlando (for those with families). What they don't want is a make-it-up-as-you-go process, of which Suzy Spur is so fond, that will send them to Las Vegas in August with no AC.

In comes "Craig Calm". He acts deliberately, instead of by reflex. He surveys the road ahead and lays out a route which will get him to his destination with a minimum of fuss instead of bouncing over each hill unable to see over the next rise. He prepares the project foundation so the flurry of change means asking different interior designers for their ideas on the finishing touches instead of tearing out walls because they were put up before the wiring and pumbing were installed. He is respected because his team can plan time off because his projects are always on-time or any delays are expiditiously relayed to the proper governance group; instead of reviled due to the ever-cracking whip and constantly worrying about being fired right before a family vacation because the project is always behind the eight ball -- the deadline never moving regardless of the increased workload.

When a deadline doesn't move even though the work increases, that is a classic sign of inadequate risk management. If you (project) manager is not insane, a sliding schedules would be a simple result of project math: Workload divided by resources = timeline. Of course I'm over simplifying but let me use an analogy here. You are in charge of building a dam and one of the project assumptions is the area will get no more rain than the largest amount in the last 100 years. If halfway through the site gets deluged with twice the 100-year-record amount, you do not go to your team, at the waterlogged site, and say "Guys, just work harder" or my favorite "Work Smarter". What the sane project manager does is go to the sponser and say, "We didn't plan on this, we're going to have to start over." It is not the fault of the team or of the project plan when the sponser approved the assumptions and then came up short. The book "Waltzing With Bears" is a fantastic resource on the subject of proper risk management and how it can restore sanity to your project.

So, for whom would you rather work? The insane activity-for-its-own-sake pile-driver or the methodical, consisent, and goes-home-by-five software development veteran?