Nobody designed the seven steps

When I joined University IT Services at Indiana University, launching a website meant getting through seven teams, one after another. Hosting, brand, accessibility, the design framework, university accounts, content review, and support each had their own request and their own approval.

My first instinct was to ask who designed it. The answer was nobody. Every step made sense on the day it was added.

It started with hosting. Then IU's brand team asked that URLs follow a pattern. As sites multiplied, new rules arrived: every site on the domain had to be accessible under the ADA, carry a privacy notice, and look like IU, so visitors wouldn't get the wrong impression. Each rule came with a team to check it.

Then the university needed to know who owned what. Hosting accounts got tied to university accounts, and those to the websites, so there was one register of everyone mapped to everything online. Another step.

Then came a framework, an early design system, so people without coding skills could build and maintain a site with the privacy notice already in place. Another layer. Then accessibility scanning across all of IU's web. Another team.

Even the way teams talked to each other drifted. Early on, one team might tell the next, "Let us know when you're done so we can reach out to the client." Over time that became self-serve: read the documentation, follow the steps in order, and get rejected at the end if you missed one.

Now add the exceptions. Hosting on a college server instead of the university's? Different path. Windows hosting instead of Linux? Different again. All of the steps varied a little depending on where you started.

In 1968, Melvin Conway observed that organizations design systems that mirror their own communication structure (Melvin Conway). Seven teams, seven steps. The process wasn't badly designed. It was the shape of the org chart, drawn as a workflow.

The people paying for it were the ones asking. Research assistants and staff told me they'd rather host somewhere else and point a redirect at it than deal with our process. When that happens, the university loses track of how its name shows up online, which is exactly what all those rules were meant to prevent.

The part that grew least was the end. Retiring a site was still a self-serve email, and site owners were never told it was their job. That's how 1,500+ outdated sites stayed live.

So before changing anything, I talked to all seven teams and mapped the workflow as it actually ran, not as it was documented: what the requester sees, what each team does behind the scenes, and every handoff in between. Nielsen Norman Group calls this kind of map a service blueprint (Nielsen Norman Group). Seeing it on one page made the problem obvious. The steps weren't the real issue. The requester was the only person coordinating all of them, and they were the one person who didn't know how.

Seven steps became two. Requesters now touch the process once to request infrastructure and once to go live. We started with retirement, the step nobody owned, and a live dashboard now tracks turnaround time, down 25% early in the rollout.

What stays with me is how reasonable every single step was. Nobody made a bad decision. Nobody owned the whole thing either.