The answer to the first question is easy. The second one is more nuanced.
The single thing that moved the needle most was removing the ambiguity. I told my team: the expectation is that you code with an AI agent next to you. Not occasionally. Not when you feel like it. All the time.
Budgets are available. Pick your tools. Experiment with different agents. But come back at least once a week and share what you found. What worked. What didn’t. What surprised you. What frustrated you.
This isn’t “play with it when you have a quiet afternoon.” It’s “I expect you to start using this, and I want to hear about it.”
The difference matters. When AI coding is optional, people try it once, hit a rough edge, and go back to what they know. When it’s the expectation, they push through the rough edges and actually discover where it changes the game. The weekly sharing compounds fast. One person’s breakthrough becomes everyone’s shortcut.
Be very clear on your highs and lows. That’s how the team learns what works.
I don’t think there’s one single biggest risk. But there’s a pattern I keep seeing that worries me: people think AI coding means doing the same thing but more efficiently.
It doesn’t. AI changes what matters.
Everybody talks about “writing more unit tests now.” That misses the point entirely. What you actually need is a test suite that operates on many different levels. Unit tests, integration tests, smoke tests, end-to-end tests. The whole stack.
Why? Because when you’re generating code at speed, the only thing keeping you honest is a tight feedback loop. If your test suite only covers one layer, you’ll ship confidently and break things spectacularly. You need fast signals at every level telling you whether the thing actually works.
This isn’t about test coverage as a metric. It’s about cranking up testing to twelve because your rate of change just went through the roof.
Here’s the thing nobody tells you: AI is a magnifier of your codebase.
If your codebase is tight and controlled—clear conventions, well-structured modules, minimal dead code—the AI will produce more tight and controlled software. It picks up the patterns. It follows the conventions. It gives you more of what you already have.
If your codebase is a mess—dead code everywhere, loose conventions, three different ways to do the same thing—the AI will accelerate you into a bigger mess. It’ll happily use all three patterns. It’ll build on top of the dead code. It’ll match the chaos perfectly.
It’s never been easier to clean up. But you have to actually do it. Agentic coding isn’t just for building new features. It’s remarkably good at cleaning house. Lots of people don’t use it that way. They should.
There’s an important distinction here. I’m not talking about refactoring—reorganizing code into better abstractions. I’m talking about pruning. Removing things. File by file, folder by folder. Deleting what’s not needed. Simplifying what remains.
This is essential now. Without it, you get high-speed rot. When a team generates code faster than ever, the accumulation of unnecessary stuff accelerates at the same rate. What used to take months to become unwieldy now takes weeks.
Keep it clean. Keep it understandable. And keep it like that. If you let things drift, it gets messy faster than ever before.
The same magnification applies to your dependencies.
In the past, you might have accumulated a few half-used libraries. An HTTP client you mostly use. A utility library that overlaps with another one. A date library from 2019 sitting next to a newer one because nobody got around to migrating.
That was always a smell. Now it’s a real problem. AI agents see all your dependencies. When there’s ambiguity—two libraries that do similar things—the confusion bleeds into generated code. You’ll get inconsistent implementations. Mixed patterns. The kind of subtle inconsistency that’s hard to spot in review and compounds over time.
The flip side: it’s never been easier to standardize. Pick the one dependency. Let the AI help you migrate everything to it. Then remove the old one. What used to be a tedious multi-sprint cleanup is now an afternoon’s work.
All of these risks share the same root cause. People are treating AI as a speed boost for their existing workflow instead of rethinking what their workflow should be.
The teams that are getting the most out of AI coding aren’t the ones writing features faster. They’re the ones who realized that the game changed: testing at every layer matters more. A clean codebase matters more. Consistent dependencies matter more. Pruning matters more.
Speed is the easy part. Staying in control at that speed is the hard part.
What in your codebase would you be afraid to magnify?
]]>Let’s talk about how to actually do this.
First, the reality check. Rodeo Service is a specific tool for a specific problem.
Rodeo Service works when:
Rodeo Service doesn’t work when:
Be honest about which situation you’re in.
Before anyone puts on a cowboy hat, you need to establish the ground rules.
When we first did this, we kept it simple. Rodeo Service handles:
What it doesn’t handle:
The boundaries matter. Rodeo Service isn’t “do whatever anyone asks.” It’s structured availability.
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.
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.
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.
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:
Not “DM whoever’s on Rodeo” or “check the schedule.” Make it dead simple.
This is non-negotiable. You need explicit buy-in from leadership that:
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.
Don’t assign this based on who’s “available.” Ask who wants to try it.
What makes a good Rodeo engineer:
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.
The first week sets the tone.
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.
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:
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.
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.
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.
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:
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.
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:
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.
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:
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.
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.
Look, some organizations demand something. Fine. But make it human-centered:
Don’t track:
Do notice:
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.
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.
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.
Rodeo Service should have an expiration date.
Stop when:
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.
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.
]]>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
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.
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.
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.
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.
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.
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.
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.
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?
]]>The Sessions are based on my believe in Holiday Coding: a playful and informal way of learning by improving real production systems through experimentation during relaxed, stress-free “off time.”
Each Holiday Coding Session is a compact but meaningful two-hour experience, blending inspiration and practical exploration:
We’ve tackled fascinating topics and experienced powerful moments of learning:
Holiday Coding Sessions create space in a fast-paced team setting, allowing people to learn and grow through real-world exploration and practical problem-solving. They encourage authentic curiosity, revealing innovation often hidden within the complexity of actual production challenges.
If you’re intrigued by the idea, I’d love to hear what sparks your curiosity—or better yet, consider joining or starting your own Holiday Coding Sessions!
We might open up with 1 or 2 extra spots in our Thursday afternoon Holiday Coding group.
]]>The upcoming weeks we’ll be exploring the “Don’t Wake Me Up At Night” - DWMUAN - lens on engineering
The presentation can be found here: DWMUAN - Placing // Holiday Coding
]]>The presentation can be found here: Claude Code - Holiday Coding
]]>The presentation can be found here: Files and Folders - Holiday Coding
]]>Some topics are big. Some topics are small. All of them are ideas.
aka: Know your standards
It’s easier to hold the 0 line than to judge the mess.
Providing learning on the job at scale is a nut I haven’t cracked yet. I always try and provide teams with an environment where it is safe to experiment (concept: don’t wake me up at night; roll forward, don’t rebuild). A balance between getting things done and the freedom to explore (Balanced Roadmap, Uncertainty).
Still, I often find myself with too little time to guide and learn from all my colleagues. I do expect people to learn. I do expect my colleagues to keep their knowledge current. And to know their tools. I think it’s part of the profession of software engineers. The field moves fast. You have to keep up to stay relevant and keep your career path open. Especially for engineers early in their careers. With that, I don’t think it’s only about knowing the latest fancy tool. It’s not about chasing fashion. It’s also about fundamentals. Proven tricks of the trade.
I do notice however that I fall back to “basic” things that turn out not to be so “basic”. Call me arrogant, call me ignorant, call me both. Not all things I see as “obvious” are “obvious” to others. I have very smart colleagues, with talent, passion and a willingness to learn. And, thank God, the willingness to speak up. They are increasingly making me aware that there might be things I can teach. Things that have somehow shaped me as a engineer, architect, tech and product lead.
That however poses a fundamental question:
“How did I learn what I learned?”
I rarely know the answer to that question. I can tell you stories. Sometimes. But generally I barely know what and who influenced me. However, I do think I can replicate a little of what has been unique for me since my early days. Ever since I built my first BBS system in ± 1993 and my first website in 1997 I’ve had a unique advantage over fellow students and engineers.
I have always had a production system at hand to play with.
My learning was hardly ever merely theoretical. I have always been in a position with the freedom to play in production. And this, I believe, is a luxury that others don’t have. I do believe that has shaped me as an engineer, architect, product and technical leader. Having and actively creating this freedom is something that you can learn and exploit.
A first step towards getting the concept of learning with production for hobby, passion and productivity is what I call Holiday Coding.
Holiday coding is improving production systems by applying understanding through effort. It is a playful way of learning on the job in off time.
Over the next days and weeks I’ll explain more about the concept. So check in with this page from time to time if you’re interested. For now, a deep dive into the (working) definition.
Holidays.
I have holidays with kids. I have a family. Holiday means no stress, freedom to play and think. A process of starting and stopping. An hour here, two hours there. Over the period of 2 weeks it adds up. Starting and stopping, trying and retrying. Forgetting where you were, picking up where you left off, it distills the outcomes. Holidays provide both times of deep thinking and hyper focus, as well as moments of mind numbing repetitive time. Holidays provide a moment of quiet when the rest of the world is still sleeping or lounging, as well as the distractions. And while I do personally do code during my holidays, I do what I like most in my off time, the concept applies to work settings as well. It’s the spirit of holidays that count. See “off time” defined below.
Coding.
This is meant broadly. It includes coding in the broadest sense possible. Architecture, implementing 3rd party systems, shell scripting.
Improving.
We fundamentally go from something that works, to something that works and is better. Better is broad. Examples are better in readability, performance, robustness, comfort, cleanliness.
Production.
This is what sets Holiday Coding apart from Kata and Tutorials. Concepts are applied to the productive mess of production systems. Where your understanding of the whole might be limited, where real life provides uniqueness.
Systems.
We look end-to-end. While Holiday coding can function on individual functions or classes, it most often focusses on the interaction between multiple parts of the system. Holiday coding can span from infrastructure to function implementation in a single concept.
Applying.
It’s not enough to understand. One has to apply. Go from a working system to a working system.
Understanding.
It’s not just applying. ChatGPT can apply code for you. It’s about applying it in a messy situation, and through the application gain a true understanding.
Effort.
A mix of play, study and putting the work in does the trick. During a normal workday one tends to not do the repetitive thing. The things that feels unproductive, but is not. People shy away from doing the repetitive work with productivity as an excuse. Holiday Coding is not that. It often contains parts that make you feel you’re plowing through mud.
Playful.
The spirit of Holiday Coding is the spirit of play. Good natured, possibly competitive, room for improvisation, jolly, folly, individual or collaborative, with space for failure and surprise.
Way.
It’s more of a mindset, a philosophy, less of a rulebook. Any structure is there to show the way, not to be the way.
On the Job.
The benefits of Holiday coding are both to the production system and to the engineer. This means the job benefits.
Off time.
There is no guarantee on delivery. It is voluntary in nature. The holidays might be over before the concept is fully explored. The coder can hope, but should never count on nor indicate that holiday time will have an immediate productive outcome.
]]>All these add up to a team that’s more adaptable, reliable, and ready to tackle whatever comes next.
Every team has some form of a regular meeting, whether it’s a daily standup or a weekly catch-up. Start using this moment to ask a simple question:
“What’s your biggest uncertainty right now?”
Encourage each person to note down their top concern or question that’s making them feel unsure. If you can clear it up right away—great! If not, decide where and when to tackle it:
When it’s time to plan, look at your list of uncertainties and ask: “What can we do to reduce these?” The goal isn’t to solve everything at once—just to chip away at it bit by bit. Maybe it’s a quick meeting, a new ticket, or simply gathering more context.
During retrospectives, review the full list of uncertainties that came up in the last week or month. Ask yourselves:
This isn’t just about problem-solving; it’s a chance to see where your team might need support, whether it’s more clarity from leadership, more training, or bringing in an expert.
Now let’s add some structure. When estimating projects:
Capture each one as a separate ticket or task aimed specifically at reducing that uncertainty. This helps you prioritize based on unknowns, not just scope.
Want to supercharge this process? Try these two playful rules:
Example: “Why do our estimates keep missing the mark?”
When a TFO is completed, the outcome should always be a Lesson Learned.
After working through your uncertainties, capture what you’ve figured out. Creating a shared “Lessons Learned” list means everyone benefits from what each person has discovered. During retrospectives, go over this list and celebrate the learning! You’ll be amazed at how much faster your team’s knowledge grows.
Start simple—a shared document is enough. If you use a ticketing system, add your TFOs there.
At ProductHub, we even built uncertainty tracking into our platform to keep it front and center in estimates and reporting.
Building great products isn’t just about having the best ideas or the most talented team—it’s about learning fast and adapting. The faster you can turn uncertainty into knowledge, the better your outcomes. That’s why the most successful teams aren’t the ones that know everything; they’re the ones willing to say, “We’re not sure, but we’re going to find out.”
Uncertainty is a fact of life in any growing, changing, or evolving organization. It’s also a major source of stress. When people don’t know what’s going on, anxiety goes up, and confidence goes down.
The Uncertainty List gives your team a safe space to surface these unknowns, talk openly about them, and turn confusion into clarity. It’s more than just a tool for better estimates—it’s a way to build a team culture that thrives on learning and tackling the unknown head-on.
Every day, ask yourself and your team: “What’s the biggest thing we’re not sure about?” Make that uncertainty visible. Tackle it together. Learn from it.
With The Uncertainty List, you’re not just improving your process—you’re building a team that’s resilient, curious, and always ready to learn.
]]>