I have a simple test that tells you a lot about the culture of any organisation.  There are two questions you need answer:

1. If you are talking one on one in their office do managers generally answer the phone when it rings (thereby interrupting your conversation) or do they leave it for voicemail?
2. Do managers regularly choose to delay or stand-up multiple subordinates when summoned by their superordinates?

If your answers are interrrupt and stand-up then you have a management culture that believes that they are central to getting things done.  This is, of course, pretty bogus, selfish and arrogant.  If you have only one of interrrupt and stand-up then you have a warning sign.  Hopefully, things are trending away from the arrogant management culture.  Managers exist to enhance the performance of others - if they do their job then they become less necessary.

Today at work we decided to shelve a project. It was an update to an existing web content management system and was due to be released in a couple of weeks. Things appeared to be going okay until the project approached release. The project is pretty traditional (i.e. waterfall) and is/was in the “testing” phase. The development and testing environments have always been flakey (crappy architecture and people putting up with less than ideal situations) until about a week ago when they took a turn for the worse. Was it the code? Some problem with one of the servers? Nobody knows - the configuration control of the servers is out of hand - nobody can really work out what is going wrong. All up there was just too much risk floating around so we decided to bite the bullet and halt the project until we get the environments under control.
Lessons? I’ve got lessons:

1. If something smells bad for a long time then it probably is. I wish I’d dug deeper into the smell earlier and ignored the advice that things “will be okay” or that the problems aren’t linked and are just a long series of individual, unrelated minor mishaps.
2. If migrating between environments is done by manually repeating steps then stamp your feel and insist that it be automated. Don’t let the developers tell you that it has always been done that way and has always turned out alright.
3. Go back to lesson one - remember to follow your gut.

Its a pity that we got so far and so much effort has been (potentially) wasted. Its embarrasing for us all. Worse, after the news of the project being shelved was shared with the developers they asked for one more day since they were sure they were close to fixing the latest problems. Now they think I don’t trust or believe them. That’s not true - I just don’t think that we can continue to dig ourselves deeper.

P.S. I started working on a new contract last year - its almost the exact opposite of my last role - big, very traditional organisation. The opposite of agile and not very fashionable technology or development processes (not much, if any, source code control, waterfall style testing, no real unit tests, etc).  Email me if you want to know about why I left my last job. I don’t think I’ll be blogging about it - at least not for a few more months.

There were a couple of comments on my First make someone responsible… post that I’d like to highlight.

Ian from Financial Cryptography (a subject so complex I can barely spell it) chimed in with his usual wisdom to say:

…It’s a mess of contradictions - the job is mostly communications, but you need to be a technical expert otherwise the techies will snow you. The job is about compromise, negotiation and swallowing ones ego; but getting the technical skills required to face up to the people you are managing requires the reverse of that…

The ability to be able to smell obfuscation in nerds is something that most reasonably experienced managers develop. Being able to challenge, or better, work with a nerd to come up with an improved and acceptable (to the nerd) solution is something that can only come from people who have themselves been nerds. As Ian notes finding such people and keeping them in the middle is something that can be a challenge. Having a role model doing the same job somewhere else in the company helps.

Tarun from Musing of an Iconoclast added this:

…if you have a late or overbudget project then this is probably the only thing you can quickly change that will make a significant difference…

So true. Even if a process is being followed the absence of someone in the middle will probably bite you. As I said in the original post, adding someone is great experiment - showing whether or not the addition has helped.

Recent posts

Nerdherding for Beginners is written by Michael Harmer, released under the Creative Commons Attribution-Noncommercial 2.5 Australia licence powered by WordPress and designed by XiAP Design Studio.