Back to All
Ai/ml
Blog

The 55-Thread Problem

Listen
The 55-Thread Problem
5:14

I came across a quote recently that's been hard to shake. It came from a user research study — a survey of IT leaders talking about what frustrates them when working with managed and professional services providers. This particular person wasn't a Mission customer. They were just describing a moment I think a lot of people in this industry will recognize:

"By the time I got pulled into the escalation, there were 55 email threads, a handful of calls with no notes anywhere, and a Slack channel nobody had updated in two weeks. I genuinely had no idea where things stood or what had already been tried."

That number might be precise. It might be the kind of estimate you make when you're frustrated and counting feels beside the point. What I do know is that anyone who's managed a complex technology engagement has felt exactly what's behind it — that sinking moment when you realize the full picture of what's been happening doesn't actually exist anywhere. It's distributed across tools, inboxes, and the memories of people who may or may not be on the next call.

I don't think this is a story about bad communication. Most teams working with a cloud partner are communicating plenty. The problem is that none of the tools those conversations happen in were designed to carry context forward. Email threads close and get buried. Tickets are built to resolve and move on. Slack is, almost by design, ephemeral — the perfect tool for right now, and a poor one for six months from now when someone needs to understand what was decided and why.

Cloud managed services relationships don't work like that. They span quarters, sometimes years. They involve cost reviews and architecture discussions and optimization cycles and planning conversations that build on each other over time. When all of that lives in fragments across five different tools, the accumulated understanding of what's been done and what still needs doing doesn't live anywhere. It has to be reconstructed from scratch, every time, by whoever happens to need it next.

That reconstruction cost is real. It's the follow-up email asking for an update that shouldn't be necessary. It's the meeting that starts with fifteen minutes of "so where did we leave off." It's the customer who has to explain their environment and their priorities to someone who should already know them. And it falls disproportionately on the customer, which is exactly backwards from how a managed services relationship is supposed to work.

We've been sitting with this problem for a while. The honest version of Mission Control's history is that we started with the most immediate customer needs — support cases, visibility into what's open, a cleaner way to track requests. That part works. Customers have submitted hundreds of thousands of cases through Mission Control since it launched, and the experience of managing support is meaningfully better for it.

Mission Control pioneered the concept of "Services as Software," where our cloud-native managed and professional services are built with the assumption of purpose-built software. So, Mission Control expanded its scope, providing continuous benchmarking with Scorecards, insights and guidance through integrated Recommendations, and visibility into our customer's AWS estates.

Support is reactive by nature, and the growing set of features in Mission Control were creating fragmented conversations. The best things we do for customers — the proactive guidance, the optimization work, the planning conversations — those were still happening in email and on calls, accumulating in exactly the fragmented way that IT leader was describing.

So earlier this year, we started rolling out something we're calling Collaboration Loops. The idea is straightforward even if the execution took a while to get right: a persistent, structured space inside Mission Control where a customer and their Mission team can work together on a specific topic — a quarterly TAM check-in, a cost optimization initiative, an onboarding effort — without losing the thread between sessions. Goals live there. Documents live there. Scorecards and recommendations are directly integrated. The history of what was decided and what's still open lives there. The right people from both sides are in the same place.

It's not a replacement for support cases, which still handle what they've always handled. It's the part that was missing — the infrastructure for the relationship itself, rather than just the requests that come out of it.

The 55-thread problem is solvable. It just requires building something designed for continuity, rather than assuming the tools designed for moments will somehow add up to one.

We're still early in this. Loops will expand over time as we add new templates, new use cases, and new ways for our teams to make their work more visible to customers. But the direction is set, and I think it's the right one.

If you're a Mission customer and want to see it in action, ask your TAM. And if you want to dig into what we've built and why, Mission Control's product page has the full picture.

Jonathan LaCour avatar

2 minutes read