Stasis Meeting

A while ago I attended a meeting about how to hold meetings. It was as useless as you’re probably thinking, consisting mainly of such generic tidbits as “start on time” and “don’t allow gadgets” with absolutely no discussion of how to enforce any of it. It was a waste of time, like the majority of meetings, but it didn’t approach the destructive idiocy of the status meetings that first made me a Java developer.

I told you (in Billing Time) that I became a developer because of my unpublishable novel. That led to work with HTML (which I knew), JavaScript (which I did not know), and VBScript (which I did not want to know). My path to becoming a Java developer had to with the time-honored management practice of throwing more mummies on the fire.

I’ll take a slight detour to explain that turn of phrase. The British supposedly used mummies to fuel trains in the desert because they were plentiful and wood was not. I’ve never cared to look into this claim because of fear that it’s probably true. At any rate, to my mind it’s a perfect analogy for the conventional strategy of throwing resources at a problem without considering how best they might be used. Other, tactful people call it putting butts in chairs. I call it throwing mummies on the fire.

This time the fire was a HoneyPot project that was behind schedule and I was the mummy.

My task was to write a Java application that would take test data out of a database and construct XML to use for testing. The team needed this but nobody had the time to do it. No problem. That’s an easy task, and an entirely reasonable request of someone who knew what any part of that meant.

Why did anyone think that it was a good idea to have me do it? I was available, and as I said everyone else was busy. The team was working 12 hour days as it was, so asking them to add this work to their load would be even more insane. Still, I had trouble believing that I would be of much help.

Then I went to my first status meeting.

For three hours, the entire team sat and took turns giving an amazingly detailed report of their progress since the last meeting. They were asked to revise their previous estimates and explain any and every slippage. Then there was a general attempt at removing blockages. All of this took only about 10-15 minutes per person, but with at least a dozen developers that adds up.

What nobody said was that they’d all get a lot more done without the daily status meeting.

I realized that no failure on my part could possibly make this situation worse. It took me a few weeks and a lot of mental anguish, but I delivered a tool that would suffice for one of the four cases they needed. They were so far behind, that they were glad to have just that.

There were two valuable things I gained from that project. The first was enough confidence in my ability to learn to carry me forward as a consultant. The second was an understanding that management views meetings as a special, magical period of time that does not come out of their budgets.


3 thoughts on “Stasis Meeting

    • That’s actually quite a relief. It always sounded suspicious to me, and yet it was just horrible enough that I could be afraid it was true. The actual plausibilty of mummies as fuel was something I never bothered to consider.


      • My pleasure, it literally was the first thing that came up in a Google search, and I learned something!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s