The first sign of trouble was a screenshot. We’d just switched on the A/B test via our feature management platform. Within the hour, a senior stakeholder landed in the variant feature flag, opened the app on their own phone, and sent us an image of it. The message, more or less: “Why is there a new tab in my app?”
It was a fair question. It was also one I thought we’d answered weeks earlier. Turns out we never really had. That’s the day I learned the difference between telling people and aligning them.
The Work We Were Proud Of
My team was reworking the information architecture and frontend navigation architecture of our app. This wasn’t a cosmetic refresh. We were changing the top-level structure to match our product vision and make the app the home of our loyalty programme. It was a strategic bet, and it carried real commercial weight.
We did the work properly, or so I believed at the time. We ran discovery sessions. We walked through the conceptual designs and release readiness plans. We reviewed the user research together. We held a final design and engineering review. And we invited our key stakeholders to every one of them. These were the people whose confidence the launch depended on.
When they couldn’t make a session, we didn’t let it drop. We sent summary emails. We posted updates in Slack. We wrote down where we’d landed and where we were going next.
By any reasonable measure, the information had been delivered. On paper, everyone was in the loop. I treated that as alignment. I was wrong.
The Launch Day Moment
When the test went live via progressive delivery, some of those same stakeholders were placed in the variant flagged user bucket. For the first time, they weren’t reading a summary. They were tapping through the change on their own phones, finding a structure that no longer matched the one in their heads. The screenshot was just the first of several.
The questions that followed were fair. Why were we making such a big change now? How confident were we that it wouldn’t hurt commercial performance or service reliability? These were exactly the questions I’d have wanted to talk through. The problem was the timing. I thought we’d worked through them weeks earlier, in sessions these stakeholders had been invited to but missed.
What I’d sent had been received. It hadn’t been absorbed. A skimmed Slack message and a declined calendar invite had given me a false reading. I’d mistaken silence for agreement. All it really meant was that busy people hadn’t yet engaged with a decision that didn’t feel real to them.
My first reaction was not a calm one. I wanted to fire back the links – the research, the design and technical specs doc, the session recording – as if the right attachment would settle it. Then it landed: if those links had worked, we wouldn’t have been in this situation. The person wasn’t missing information. They were missing the conversation that the information was meant to replace. This one was on me.
The work itself was sound. The research was solid. The design and underlying release architecture were good. But I spent launch day defending decisions instead of building on them. I was re-explaining context that should have been shared long before. The cost wasn’t a failed test. It was lost trust, a tense launch, and the quiet sense that people who should have championed the work felt it had been done to them.
Why Broadcasting Fails in Continuous Delivery
Here’s how I see it. continuous delivery isn’t just about moving code through a fast pipeline; it’s about preparing the business for that code. Written updates are great for keeping people informed. They’re a weak tool for getting people aligned on a big decision.
A Slack message asks nothing of the reader. It’s easy to skim. It’s easy to put off. It’s easy to assume you’ll catch up later. An optional invite is just as easy to decline when the week is full. None of these create the moment a stakeholder actually needs: the moment where they engage with the change, feel what it means, and raise concerns while there’s still time to act.
And concerns don’t disappear because no one said them out loud. They wait. They come back at the worst possible time, usually when someone finally experiences the change first-hand. By then you’re not aligning anyone. You’re defending a decision that already looks final. That’s a much harder conversation.
For an information architecture or core system feature change tied to commercial performance, that’s an uncomfortable place to be. A nervous stakeholder on launch day can stall a test, demand last-minute rollbacks or feature flag disables, or simply pull their confidence in the work. Not because the work was wrong, but because they were never brought along.
What I Do Differently Now
The fix wasn’t more communication. It was a different kind of communication. Three things changed.
First, I treat key stakeholder attendance as a requirement, not a nice-to-have. If someone who can make or break a launch can’t make a session, we move the session. A declined invite is not alignment. Treating it as one just defers the problem to a worse moment.
Second, for big launches, we now run a dedicated pre-launch alignment call. It isn’t a status update. It’s a working session. We walk through the whole experience together, revisit the reasoning, and surface concerns while there’s still room to act. The goal is to hear the hard questions in that room, not on launch day.
Third, and most importantly, we let stakeholders experience the change before customers do by targeting them directly using feature toggles. Ahead of a key launch, we run a round of friends-and-family testing through internal canary releases. The people who matter use the new experience on their own devices. There’s no substitute for this. Reading about an information architecture or system change is abstract. Navigating it yourself makes it real. And real is where the genuine questions, and the genuine buy-in, come from.
The Takeaway
Alignment isn’t a message you send. It’s an experience you create.
The point of stakeholder communication was never to be able to say “I told them.” It’s to reach launch day with no surprises, because everyone who matters has already seen the change, questioned it, and agreed it’s worth doing.
So before your next big launch, ask yourself one question: have my stakeholders actually experienced this decision, or have I only informed them about it? If it’s the latter, you don’t have alignment yet. You have a launch day waiting to go sideways, and a perfectly good piece of work that no one is ready to stand behind.
from DevOps.com https://ift.tt/kaxPJpH
Comments
Post a Comment