Mark's Pages

April 5, 2010:

I'll tell you about my first meeting there.

A young development lead organized a conversation between himself, representing Engineering, and a senior system administrator, representing IT. The developer was hoping to mend a historically rocky relationship between the two organizations; while in the short run, he needed IT to spin up a new server for his group. I was there as newly-hired consultant to senior management.

It was clear that the IT fellow hadn't previously heard of the type of system the young engineer required. Odd, because it's pretty much ubiquitous. So, we explained. "Continuous Integration means that a build of the product is automatically generated every night by the system, without human intervention. An email is sent to the dev leads if anything goes wrong. This way, Engineering knows early if there's a code problem severe enough to break the build. Of course, this doesn't guarantee that the product is bug free. But it does quickly expose truly catastrophic problems before they ever reach QA. Over the long run, it's one mechanism for increasing code quality and decreasing QA costs."

As we spoke, a look that I can really only describe as eager triumph grew on the IT fellow's face. "That can never work," he said with undisguised satisfaction. "As soon as it comes to take more than 24 hours to compile the program, it will fail." Then looking around the table, he concluded, "I challenge you to name even one company where this has been implemented successfully." He crossed his arms, leaned back in his chair, and smiled. The answer was no.

Now, understand our surprise. The concept of Continuous Integration has been standard practice for many years. The software in question was written in a scripting language which was interpreted at runtime, not compiled. Everything about the IT fellow's position was simply wrong. He was ignorant, smug, and the odd thing is, empowered, that is, allowed by his management to define himself as an obstacle instead of a help.

All of which turned out to be furthered by the broader company culture, which defined organizational domains as a system of independent mini-states governed by patronage, like Mediterranean provinces communicating through exchanges of goats and extravagant displays of feigned respect. It was a train wreck, a profound failure incapable of delivering new products or keeping existing ones alive, symbolized and summarized by this fruitless meeting between Engineering and IT.

Yet here's the truly twisted thing. These people considered themselves not just successful but downright brilliant. They thought they'd built a wonderful place to work. The phrase you'd hear often about other companies was that, organizationally, "They just don't get it." After their failure they took this model with them into the wider world, where they rationalized their subsequent disasters as "politics". They have frequent cult-like reunions where they exchange nostalgic stories of the Good Old Days when they knew they were Kings because they told each other so. They hire each other as they wander from company to company because they genuinely and crazily believe; and besides, who else would?

I'm not invited. I told them to their faces they're incompetent, and I worked, as I was hired to do, to fix the messes they'd created. This makes me a "bad person", because for them these questions all resolve to interpersonal relationships, as you'd expect from a Mediterranean-style patronage culture.

Good night, and good luck.