Things I Have Learned (So Far) In IT Consultancy

The best answers are usually simple, but getting to simple is often complicated

What do we mean by “simple”? Not zen wisdom — it’s more like “boring”.

As ideas and technologies mature and find their niche, the novel aspects of them become routine. They move from complex (many options, unclear what the best approach is) to complicated (many options, expert analysis can identify the right solution) to simple (a few well-understood options).

Spring Boot / 12-factor app is now a well-established tech: REST API, messaging listeners, service layer, repos…

At the start of the [airline] project (my first outside of the [consultancy] office, three and a half years ago…), all of this was far too wacky. The nearest-to-hand answers to questions like “how do we do SOAP as well as REST” or “how do we make this modular” involved complex bundles of technologies with lots of coupling.

Now we’d push for a much simpler scenario, but we’d only be able to do so because the technologies are more established and we could more credibly say “if you do it this way instead, you won’t have that problem”. When it’s new and untested, the worry is “what new problems will I have instead?” — the tradeoffs aren’t clear.

People cling to complicated solutions, and make them more complicated, out of fear. Example: using aspects to log exceptions, out of fear that developers will trap and then silently ignore them. “How else can we have this thing we want?”

“How else can we have distributed transactions?”

Getting from complex to simple is often a matter of building trust. You have to make the new way credible.

Don’t be intimidated

The guardians of complicated solutions are often intimidating. They have titles like “enterprise architect”. They know a lot about the system, and only they know all about the peculiarities of their custom solutions to the problems only they have.

If someone’s trying to layer their own implementation of Paxos on top of Cassandra, it’s hard to talk them down…

What gives someone in this position value is their private ownership of ideas. They’ve built up credibility by doing things that existing commodity solutions can’t do, by stretching the capabilities of those systems. This is a valid thing to do — sometimes it’s the only way to grow, in the short to medium term. But we tend to become involved at the point where things are stretched to breaking, and it’s time to move away.

The enterprise architect would like to play with new things, but doesn’t want their existing status and credibility undermined. If we can’t get them sacked, we have to give them ownership.

Don’t be intimidating

Actually, sometimes it’s ok to win through intimidation. If people who don’t know what they’re talking about are being obstructive, establish your credentials as someone who knows better and should be listened to. But it’s a short-lived victory. Eventually your aura of expertise is going to run out, and you’re going to have to switch to working in partnership with people. You can’t empower people by scaring them. Although, it’s still fun.

I have never really followed my own advice on this, but: we need to pair more with people. Sit down and code with not-particularly-good developers, and help them become better. (We did this at [online retailer], to good effect).

Understand what people have to lose, and what they have to gain

You’re making people an offer. Actually, you’re making different offers to different people. The dev lead whose team is valued and rewarded for delivering features reliably, is going to want to protect their ability to do that: the disruption of a major architectural overhaul is going to be unwelcome, unless you can show how the team will be recognised for making the process happen effectively, and will be able to do their thing more effectively as a result.

The ops manager who looks after the boxes in the server room is valued and rewarded for manually building and fixing physical boxes, and answering their pager every time it goes off. Transitioning to a more resilient system, with resources in the cloud and ubiquitous automation, is going to take a lot of that away. But it’s the path to much greater power, responsibility and effectiveness — and hopefully much fewer pager calls in the early hours.

Conclusion

My favourite joke of Bob Monkhouse’s is about the secret of success in showbiz. He’d go into a long spiel about the ups and downs of his career, the way his audience had always sustained him, the special bond you come to feel, the responsibility of being an entertainer. The dark days, the drink and drugs, the failed marriages. Through it all, the one thing that had kept that sacred bond intact: sincerity…if you can fake that, you’ve got it made.

For us, as I’ve been saying, it’s a trust game even more than a credibility game. Credibility is when you can play the expert effectively, be the subject-supposed-to-know. It’s vital in the early stages, where you need some pizzazz to justify being in the building. Trust is when you can make people an offer and they believe that the trade-offs are worth it. That’s what’s needed to move past being the expert, and into working in partnership with people.