The Matryoshka Dolls of IT

I often get complaints from clients that their IT projects are always cumbersome, delivered late and over budget. They’ve had an impact on the business, certainly, but it’s far from a positive one. There’s a lot of blame to go round for this, and finger pointing can be fun, but what needs to be done is to get our C-level stakeholders and project sponsors to understand the implications of proposed work versus timelines.

Building a solution as a green field implementation is easy — there’s nothing there already, we’ve got freedom to design and build the best fit without all of that troublesome technical debt getting in the way.

This is fine for the vanishing small number of real world green field projects. Meanwhile, in the real world, the vast majority of IT work takes place in (so very aptly named) brown field environments. Tangled snares of existing IT implementations, sucking holes of technical debt, cut through with the ongoing sniping between different factions of developers and operations, all covered in a miasma of out of date procedures and design documents that didn’t even reflect reality when they were written 5 years ago.

This is where the Matryoshka Dolls of IT come in. An issue is recognised: “We need to interface with that database.” Fine. Easy problem to solve. Easy issue to communicate to non-IT staff. Easy issue for PMs to add to their project plans.

Except. We can’t interface with the database because the new solution doesn’t support the old protocol it uses. And the schema needs updating. And we need to encrypt the connection. And the PKI solution doesn’t quite work. So we need self signed certificates. Except we can’t distribute those, because the automation is about build and patching in this release cycle. And there’s a known issue with the PKI library on the servers. Which we have a patch for. But we can’t patch for 3 months because the app support team won’t take the maintenance outage.

Doll after doll. Each issue, while simple in itself, uncovers another issue. Before you know it, the thing has snowballed to a monstrous project risk — which no-one can clearly articulate — and suddenly it all kicks off.

At this point I have to point the finger firmly at technologists: we are great at talking tech, less so talking the language of business. Or even plain English. But there’s no real excuse for this — this has been a problem in IT for the 25+ years of my career. Journalists facing a tight deadline are regularly opting to hit “re-print” on last year’s article about the need for senior IT staff to be more business focussed.

The CTO or project sponsor doesn’t want to hear about patching issues or maintenance windows. They don’t understand, and they don’t care. It’s our job to effectively explain, in their terms, why the simple project task of “Connect solution to existing database” has blown up into “6 month delay to delivery date, risk to project”.

As technologists we should be communicating more effectively — not just with business people, either. It’s not hard and it’s hugely beneficial to your career. Yet the current drive from Silicon Valley, with startups focussed on delivering technology solutions to ephemeral problems, has seemed to exacerbate this lack of communication. There’s a culture of praising the geekery and throwing around (and, most hateful of all, reusing!) acronyms. It can’t be a clever, game changing product if everyone understands it, right? That won’t get me on the conference circuit!

This isn’t a public speaking issue, or a language issue. This boils down to really understanding the root cause of issues, and then explaining those without using technology terms: and then wanting to help others understand.

Metaphor is hugely helpful for this. If the CTO is a gear head, explaining that the project is trying to fit an F1 engine into a 20 year old Vauxhall Corsa will instantly make sense. More importantly, perhaps, it gives your stakeholders the instant context to start making risk/reward decisions for the project.

We’re not smart because we use obscure terms that no one else understands. We’re smart (and successful) when we help the people around us understand, when we educate and communicate.

My parting thought: as technologists our primary role isn’t to deliver technology, or even solutions — it should be to communicate.