Architectural Decision-making

The audience for this talk was the technical leadership team, director and VP level, of a well-known retail chain. They had been struggling through taxonomy projects that stalled for unexpected reasons or failed to deliver the value promised. I was asked to speak to them about why problems like this happen. It was a fun opportunity because my audiences are usually the individual contributors who are desperately trying to force these kinds of decisions, not people with the power to actually make them.

Deck

In the 1850s, Australia needed a railway system. One colony decided to use 4’ 8 1/2” track, the other decided to use 5’ 3” track. They haggled back and forth, people got angry, I’m sure, but it never got ironed out. Instead, as new colonies were founded, they became states, and the country continued to industrialize, the railways developed to meet each state’s needs, rather than that of the emerging nation. It got worse. By the 1870s, passengers or freight going from the east to the west coast had to be unloaded from one train and put back on another five times.

What’s the solution here? (It’s not a trick question.)

Australia didn’t have a standardized rail network until 1982. (And actually, this is arguable, rail standardization projects are continuing today.)

So, why did it take so long? Why did Australia have computers before it had a standardized rail network?

Was it a technical problem? In 1922, inventors proposed 273 gadgets and stratagems to solve it, but none were adopted. Choosing a rail gauge is a significant decision, but there aren’t infinite options, you just choose one, and then you build new rail, right?

Did it not seem important enough? Railway networks are extremely powerful, and this was understood at the time. They enabled people and goods to travel long distances cheaply and allowed the emergence of national markets, rather than prices differing from town to town. The modern nation state as we understand it would not exist without railways. It was the most transformative technology of the 19th century.

I’m belaboring this a bit because I think it’s clear why this was a problem: Connectivity requires standardization. It doesn’t work as well when everything has to get off one train and get back on another at every internal border. Rail connectivity required standardization on an unthinkable scale for us.

Not just in the coordination of infrastructure, but it actually required us to standardize time across cities. In case you haven’t noticed, there’s something wrong with this clock. One of those isn’t a second hand, it actually has two minute hands: One for the time it was in Bristol, England, where this clock is, and another for the time it was in Greenwich. 140 miles away. People and information had never moved fast enough to require 7:30 in one place to be simultaneous to 7:30 in another. Suddenly, everybody had to agree on a lot more about the world, so they could reap the benefits of this system.

This resonates with reasons I see projects in my scope fail. I handle information architecture:

 The navigation model - the types of navigation you expect to have on a site or in a product (persistent, contextual, utility) and the rules for putting them together. If you’ve ever felt like you’ve wanted a sitemap, this is what you want.

The content model - The reusable things we have and their relationships to each other. If we are a recipe site, it’s probably recipes, but maybe also Chefs, Ingredients, Menus, Blog posts, and Reviews. In another context, it could be products, ingredients, stores, or even reports and datasets.

The information model - The infrastructure of taxonomies and other metadata that string it all together and make it work.

You can see that all of these are fundamentally concerned with standardization, agreement between areas, getting everyone, metaphorically, on the same gauge railway. Has anyone here ever been involved in a metadata project, or a schema project, or a navigation project? Something on this slide? Was it easy?¹ ⊕ ¹ This usually gets some pained laughter. It is a silly question. They’re definitely not easy.

They’re usually not. In fact, they go sideways a lot of the time. Sometimes they straight up fail in a recognizable way, but more frequently, they take too long for not quite the hoped-for outcome or get quietly abandoned.

I worked with lots of companies before I came to Microsoft, and I’ve talked with lots of other people who do this kind of work with clients, including you all, and these are just some of the reasons we’ve seen IA projects go off the rails, as it were:

• People couldn’t agree on whether the product should exist, this delayed a navigation product for a year.
• People couldn’t agree on what the product was, this has stretched a content model project to five years.
• Product and engineering couldn’t agree about how the product worked, this delayed a migration project for three years.
• People couldn’t agree on what components each product had, this caused a million dollar project to be abandoned only to be tried again 6 years later.
• People couldn’t separate who owned the part of the business from how we put it on the website, this caused a CMS migration to miss the Holiday season.
• People couldn’t agree on what the taxonomy was supposed to do, this turned a two-week project into an eight-month one.

(This is non-exhaustive.)

I find that disagreements come in two main flavors.

The first is, “I disagree with this and think it is something else.” This is actually relatively easy to deal with, because you can name the disagreement directly and there are ways to get past it, like verifying assumptions with data or disagreeing and committing.

The second is deadly, and these all mean, “This isn’t clear enough for anyone to meaningfully agree with or not, because they don’t understand it.“ Since they don’t understand it, they don’t have an alternative, and progress stalls. To get past this kind of nebulous disagreement, you’re actually maturing your organization’s approach to architecture.

Most organizations start with something simple, and when everyone’s working on their own local systems or straightforward enough to be kept in one person’s head, you can get away with not having these conversations. And from time to time, big projects will mysteriously fail. Or they’ll take a year, when some people are sure that it was three weeks’ worth of work.

Then, what usually happens is that someone sees this happening and hires an outside expert to deal with it. You get a technical recommendation to deal with a proximate problem. Sometimes it works, sometimes it doesn’t, because it’s blocked by a big disagreement, or more frequently, an organizational inability to commit to a substantial change.

Eventually, if you see value from doing these external projects, you get tired of writing SOWs all the time and you buy a very senior person off the market or identify someone internally who has been desperate to do this work. They often work like an internal consultant, deployed strategically where they’re supposed to have the most impact. If the organization hasn’t also made some important decisions, this person will need to rely on their individual political savvy to make things happen.

Sometimes, you get systems thinking to become endemic. The whole org has agreement on basic facts of the domain and you’re having important, not just urgent, conversations. Architecture becomes more about making sure those conversations are happening, not always facilitating or guiding them.

I’ll let you decide where you think your organization is. It’s probable that your whole org isn’t at one place, or your at a moment of transition. That’s why we’re having this conversation.

So, what can you do to help move up this maturity model and keep work from mysteriously failing or delaying?

Architectural problems can be hard to see. Your biggest tell is that if it feels expensive, scary, or unwieldy, there’s an architectural problem in there somewhere.

Learn to see, or trust your people who can, when something is an architectural problem.

An executive asked me this question when I was new at Microsoft. He didn’t immediately do everything I said, obviously, but it gave me the chance to tell him the things I saw that were negatively impacting his business. And then, later, he spoke positively about my work and supported me for a promotion, instead of being peeved that I hadn’t told him that everything was fine.

Too frequently, leaders treat people who see problems as if they have created them. This is endemic among people doing architectural work. There’s a known phenomenon among people who are hired to go in-house: A company hires an IA to fix their navigation or metadata problem, and they ruffle too many feathers by diagnosing it. That IA gets pulled off the project that would have had impact, gets sternly spoken to, and put on something small. They get to try again in a year or two if they’re lucky. It’s easy, relatively, to find headcount to hire somebody to just fix things. It’s harder to reward them for telling you the truth, but that’s something you can change as a leadership team. Prioritize and reward systems thinking. Protect people who are telling you the truth about your rail gauge.

You also need to be realistic about the fact that you’re the ones who have the power to make these decisions, and that this kind of decision-making is difficult.² ⊕ ² h/t to [Ika Willis (https://bsky.app/profile/ikax.bsky.social/post/3lbqjkbf5vk2u) for this great turn of phrase.] There’s no process or tool that will eliminate the risk. Every decision closes off other possibilities and commits to a certain set of risks. People avoid it because it’s hard and frightening.

As a leadership team, you need to support each other through those decisions. That means accepting uncertainty, letting people change their minds without fear of ridicule, and focusing on the quality of your decision-making itself, not just the outcomes.

As an aside, I almost always give talks like this to ICs or consultants, and the number one thing they see predicting the success of an architectural project is an executive who “gets it.” This is something that you are uniquely positioned to change. Do it together.