When Process Becomes the Problem - Why Opening Doors Beats Building Walls
There’s a moment in every tech organization when things start to crack. Not the code—though that’s probably cracking too—but the space between teams. Between engineering and the rest of the company. Between what was promised and what can actually be delivered.
You know the moment I’m talking about. Bugs are piling up faster than they’re getting fixed. Customer support is escalating everything. Sales is making commitments that engineering finds out about on Slack. Leadership is asking “when will it be ready” with increasing frequency and decreasing patience.
The instinct, for most technical leaders, is to build walls.
Create a ticketing system. Implement approval workflows. Route all requests through product. Send people links to Jira. Establish “focus time” where the team can’t be interrupted. Build barriers between engineering and everyone else who seems determined to distract them from shipping.
I understand this instinct. I’ve done it myself.
But here’s what I learned ten years ago when my own team hit this breaking point: when things are truly on fire, process doesn’t put out the flames. It just makes people angrier about how long it takes to report the smoke.
A practical field guide is available here
The Frustration Spiral
Let’s talk about what’s actually happening when organizations reach this point.
It’s not just that there are bugs. Every production system has bugs. It’s not just that people are stressed.
What’s happening is that trust is eroding. The rest of the organization doesn’t understand why fixes take so long. Engineering doesn’t understand why people can’t just log a ticket and wait their turn. Everyone is frustrated. Everyone feels unheard. Everyone is right, from their perspective.
This is when culture starts to crack.
And this is exactly when most teams respond by adding more process. More gates. More ticket fields. More structured communication. The reasoning makes sense: if we can just get people to follow the process, we can manage the chaos.
But process is designed for normal operations. It catches your everyday occurrence of this issue. When you’re in a frustration spiral, process becomes one more thing people are angry about.
The Counterintuitive Play
Ten years ago, I tried something completely different.
Instead of building walls to give the team focus time, we opened the doors as wide as we could. We designated rotating “Rodeo Service” duty—one or two engineers each week whose primary job was to be as reachable as possible. Take the calls. Walk over to desks. Jump on a call. Triage everything that came in. Fix what could be fixed quickly. Communicate clearly about what couldn’t. Get a “real time” sense of the issues.
We brought cowboy hats for the engineers on duty.
And we had one non-negotiable rule: if you want Rodeo’s attention, you talk to a human. Five to ten minutes. On camera or in person. Actual conversation.
No tickets as the entry point. No Slack messages. No lists of requirements or prioritized spreadsheets. You want help? You talk to the person wearing the cowboy hat.
This sounds extreme until you understand what it actually does.
First, it’s a filter for real urgency. If someone won’t invest ten minutes in a conversation about their “critical” issue, it’s not actually critical. When everything routes through tickets, everything can claim to be urgent—there’s no cost to escalating. But asking someone to get on a call? That requires them to actually believe it matters.
Second, it’s an anti-weaponization mechanism. I’ve seen plenty of tickets that read like attacks. “This STILL doesn’t work. WHEN will this be fixed? This is COMPLETELY unacceptable.” The same person on a call sounds different. “Hey, I’m getting customer complaints about this export feature. Can we look at it?” It’s much harder to be mean to someone’s face than to weaponize a Jira ticket.
Third, it forces context to flow. When you’re on a call, you can ask follow-up questions in real time. “Who’s affected? What’s the actual impact? Is there a workaround? What happens if we fix it tomorrow instead of today?” Tickets don’t have this. They’re static snapshots, often missing crucial context.
I knew what I hoped for: that human contact could solve what process couldn’t. That the temperature would drop. That context would flow both directions. That trust could rebuild.
It worked.
Why This Works When Process Doesn’t
Process is designed to scale. You build a system that works at steady state, then you follow it. This is good and necessary for sustainable operations.
But when you’re in crisis mode, you don’t have a scale problem. You have a trust problem and a context problem.
Trust erodes when people feel like they’re shouting into a void. When their urgent request gets auto-responded with a ticket number and a reminder about SLAs. When they’re told their critical issue is “in the backlog” with no clarity about when or if it will be addressed.
Context degrades when engineers only see tickets, not people. When they’re optimizing for closing Jira issues rather than solving actual business problems. When they make technical decisions without understanding the commercial impact.
Human contact solves both of these problems in ways that process cannot.
When someone can walk up to the engineer and say “this customer is about to churn if we don’t fix this,” that engineer can get the context. When that engineer can explain “here’s why that’s hard and here’s what we can do today,” and discuss potential short term workarounds you have trust.
And when both of those people are looking at each other—on camera or in person—the conversation stays human. The engineer remembers they’re helping a real person with a real problem. The stakeholder remembers they’re talking to someone who’s genuinely trying to help, not “the system that’s ignoring them.”
You can’t get this from tickets. You can’t get this from Slack threads. You can only get this from actual conversation.
But Won’t This Just Burn People Out?
This is always one of the first objections, and it’s a reasonable one.
The answer is: it depends entirely on how you do it.
If Rodeo Service becomes “everyone dumps on these engineers all week,” then yes, it’s brutal and unsustainable. If it’s a recognition that things are broken and this is the temporary measure while we fix the underlying issues, it can actually be energizing.
I’ve seen plenty of engineers volunteer for Rodeo duty. Multiple rotations in a row. Not because they’re masochists, but because they find it satisfying. There’s something deeply rewarding about short-term problem solving. About being the person who helps. About getting thank-yous directly instead of through layers of tickets and product managers.
The ten-minute conversation requirement actually protects against burnout. It filters out the noise. The person who fires off fifteen “urgent” tickets in a day won’t schedule fifteen ten-minute calls. The real issues surface. The email-courage complaints disappear.
The key is that it can’t be permanent. If your team needs dedicated Rodeo Service for months on end, you don’t have a communication problem. You have a foundational problem that needs different solutions.
But as a circuit breaker? As a way to stop the frustration spiral and buy time to actually fix things? It’s remarkably effective.
What This Reveals About Your Organization
Here’s what implementing Rodeo Service will tell you about your team:
You’ll discover who actually likes human contact. There’s this myth that all engineers hate talking to people. It’s nonsense. Some engineers thrive on it. Some absolutely don’t. Both preferences are fine. But you need to know who is who.
You’ll see where the real communication gaps are. The issues that flood Rodeo Service—the ones people are willing to get on calls about—show you exactly where your organization lacks shared understanding. These are the areas that need fixing, not more documentation or process.
You’ll learn whether your team culture is healthy. If nobody wants to do Rodeo Service ever, or if people fight about who has to do it, that’s a signal. If people naturally rotate through it and it becomes a badge of honor, that’s a different signal.
You’ll understand what “urgent” actually means. When everything is filed as P0 in Jira, nothing is actually urgent. The ten-minute conversation requirement forces people to think: is this worth ten minutes of my time to explain? If not, it goes through normal product management channels. This natural sorting happens without anyone having to play process cop.
You’ll see what gets lost in tickets. The nuance. The context. The “by the way, this is also affecting X.” The human understanding of trade-offs. All of this comes out in conversation and gets buried in ticket fields.
The Cultural Statement
Requiring conversation isn’t just a tactical choice. It’s a statement about culture.
It says: we’re not hiding behind process. We’re not making you navigate a bureaucracy to talk to an engineer. We’re not treating you like a ticket number. We’re humans solving problems together, and that requires actually talking to each other.
When we implemented this, some people initially resisted. “I just want to send a quick message, why do I have to get on a call?”
Because if it’s actually quick, a ten-minute call resolves it faster than a ticket thread that takes days. And if it’s not actually quick, you shouldn’t be framing it as something that needs to interrupt focused work.
Within a few weeks, everyone adapted. The people who genuinely had urgent issues appreciated the direct access. The people who were just venting learned to route things through normal product processes instead. And the Rodeo engineers weren’t drowning in a flood of tickets claiming equal priority.
There’s something powerful about removing all the machinery between “I need help” and “let me help you.” No forms. No routing. No approval chains. Just: talk to me about what’s broken.
When You Should Try This
Rodeo Service isn’t for every situation. It’s not a replacement for good incident management or sustainable support practices.
But if you’re seeing these signs, it might be exactly what you need:
The gap between what the business expects and what tech can deliver is widening. Communication between engineering and other teams has become tense or adversarial. Your team is drowning in interruptions despite having all the “right” processes in place. People are escalating around your ticket system rather than through it. Quality is dropping and frustration is rising in a compounding cycle.
If this sounds familiar, consider that maybe the answer isn’t better process. Maybe it’s more human contact, not less.
The Question Process Can’t Answer
Process is built on the assumption that everything can be categorized, prioritized, and queued. That if we just structure communication correctly, the chaos will resolve.
But organizations aren’t machines. They’re groups of people trying to build something together under pressure. When that pressure builds to a breaking point, spreadsheets and ticket workflows don’t ease it. Conversation does. Context does. The feeling that someone is listening and actually cares about your problem.
That’s what Rodeo Service provides. Not a perfect system. Not a permanent solution. Just a way to lower the temperature, rebuild trust, and create the space for actual fixes to happen.
And the ten-minute conversation requirement? That’s not a barrier. That’s the mechanism that makes it work. It filters for real urgency. It prevents weaponization. It forces humanity back into a system that’s lost it.
Sometimes the most sophisticated technical solution is to put on a cowboy hat and answer the phone. And to require that the person calling actually wants to talk to you like a human being.
What does pressure look like in your organization right now? And what happens when people can’t get through?