home

Implementing Rodeo Service - A Field Guide for Technical Leaders

If you read the previous piece and thought “this might actually work for us,” this guide is your implementation playbook. Not theory—what actually worked when my team tried this ten years ago, and what I’ve seen work since.

Let’s talk about how to actually do this.

Before You Start: Is Rodeo Service Right for Your Situation?

First, the reality check. Rodeo Service is a specific tool for a specific problem.

Rodeo Service works when:

  • Your team is underwater with interruptions despite having “proper” ticketing in place
  • Frustration between engineering and other teams is actively eroding trust
  • You’re in a high-pressure period (pre/post major release, growth spike, etc.)
  • Quick wins and visible responsiveness would buy time for deeper fixes
  • You have at least 4-5 engineers (smaller teams need different approaches)

Rodeo Service doesn’t work when:

  • You don’t have leadership buy-in to protect Rodeo engineers from other work
  • Your culture is so toxic that human contact would just create more conflict
  • You have product owners or team leads that are so protective, that they are afraid to let go and have people actually talk to each other.
  • When you have no way of “quickly” releasing or making changes to your software. For example, if CI/CD is fully missing or your code review processes are so stiff and slow that minor changes can’t get through.

Be honest about which situation you’re in.

Step 1: Set Up the Foundation

Before anyone puts on a cowboy hat, you need to establish the ground rules.

Define the Scope

When we first did this, we kept it simple. Rodeo Service handles:

  • All incoming bug reports and service requests
  • Triage and initial diagnosis
  • Quick fixes where possible
  • Communication about what’s happening and why
  • Routing complex issues to the right people
  • Talk to the team lead / PO / senior engineers when they want help with triaging.

What it doesn’t handle:

  • Feature development
  • Scheduled project work
  • Deep architectural decisions
  • Anything requiring days of heads-down work

The boundaries matter. Rodeo Service isn’t “do whatever anyone asks.” It’s structured availability.

Establish the Core Rule: Talk to Humans

This is the most important part of setup, and you need to be crystal clear about it from day one:

If you want Rodeo Service’s help, you have a conversation. Five to ten minutes. Face-to-face or on camera. No exceptions.

This is not the same as your normal ticketing system. This is not “log a ticket and we’ll call you.” This is: you pick up the phone, you jump on a call, you walk over to the person wearing the (proverbial) cowboy hat, and you talk to them.

If you’re not willing to invest ten minutes in a conversation about your issue, it’s not urgent enough to interrupt focused work. Route it through your normal product management processes instead.

Why this rule matters:

It filters for real urgency. The person who fires off fifteen “P0” tickets in a day won’t schedule fifteen ten-minute calls. Email courage disappears. Real problems surface.

It prevents weaponization. The ticket that says “This is COMPLETELY BROKEN and UNACCEPTABLE” becomes a much calmer “Hey, customers are reporting issues with the export feature” when you’re looking at someone.

It forces context. “The thing is broken” becomes a real conversation where engineers can ask “Which thing? What’s happening? Who’s affected? What’s the business impact?”

It protects Rodeo engineers. Without this rule, they drown in noise. With it, they have focused conversations about real problems.

How to Communicate This Rule

Send a clear message to the entire organization:

“We’re launching Rodeo Service as a way to handle urgent issues. Here’s how it works: [Engineer Name] and [Engineer Name] are on duty this week. If you have something urgent, reach out to them directly via [slack channel/phone/desk]. Be ready for a quick 5-10 minute conversation about the issue—this helps us understand context and get you help faster. If something doesn’t need immediate attention, please continue using our normal product management channels.”

Don’t apologize for the conversation requirement. Don’t frame it as a barrier. Frame it as what it is: the fastest way to get help when something actually matters.

Establish the Schedule

We ran one-week rotations. Some teams do two weeks. I don’t recommend shorter—there’s a learning curve each rotation.

For team size, we had about 15 engineers, so we did two people on Rodeo at a time. One person works for smaller teams. Two is better if you can afford it—prevents single points of failure and allows for pairing on complex stuff.

Create the Communication Channel

Set up one clear place where everyone knows to reach Rodeo Service. We used a dedicated Slack channel, but that channel’s purpose was to say “I need to talk” not to have the conversation. The conversation happens on a call or in person.

The pattern we used:

  • Someone posts in #rodeo-service: “Need help with customer export issue, can someone call me?”
  • Rodeo engineer responds: “Jumping on a call with you now” or “Can you meet me at my desk?”
  • The actual work happens in conversation

Not “DM whoever’s on Rodeo” or “check the schedule.” Make it dead simple.

Get Leadership Alignment

This is non-negotiable. You need explicit buy-in from leadership that:

  • Rodeo engineers do not have any sprint commitments during their rotation
  • Their primary responsibility that week is Rodeo, not shipping features
  • The rest of the organization understands the “talk to us” requirement
  • This is the official urgent channel, not a workaround

Have this conversation with your CEO, CPO, Head of Sales—anyone whose team will interact with Rodeo Service. Make sure they understand and endorse the conversation requirement.

Step 2: Choose Your First Rodeo Engineers

Don’t assign this based on who’s “available.” Ask who wants to try it.

What makes a good Rodeo engineer:

  • Comfortable with human interaction (doesn’t have to love it, can’t dread it)
  • Good at triaging and prioritizing quickly (almost everybody can when put on the spot!)
  • Enough system knowledge to navigate different areas
  • Can translate tech → business language (most can when in conversation!)
  • Temperament to handle pressure without getting defensive
  • Willing to have multiple 10-minute conversations throughout the day

How to identify them:

Send out a message: “We’re trying something new called Rodeo Service. Here’s what it entails [including the conversation requirement]. Who’s interested in being part of the first rotation?”

Some of your quietest engineers will volunteer. Some of your most social will say “absolutely not.” Both responses are valuable data.

For the first rotation, I strongly recommend two people and at least one volunteer. Forced participation poisons the well.

Step 3: Launch Week - Set Expectations

The first week sets the tone.

To the Organization

Send a company-wide announcement explaining what Rodeo Service is, who’s on duty, how to reach them. Make it clear this is an experiment.

Be explicit about the conversation requirement. Not as a barrier, but as the mechanism:

“When you reach out to Rodeo Service, one of the engineers will get on a quick call with you (5-10 minutes) to understand what’s happening. This helps us triage effectively and get you the right help fast. If you’re not able to jump on a call, your issue can go through our normal product management channels.”

Make Rodeo engineers visible. Actual cowboy hats work remarkably well if you’re in-office. We’ve also had big pink flamingo’s marking the rodeo desks. Make the people visible and easy to find. If you’re remote, Slack status + profile photos. The point is: no ambiguity about who to talk to.

To Rodeo Engineers

Give them permission to organize however they want. Keep notes in whatever system works for them. Track issues however makes sense. The goal is human contact and context, not process compliance.

In high-compliance environments, yes, things eventually need to get logged properly. But that can happen after the conversation. The front end should be human. The organisation should be organic.

Tell them explicitly:

  • You have permission to say “no” to non-Rodeo work
  • You have permission to enforce the conversation rule—if someone won’t get on a call, route them to normal channels
  • Quick fixes are good; rabbit holes are not
  • Communicate liberally—over-communication is the point
  • Talk to each other daily about what you’re seeing

On handling resistance to the conversation requirement:

Some people will push back: “Can’t I just send you the details?” The answer is: “For urgent issues that need Rodeo Service, we need to talk. For things that can wait, please use the normal product process. Which one is this?”

This isn’t about being difficult. It’s about the person self-selecting the right channel based on actual urgency.

To the Rest of Engineering

Make sure everyone else knows that Rodeo engineers are off-limits for sprint work. Protect them fiercely. If you are in firefighting mode all day, you can’t expect an engineer to also join a 2 hour architecture meeting that sets the future of the platform. The brain simply won’t be in as good a shape to make long term technical decisions when on Rodeo duty.

Also make sure the team understands why you’re requiring conversation: it’s not bureaucracy, it’s anti-bureaucracy. It’s removing all the machinery and getting back to humans helping humans.

Step 4: The First Conversations - What They Look Like

Here’s what actual Rodeo conversations look like in practice:

Example 1: The Quick Fix

[Slack rings]

Rodeo: “Hey, what’s going on?”

Stakeholder: “The customer dashboard is showing last week’s data instead of today’s.”

Rodeo: “Okay, is this affecting all customers or specific ones?”

Stakeholder: “All customers as far as I can tell. I’ve had three complaints this morning.”

Rodeo: “Got it. Let me check the data refresh job… ah, yeah, it failed overnight. Give me twenty minutes, I’ll fix it and confirm with you.”

[20 minutes later]

Rodeo: “Fixed. It was a API timeout issue. I’ve increased the timeout and the data is refreshing now. Let me know if you get any more reports. I do think we might have a fundamental issue that needs a longer time to solve. I’ll let the team know to look at it more deeply. However, for now, it’s fixed. If it happens again tomorrow, please contact me again. I did create a formal incident ticket, you might get a follow up on that later next week.”

Total time: 5 minutes of conversation, 20 minutes of work. No ticket. No back-and-forth. Just: problem explained, problem fixed, problem confirmed resolved.

Example 2: The Misunderstood Urgency

[Video call]

Rodeo: “What can I help with?”

Stakeholder: “The reporting feature doesn’t have the filters we talked about last month. We need them this week.”

Rodeo: “Okay, so this is a missing feature rather than something broken?”

Stakeholder: “Yeah, but it’s important.”

Rodeo: “I believe you. But this sounds like something that should go through product planning rather than Rodeo Service. Rodeo is for things that are broken or blocking people right now. Can you work with [Product Manager] to get this prioritized? I expect it to be several weeks worth of work, so don’t expect miracles immediately. Did you already consider to use [x,y,z] dashboard to see if that is good enough for now?”

Stakeholder: “Oh, I thought this was the fast channel for everything.”

Rodeo: “It’s the fast channel for urgent problems. For new features or improvements, product planning is the right place. They can help you get this scheduled properly.”

Total time: 3 minutes. Appropriately routed. No hurt feelings because it’s a human conversation, not a form rejection.

Example 3: The Context That Changes Everything

[In-person conversation]

Rodeo: “What’s going on?”

Stakeholder: “The mobile app crashes when you try to upload photos.”

Rodeo: “Okay, how many users are affected?”

Stakeholder: “I don’t know exactly, but we’ve had reports from our biggest client. They’re doing a product launch tomorrow and they need this working.”

Rodeo: “Okay, that context helps. If they’re launching tomorrow, this is genuinely urgent. Let me look at it right now. Who can I reach out to at the customer to screen share with them? It’d be great if we can ‘see it failing’ can you setup a customer call for me this morning?

Stakeholder: “Yeah, I’’ll call the customer now. Thanks for jumping on this.”

Rodeo: “No problem. While waiting for a meeting link I’ll start debugging.”

Total time: unknown, but, given that the stakeholder is willing to immediately setup a meeting with the customer, at least the urgency is really there.

Step 5: Let It Run - Resist the Urge to Measure

Here’s where most implementations go wrong: someone immediately wants dashboards showing response times, resolution rates, number of conversations.

Don’t.

The whole point of Rodeo Service is to remove the machinery and let humans back in. The moment you start measuring conversation duration or tracking ticket velocity, you’re back to optimizing for the wrong thing.

What you should pay attention to:

  • Does the atmosphere in the office change?
  • Are people less frustrated?
  • Are conversations between teams less tense?
  • Do Rodeo engineers report patterns they’re seeing?
  • Is trust rebuilding?
  • Are people respecting the conversation requirement or fighting it?

These aren’t things you measure in Jira. They’re things you feel in the room and hear in hallway conversations.

When my team first did this, I didn’t track a single metric for the first month. I just watched. Listened. Checked in with Rodeo engineers about what they were experiencing. Asked people around the company how it felt.

The data was qualitative and obvious: the temperature dropped. People were calmer. Engineers had context they didn’t have before. Problems were getting fixed that we didn’t even know existed. Roadmaps were re-aligned, the process became more human.

That’s the measurement that matters.

Step 6: The Daily Rhythm

Once Rodeo Service is running, a simple daily cadence helps:

Brief morning sync (15 min): Rodeo engineers talk to each other about what came in yesterday, what’s still open, what needs escalation. They also check: are people respecting the conversation requirement? Is anyone trying to circumvent it? Are there bigger issues at hand that might need engineering or product leadership to step in?

End-of-day wrap (15 min): Quick debrief about what got resolved, what’s rolling forward, any surprises. Then a short update to the team channel—not detailed metrics, just enough that people see activity.

Weekly retrospective (1 hour): At the end of the rotation, sit down with Rodeo engineers and ask:

  • What did we learn?
  • What worked, what didn’t
  • What patterns did you see
  • How did the conversation requirement work in practice
  • Did anyone push back hard on it
  • What should we fix
  • Who should go next

This is where the self-healing aspect kicks in. The engineers who lived in Rodeo Service for a week see things others don’t. Listen to what they tell you.

The retrospective will provide extremely valuable insights to leadership to deal with process, cultural and overall context issues.

Step 7: Triage Through Conversation

Here’s how triage actually works when it’s conversation-based:

You don’t need P0/P1/P2 definitions. You need Rodeo engineers who can have a conversation and use judgment.

The key questions in every conversation:

  • “What’s actually happening?”
  • “Who’s affected?”
  • “What’s the business impact?”
  • “Is there a workaround?”
  • “What happens if we don’t fix this today?”

These questions reveal real priority. Not formal severity levels, but actual understanding of impact.

Mind the goal of Rodeo Service - it’s about restoring trust - it’s a cultural tool - not an efficiency instrument! Even, if in hindsight, an engineer completely misjudges the priority, that’s perfectly fine as long as trust increases and the human touch is involved.

When someone insists something is urgent and Rodeo engineers assess it differently, they continue the conversation:

“I’m thinking this can wait until tomorrow because X. Am I missing context about why it needs to be today? We’re currently also working for [Person X] solving [Issue Y] and we’d like to finish that first.”

Usually that reveals either that the engineer is right, or that there’s business context they didn’t have. Either way, everyone’s smarter afterward.

And here’s the key: you can have this conversation in real time. You can’t do this in a ticket thread.

Step 8: Handling Resistance to the Conversation Requirement

Some people will resist. Here’s how to handle it:

“I don’t have time for a call, just read my message”

Response: “For urgent issues, we need real-time conversation to understand context. For things that can be handled asynchronously, please use our normal product channels. Which is this?”

“This is such a small thing, why do I need to talk?”

Response: “If it’s small, a quick call will be faster than a message thread. If it’s not small, we need to understand it properly. Either way, let’s jump on a call.”

“I already explained everything in my message”

Response: “I appreciate the detail. A quick conversation will help me ask follow-up questions and make sure I understand the full context. Can we talk now?”

“This feels like you’re making it harder to report issues”

Response: “We’re actually making it easier for urgent issues—you get direct access to an engineer immediately. For non-urgent things, the normal process is still there. This just makes sure the urgent channel stays urgent.”

The key is consistency. If you let people circumvent the conversation requirement, it collapses. Everyone will go back to firing off messages and expecting immediate responses.

Step 9: What to Track (If You Must)

Look, some organizations demand something. Fine. But make it human-centered:

Don’t track:

  • Number of conversations
  • Average conversation length
  • Time-to-resolution
  • Response SLAs

Do notice:

  • Feedback from people who used Rodeo Service (just ask them how it felt)
  • Feedback from Rodeo engineers in debriefs
  • Observed change in team/company tension
  • Patterns discovered that led to fixes
  • Context gaps identified and closed
  • Whether the conversation requirement is being respected or constantly challenged

The real win isn’t “had 47 conversations this week.” It’s “the gap between sales and engineering is no longer an active fire” or “we discovered that one workflow was generating 40% of our support load and fixed it.”

You’ll know if it’s working because you’ll feel it. The hallway conversations change. The Slack tone changes. People stop cc’ing leadership on every escalation. People stop trying to bypass the conversation requirement because they see it works.

Trust your ability to sense this. You don’t need a dashboard.

Step 10: Common Pitfalls

Pitfall 1: Letting the conversation requirement slide

This is the death of Rodeo Service. Someone sends a long message. Rodeo engineer reads it, understands it, fixes it. Seems efficient. But now everyone else sees that you don’t really need a conversation. The flood gates open.

Fix: Be religious about it. “Thanks for the detail. Let’s jump on a quick call so I can make sure I understand everything. Can you talk now?”

Pitfall 2: Rodeo becomes “do whatever anyone asks”

Someone books a conversation, then uses it to request a feature they’ve wanted for months.

Fix: “This sounds like a feature request rather than an urgent issue. Let’s route this to product planning where it can be properly prioritized.”

Pitfall 3: Measuring the wrong things

Someone starts tracking “conversations per day” or “average resolution time.”

Fix: Stop. Have a conversation with whoever’s asking for metrics about what Rodeo Service actually solves.

Pitfall 4: Rodeo becomes permanent

You’re running it for six months. It’s just “how things work now.”

Fix: This means you have foundational problems. Rodeo is buying you time. Use that time to fix the actual issues, then wind down Rodeo.

Pitfall 5: Not protecting Rodeo engineers from other work

Someone pulls a Rodeo engineer into a sprint planning meeting or asks them to review a PR.

Fix: Leadership enforcement. “They’re on Rodeo this week. Talk to them next week.”

Pitfall 6: The Product Owner or Product Manager steps in for the conversation

If you put a proxy back in place, you’re most likely rapidly slipping back into dynamics that actually created the problem to begin with.

fix: Have to PO/PM roam around and join calls, but let the engineers do the talking.

Step 11: Common Objections

Objection 1: But we need the process for compliance

Humans first, process later. If 2 people talk before they start documenting, you can then backfill any ticketing system or process after the conversation. If your process is so stiff that it doesn’t allow that, you might want to look at that first. Consider asking your PO/PM to take care of keeping the compliance in check.

Objection 2: This will lead to terrible code!

Maybe it does, maybe it doesn’t. Most engineers don’t piss in their own pond if they don’t have to. If one needs to hot wire something together to make it work, it’s a clear indication that one of the upcoming sprints might need some time reserved to polish things. If you’ve got a working system, and a happy customer, you should be able to prioritise more calmly than when working under high pressure of a non-working situation.

This does of course assume that you either trust the engineer and/or you trust your CI/CD, test suite, code review process or anything “internal” to the engineering team that catches grove mistakes. Also, depending on the area of the fix, you might put some guardrails on security. What changes you need in the internal tech team processes are things you will learn when you start Rodeo Service.

Objection 3: All my engineers hate talking to business people

I call bull crap. Engineers are just people, often people that like helping other people. Also, many engineers aspire to be “more than just engineers” in their career. They might actually love the opportunity to be involved directly. If communication in your organisation is so toxic that people don’t want to talk to people, you have a culture issue that surpasses your process problems.

Objection 4: Isn’t this the job of the PO/PM

Yeap, in the normall process, this is often put on the PO/PM. But the normal process (temporarily) doesn’t work as it should, otherwise you would not be considering rodeo service. So take a step back, remove the process, then bring back in the PO/PM with extra clarity on what stakeholder management entails. Also, during the rodeo services, the PO/PM keeps handling any normal process flow!

Objection 5: This is just the same as an engineer “being on call”

Then you’re not operating lean and mean enough. Being on call is great for stakeholder communication. It can and maybe should be part of your standard operating process. However, an engineer ‘on call’ normally does contribute to the sprint it’s an “extra task” on top of normal work, not the main focus. If you always have an engineer on call in a pressure cooker environment, you are effectively running rodeo service as part of your standard process. In that case, take a good look at your retrospectives to see what you can improve to reduce stress in the team.

Objection 6: This will only raise expectations of non-tech people, to which we can’t deliver!

That’s the counter intuitive part. It does not. Unreasonable expectations are often fuelled by lack of context. Rodeo brings the human back into the loop, and with that it brings context and normal emotion back in. This helps solve the context and the priority problems.

Step 11: When to Stop

Rodeo Service should have an expiration date.

Stop when:

  • The volume of critical interruptions has dropped
  • You’ve fixed the major patterns Rodeo identified
  • The organization has rebuilt trust enough to get back to normal processes
  • Normal processes are working again
  • The pressure situation has passed

We ran our first implementation for about three months. Then we kept it in our back pocket as something we could spin up when needed.

Have a proper retrospective when you stop. What did you learn? What would you do differently? How did the conversation requirement work? Because there probably will be a next time.

The Implementation Truth

Here’s what implementing Rodeo Service actually requires:

Leadership courage: To remove process when everyone expects you to add it

Internal Team trust: To let people organize their work as they see fit

Cultural commitment: To prioritize human connection over measurement

Boundary enforcement: To protect the conversation requirement even when it’s inconvenient

Patience: To let the benefits emerge without forcing metrics on them

The conversation requirement is the keystone. It’s the thing that makes everything else work. It filters. It humanizes. It prevents weaponization. It forces context.

Without it, Rodeo Service is just another support queue with a fun name.

With it, it’s a way to remember that behind every issue is a person trying to do their job, and the fastest path to helping them is to actually talk to them.

Ready to try this? Start with one rotation. Enforce the conversation requirement from day one. See what you learn. Trust your people to figure out the details.