I was asked to help figure out how we could be more proactive in notifying customers of changes. My first thought: "We already have a release process - we just need to layer communication on top." Turns out it was more complicated. The problem was that multiple teams (engineering, product management, and customer support) needed to coordinate on infrastructure and operational changes (changes outside the normal software development cycle), but there was no consistent, repeatable process to make that happen. Worse, customers were finding out about changes before anyone inside had a plan to notify them.

These changes mattered. When external regulatory or standards requirements changed, customers needed to take action. When infrastructure templates changed, same thing. These weren't scheduled product releases. They were operational updates driven by external requirements. But they still needed to reach customers with notice and explanation. Instead, they just happened, and our support team found out from customers, not from engineering.

Working with the teams, we rebuilt the workflow from scratch. The result: a single source of truth with clear ownership, automatic visibility across teams, and a customer-facing change log. It's been running long enough to prove it wasn't a one-time project, with a steady stream of customer communications authored through the process and continuously improving.

Here's how I got from "this is chaos" to "this is a system."

The moment visibility broke down

Symptoms appeared regularly. A customer would log a support ticket reporting a behavior change they didn't expect. Support would ask engineering when this was announced. Engineering would explain it was due to an external requirement change, but support had no record of it (no email, no notification, nothing). So the support team would scramble to brief the customer, or the customer would assume it was a bug.

This happened often enough that it became the normal pattern.

The real problem was only visible if you looked across teams. Engineering knew when changes were happening. Product management didn't have visibility. Support found out from customers. Customers got no advance notice. Each team operated with incomplete information.

Why the existing process wasn't working

There was a process, but it had fundamental gaps. It assumed one team would notify another, and they'd cascade the message to customers. It sounds simple in theory.

In practice, it wasn't being followed. For a few reasons: teams weren't aware of it, there was no enforcement mechanism, and it placed all the communication burden on one team that wasn't set up to handle enterprise-scale communications.

When a change happened without going through the process, nothing broke. The system just continued until a customer noticed and complained. By then, damage control was the only option. No time to plan ahead, no coordination.

Change tracking defaulted to whatever was fastest: Teams chats and emails. Reactive, not proactive. Solving the immediate support ticket rather than preventing the next one.

What visibility actually required

Working with each team, we mapped out what they needed. The goal wasn't to design the "ideal" process. It was to understand what each team actually lacked.

Engineering said: "We know when changes are happening, but we don't always know who else needs to be involved." They had the information but lacked visibility into downstream dependencies.

Product management said: "We need to know what's coming so we can plan communications strategy." They wanted advanced notice and context.

Customer support said: "We need to know about changes before customers call about them. We need to know how urgent they are and who's affected." They needed to be informed early enough to prepare.

The pattern was clear. No team had complete information. Each one was missing something the other teams had.

Designing the workflow: One source of truth, clear ownership

I mapped the entire flow. Information inputs, outputs, dependencies, handoff points. Who needs to know what, and when.

The new structure:

1. Change notification entry. Engineering logs the change with: what is changing, when, why, customer impact.
2. Automatic visibility. Product management and support see it immediately and can collaborate in the workflow (clarification, communications review, timeline adjustments).
3. Triage rules. High-impact changes trigger a specific workflow for expanded visibility and sign-off. Lower-impact changes follow a lighter path.
4. Notification deadline. If a change goes live, customers must be notified by a defined time (aligned with external requirements where applicable).

Each step mattered because it solved something one of the teams identified.

To make it stick, we needed the workflow to become the path of least resistance. When a change happened outside the workflow, support would eventually create a record anyway (because customers called). But creating the record first was so much simpler that people naturally used it.

Building cross-team alignment: From conversation to concrete design

The early conversations were productive, but they surfaced something: everyone agreed the process was needed, but there was no shared mental model of what it should look like.

The turning point came when we moved from talking to drawing. I mapped out an end-to-end workflow with swimlanes, showing each team's role in sequence. Here's when engineering logs a change. Here's what product management sees. Here's what support does. Here's what the customer receives.

Making it visual made it real. People could see where their responsibilities started and ended.

I built a proof-of-concept in Jira Service Manager, and invited the teams to see it in action. "Here's what this could look like. Let's walk through it." Seeing it, rather than imagining it, created confidence.

Getting all the right people in the conversation took about two months. Once there was alignment on the process design, the workflow build took about three weeks. Then I brought people through a few live iterations, not because they needed technical help, but because they needed to build confidence in the new rhythm and way of working.

Results: What actually improved

After the rebuild:

A customer-facing change log became the source of truth. Customers now have a single place to see what non-product changes are coming. Simple as it sounds, this visibility didn't exist before. They had to piece together change information from emails, support conversations, and guesswork.

Customers get notified in advance. The workflow made notification a formal requirement, not an afterthought. The workflow automatically creates follow-up work items for documentation and customer communications, so each team has a clear task and nothing falls through the cracks.

Teams have visibility into each other's work. When one team sees a change coming, they have time to prepare. When someone flags a timing concern, the whole system sees it. When teams understand the downstream impact, they make different decisions.

The system has sustained. Since launch, dozens of customer communications have gone through this process. The workflow has evolved based on what we learned. It didn't fade after the initial launch. Teams use it because it makes their own work easier, not because they were forced to.

What this taught me about process architecture

Most people think architecture lives in code, systems, and infrastructure. But process architecture is equally load-bearing. A broken process creates the same failure modes as a broken system: unpredictability, diffused accountability, cascading failures downstream.

When visibility breaks down, you can't fix anything. Nobody knows who's responsible. Teams make local optimizations that hurt the whole system. Customers notice first.

Cross-team coordination is harder to design than single-team workflows. It's not just a technical problem. You're designing for incentives that don't naturally align. You have to structure it so every team gets something: visibility for some, preparation time for others, clarity on dependencies for another, advance notice for customers. Everyone benefits, but only if the process actually makes it worth their while to use it.

One last lesson: don't choose the tool first. Start with the process. Once the process is right, find a tool that enforces it. The tool is just the mechanism that makes it real and keeps people honest.

---

Comments welcome!