"What’s In It For Me" Architecture

I recently read the quote, ‘The best architecture that isn’t implemented is just an expensive drawing,’ and I couldn’t agree more. I wish I came up with it.

When organisations hire for architecture roles they always look for extremely technical and knowledgeable people. While it is true that you need deep technical knowledge to set up large-scale architecture outlines, it’s all worthless if you can’t convince people to actually implement it.

The drawings and roadmaps are just the first part, the convincing and negotiation part is probably just as important.

Know your decision makers

Often when you are pitching ideas it’s not the higher-ups that fully decide. These people often (or should often) lean on the expertise of the more hands-on people to get a better picture of what’s happening.

There isn’t a strict line for who that is. It’s a very personal thing for a manager to have a trusted person they want to speak to in private to have a full opinion of what’s happening.

If you can convince these people, you also convince the higher ups. The nice thing about this approach is that you don’t have to wait 2 weeks for a meeting with them. They are typically easier approachable. The hard part is, however, figuring out who they are.

Understanding the needs

To do a decent proposal, you need to understand your playing field. Every project has their impacted groups. Some get less work, others might have to adapt their work. Some like it, others hate it. An important part of this is understanding what these groups find important.

Some project managers for example only care about the scope of the project. Very understandable as that’s what they are hired to do. Get project X implemented in 6 months and keep the cost below Y. If you are going to pitch idea’s that impact any of these factors, you’re going to have an initial negative reaction to them, even if it’s good for the long term. If you can however make the work more predictable or create “gates” in the project, they will gladly take you along for the ride.

Engineers, on the other hand will be very concerned for their environment. Introducing big rewrites and quick hacks to meet a deadline will not be appreciated. These things will survive the project, and they’ll be stuck with them. If you can however calculate in a rewrite of a messy part that you can maybe offload to a different system, you’ll have all the excitement you’re ever going to need.

Then there is also the higher-ups. Executives don’t really care about clean code. They care about Total cost of ownership and speed to market. If you can’t translate your technical or project “win” into a business “win”, you’ll lose them.

As you can see, even on a project basis, you have different people looking at the same work in very different contexts. Keeping these contexts in mind is very important while drawing up your plans.

Preparing your arguments

When I work on architecture I always play devil’s advocate. Even if I’m 100% sure that an approach is the best one, I’ll always try to argue against it. My goal is to have better counterarguments than the opposition can think of.

Sometimes I also weave them into the conversation early. “I know this looks like I’m trying to slow down the sprint. I’m not. I’m trying to ensure we don’t have to rewrite this in Q4”.

You will also encounter immovable people. I find these the hardest to deal with. People who will just not move an inch towards compromise. If you’re lucky you can let their managers handle it, by going one level higher. But this only works if they are not a “trustee” of said manager. This is also a sure way to burn a bridge.¹

Another approach is a pilot. Let’s do an experiment and actually see how this will all turn out in reality. Is this actually something that will bring you so much more work, and will it all turn into a huge mess? Let’s find out. An important part here is that you also need to be fair. If the pilot turns out bad, have the honesty to roll it back and admit that you were wrong.

If you don’t do this, you will lose all your credibility.

The architect as a diplomat

A lot of architecture is actually more social and political than most people think. You often get further with having coffee with the right people than writing very deep design documents.

This is something new architects typically struggle with. You get an architecture role due to you being very technically knowledgeable, and now you have to step into the peopleware section.

A lot of developers go for architecture roles because they don’t want to manage teams. They just want to focus on the technical stuff. Well, I personally think that you have to do way more managing of people in an architecture role compared to a team lead role.

That is if you don’t just want to make expensive drawings that will never be implemented.