How Architects Should Collaborate With Operational Teams?
A practical guide for architects who want to work better with the operational teams that support software after release: support, SRE, onboarding, and beyond.
If you want to know whether your system really works, talk to the people who keep it working after release.
Architects often spend most of their time with product managers, engineering managers, and development teams. That makes sense. Those groups shape the roadmap, the delivery plan, and the design. But once the software reaches production, another set of teams starts living with the real consequences of those decisions.
Support teams hear where customers get stuck. Customer success and account management see where the product creates friction after the sale. Professional services teams learn which onboarding steps still need human help. Infrastructure, SRE, and CloudOps teams see which parts of the platform are stable, which parts are expensive, and which parts everyone quietly hopes will not fail tonight.
That is what I mean by operational teams: the people who make sure software is usable after release, while real customers are using it.
Architects who ignore those teams usually miss the clearest picture of how the system behaves in the wild. The result is predictable. We optimize for planned behavior and stay blind to actual behavior.
This article was created with support from IcePanel.
IcePanel is a collaborative diagramming and modeling tool for software architecture.
It supports C4-style levels, so you can model the system from high-level context down to technical detail.
It supports flows, so you can show how requests, events, and data move through the system.
It keeps diagrams consistent by using a connected model.
It structures architecture data in a way that AI tools like Claude Code, Codex, or OpenCode can easily read and understand.
That makes it a good fit for teams that want architecture to stay useful beyond a single workshop.
It is available for free. Give it a try!
Thanks to IcePanel for sponsoring this article. Let’s get back to it!
Operational Teams See the System Customers Actually Experience
The first thing operational teams give you is direct exposure to customer pain.
Product managers usually bring customer needs through strategy, prioritization, and feature framing. That is important. But operational teams sit much closer to day-to-day friction. They hear the same complaints repeatedly. They see the same confusion repeatedly. They know which issues are annoying, which ones are costly, and which ones make customers question whether the product is reliable at all.
That matters because customer experience is not only a product problem. A large part of customer experience comes from technical decisions.
Reliability is technical. Performance is technical. Recovery is technical. Manual workarounds are technical. The more you understand those "non-functional" realities firsthand, the better your architectural decisions become.
Operational teams also help you validate functional requirements. If all your input comes from a PM, you have to trust that the information stayed complete and accurate all the way through the chain. Sometimes it does. Often it does not.
Every handoff filters information through personal judgment. People naturally emphasize what they think matters most and compress the rest. That does not mean anyone is careless. It means no single channel gives you the full picture.
Operational teams are another source of truth. If you talk to them alongside the product, you get a much more complete view of how the feature works, how customers use it, and where the real edge cases live.
They Also See the Hidden Cost of Your Design
One of the most useful things operational teams can show an architect is the cost to serve.
Many systems look acceptable on paper because the missing automation gets pushed into human effort. You have probably heard some version of this sentence before:
"We do not have the capacity to automate it right now. Support can do it manually for now."
That sentence sounds temporary. In many organizations, it becomes architecture.
Support starts doing the same workaround again and again. Professional services carry repetitive onboarding steps that should have been productized. Platform teams absorb unstable infrastructure work because the safer path was postponed one more quarter. None of that always shows up on the roadmap, but all of it shows up in operational load.
When you understand what these teams are doing manually, you can improve two things at once:
The cost to serve the customer
The quality and resilience of the solution
This is where operational teams become especially valuable for architects. They do not just tell you what is broken. They show you what the costs are to keep the system alive.
They Know Where the Bugs and Time Bombs Are
Operational teams often know the weak places in a system better than the engineering team that built it.
They know where bugs keep resurfacing. They know which failures cause panic. They know which workflows produce tickets every week. In more advanced operational groups, they also know the thin places in the system, the time bombs everyone hopes will survive one more traffic spike or one more quarter of growth.
Think about a legacy monolith with a database that everyone knows is under pressure. No one can say exactly what request will be the last drop, but everyone close to operations knows the risk is real. That is not theoretical architecture knowledge. That is operational truth.
The mistake here is to become the messenger yourself. Do not collect all that feedback and carry it manually between ops and development forever. Build the channel instead.
Facilitate direct communication between the people who see the pain and the people who can remove the cause. If you become the permanent relay, you create another bottleneck. If you help both sides speak directly, you create a system that learns faster.
What Operational Teams Need From You
So far, this is what you get from operational teams. The relationship only works if you also give them something useful in return.
1) Give honest constraints, not empty promises
Not every issue can be fixed now. Not every issue is even worth fixing now. Architects need to explain that clearly.
When an operational team raises a problem, do not dismiss it. But do not promise a fix just to reduce tension in the conversation. Explain what is possible in the current reality, what tradeoffs are blocking the change, and what will have to wait.
That honesty is better than false reassurance. It helps operational teams plan around reality instead of waiting for a solution that is not coming soon.
2) Explain intent, not just implementation
People in operations often see how the system is being used in practice, not how it was intended to be used.
That gap matters.
Sometimes a spike in activity is a bug. Sometimes it is expected behavior. Sometimes support sees a strange customer pattern that looks wrong but is actually a consequence of the design. Sometimes the opposite is true: a behavior looks normal because people have adapted to it, even though it signals a product problem.
Architects can help operational teams understand the thinking behind a feature, the intended usage pattern, and the boundaries of expected behavior. That makes it easier for them to tune the system, recognize abnormalities, and escalate the right things earlier.
3) Share direction early, especially with platform teams
Infrastructure is expensive to change. Platform decisions age slowly and usually cost a lot to reverse.
That is why operational and platform-oriented teams need architectural direction early, not when engineering is already blocked and waiting.
If developers will need new platform capabilities next year, the conversation with operational teams should happen now. By the time engineers urgently need a platform change, you are already late.
This is also where a technology radar, a platform roadmap, or a similar shared decision tool can help. The goal is not bureaucracy. The goal is stability. You want the baseline platform to evolve deliberately instead of swinging with every new preference or short-term pressure.
When possible, facilitate a PoC between development and operational teams so they can learn together instead of throwing requests over a wall.
4) Challenge routine before it hardens into stagnation
Operational work can easily collapse into routine. Incident response, support queues, repeated manual steps, and platform maintenance consume attention fast.
That is exactly why architects should challenge these teams from time to time.
Ask simple questions. Can we do this better? Why is this manual? What process are we protecting that no longer makes sense? What change would reduce noise for both engineers and customers?
This is not about criticizing the team. It is about reopening space for improvement during calm periods, before the next incident makes all improvement work impossible again.
5) Build a Working Partnership
The best collaboration with operational teams does not look like a status update process. It looks like a working partnership.
Architects need these teams because they see reality after release. Operational teams need architects because architects can connect what is happening now with the design decisions that created it and the platform direction that should change it.
That partnership works best when it includes three habits:
Treat operational feedback as system insight, not noise.
Create direct channels between operations and development instead of becoming the long-term translator.
Bring operational teams into future-facing conversations early enough that they can shape the answer, not just absorb the consequences.
When those habits are missing, you get avoidable manual work, recurring incidents, and a growing gap between how the system was designed and how it actually behaves.
What to Do on Monday Morning
If you want to improve this collaboration next week, start here:
List the operational teams around your system: support, customer success, onboarding, SRE, CloudOps, and anyone else carrying post-release reality.
Ask each team what manual work they do today that the product or platform should eventually remove.
Find one recurring pain point that appears in both customer feedback and operational effort.
Set up one direct conversation between development and operations around that issue instead of relaying the discussion yourself.
Share one piece of future platform direction early enough that the operational team can prepare before engineering is blocked.
Operational teams are often overlooked by architects, and that is a mistake. If you build a real communication channel with them, you stop guessing whether the system works the way you intended.
You start knowing.
Want to learn more?
🎓 Check out the courses: Explore here
🌐 Follow us on LinkedIn: Follow here
📖 Explore the Guide: Read here