The aim of the presentation is to inspire and encourage engineering (leadership) to think about some of the long term and big picture effects of the AI coding craze. The presentation ends with some very practical questions that teams need to start finding answers to if they decide to go “all in” with 1 or 2 fast moving AI teams.
The slides are organised into four sections:
Key Takeaways — AI coding is a magnifier, not a magic wand. If your codebase, feedback culture, or company culture has problems, AI will amplify them. And when you go faster, you need to look further ahead.
Organisational — Pace layering, the simplicity cycle, cognitive debt, and why the handovers we lost were actually hidden quality gates. Includes a technique for unwinding fidelity when reviewing AI-generated prototypes.
Engineering Management — Where does the rigor go when AI writes code? Testing as survival, security as non-optional, LLM-as-judge, and why you shouldn’t ship slop.
Workshop Time — Fifteen questions to discuss with your team, from pace layering your technology to protecting your master branch.
Think about how a feature used to move through a team. A stakeholder had an idea. A PM sketched a wireframe. A designer turned it into a low-fi mockup, then a high-fi design. A slicer prepared the assets. A front-end engineer built it. A back-end engineer connected it. A data engineer wired the pipeline. QA tested the whole thing.
Every arrow between those roles was a handover. And every handover was a conversation.
The designer receiving a wireframe had to ask questions — “what happens when the user clicks here?” The front-end engineer looking at a design had to push back — “this animation will kill performance on mobile.” The back-end engineer reviewing the API contract had to negotiate — “we can’t expose that data without pagination.”
Nobody called these conversations “quality gates.” They didn’t feel like process. They felt like work. But they were doing something crucial: each handover forced a translation between perspectives. And in that translation, problems surfaced early, cheaply, and naturally.
Now someone with an idea and access to AI goes from concept to clickable prototype in hours. Not days. Not weeks. Hours.
This is genuinely powerful. The person building has a tight feedback loop with the material itself. They make, they see, they feel something’s off, they adjust. Twenty micro-decisions happen on intuition. The result often feels more coherent and more “on taste” than anything a committee would have produced. One person holding the full context can do things a fragmented chain never could.
But here’s what got lost: five or six conversations that used to happen automatically now happen zero times.
The designer never questioned the flow. The engineer never flagged the impossible interaction. The data engineer never pointed out the missing edge case. Nobody challenged the assumptions, because there was nobody to hand over to.
Those conversations weren’t overhead. They were the immune system.
So the prototype gets built. It looks great. It works. Time to get feedback.
And then you put it in front of the team.
What happens next is predictable and painful. Everyone reacts at once, but on completely different layers. Someone says “that button should be blue.” Someone else says “why does this step exist at all?” A third person asks “will this scale?” A fourth notices the error state is missing. The copywriter flags three labels that don’t match the brand voice.
All of this feedback is valid. None of it is on the same level. And nobody can stay on one level because the prototype makes everything visible at once.
In the old model, you couldn’t give color feedback on a wireframe — there were no colors. You couldn’t question the API design during a visual review — the API didn’t exist yet. The constraints of each phase forced focus. That focus wasn’t a limitation. It was a feature.
Now there are no phases. There’s one artifact that contains all layers simultaneously. The meeting devolves into a soup of comments jumping between flow, UI, design, UX, copy, technical feasibility, happy paths, unhappy paths, and fundamental assumptions. Often in the same sentence.
That’s not a review. That’s noise.
There’s something more insidious going on beneath the surface.
The person who built the prototype has already made dozens of decisions. They’ve already iterated. In their head, there’s a coherent narrative about why it looks and works the way it does. But that narrative is invisible to everyone else in the room.
So when people start giving feedback on six layers at once, the maker gets defensive. Not because the feedback is wrong, but because it feels like people are tearing apart something whose internal logic they can’t see. In the old model, you never had to defend your entire chain of reasoning — each step was already validated before the next one started.
Do this a few times and employee happiness starts to drop. People don’t enjoy these meetings. The maker feels attacked. The reviewers feel unheard. Everyone leaves frustrated. The speed gains from AI start feeling like they come at a human cost.
One thing that helps is thinking in pace layers — Stewart Brand’s model where different layers of a system move at different speeds.
A UI screen can be thrown away and rebuilt tomorrow. A data model lives for years. An API contract sits somewhere in between. These layers deserve different speeds of decision-making and different levels of rigor.
We’ve started applying this deliberately. Go fast on the outer layers — visual design, copy, interaction details. These are cheap to change. Go slow and deliberate on the foundational layers — data architecture, API contracts, core business logic. Have those deeper conversations early, with the right people, before anyone opens a code editor.
This helps. But it doesn’t solve the feedback soup problem.
Here’s a technique we’re experimenting with that feels promising.
You have a high-fidelity prototype. It’s done. It works. But instead of showing it as-is and inviting chaos, you ask AI to strip it back down.
In the case of, for example a browser based prototype: rebuild it as a wireframe. Grey boxes. No colors. No copy. Just structure and flow.
Then in one meeting, you walk through the prototype in rising fidelity. Five steps, ten minutes each:
You’re not building in layers. The thing is already built. You’re revealing it in layers. And each layer constrains what the room can talk about.
This is the trick: you use AI to undo what AI did, so that humans can process it the way humans need to.
The prototype exists in full fidelity for speed. But the review happens in progressive fidelity for focus. You get the benefit of AI’s compression without losing the benefit of structured human feedback.
There’s a deeper point here.
AI has accelerated the making process dramatically. But it hasn’t accelerated the human capacity to evaluate, discuss, and align. Our brains still need to separate concerns. We still need to focus on one layer at a time. We still need the psychological safety of critiquing a wireframe instead of something that looks “finished.”
The old workflow wasn’t just a production process. It was an externalized thinking process. Each phase gave people permission to think about one thing at a time. AI removed those phases because they’re no longer technically necessary. But they were always cognitively necessary.
The teams that will thrive aren’t the ones that go fastest. They’re the ones that figure out where to reintroduce structure — not because the tools need it, but because people do.
We’re all beginners at this. Hopefully fast learners.
What gates has your team lost to speed? And what would it look like to bring them back deliberately?
]]>Play isn’t the opposite of serious work. Play is how you learn at the edge of your competence.
Holiday Coding is structured play on production systems. You pick a direction, not a destination. You work on real code, but the path is yours.
Why production code? Because it drags ideas out of the laboratory and into the real world. When you apply a new concept to a codebase that matters, you find out in minutes whether it actually improves things — not in theory, but in practice.
It’s not a course — there’s no curriculum, no certification. It’s not a sprint — there’s no backlog, no velocity. It’s not a hack day — the goal isn’t to ship. The goal is to understand. The only deliverable is what you learned.
A Holiday Coding session is a 2+ hour block built around a single topic. Someone prepares a set of inspiration and hooks, then presents them in a fast-paced 20–40 minute slot. It’s not a polished keynote — it’s a presentation put together by someone with passion for the subject. The energy comes from enthusiasm, not production value.
After the presentation, participants use the remaining time for Holiday Coding: hands-on, practical exploration of the topic on real code.
The presentation is designed to work as a reference. It deliberately contains far more information than you’d normally put in a slide deck. A typical tech talk or keynote is optimized for single-time delivery — you polish every slide because the audience sees it once. Holiday Coding presentations are the opposite. They’re dense with links, ideas, and starting points so participants can come back to them later when they want to dig deeper into something that caught their attention.
This makes them fast to create, too. You don’t spend days on transitions and visual polish. You spend your time collecting the best ideas, the sharpest provocations, and the most useful references. It’s up to the presenter to pick which inspirations to focus on in their 30-minute slot — the deck is always bigger than the talk.
These are lessons learned, not laws. Ideas to spark your interest.
Not a magic wand. A magnifier. If your codebase is tight, the AI produces more tight software. If your codebase is a mess, the AI accelerates you into a bigger mess.
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.
Removing things. File by file, folder by folder. Without it, you get high-speed rot. What used to take months to become unwieldy now takes weeks.
You need a test suite that operates on many different levels. Unit tests, integration tests, smoke tests, end-to-end tests. The whole stack. Your rate of change just went through the roof. Crank testing up to twelve.
Two libraries that do similar things? The confusion bleeds into generated code. Pick the one dependency. Let the AI migrate everything. What used to be a tedious multi-sprint cleanup is now an afternoon’s work.
Engineering quality doesn’t disappear when AI writes code. It migrates — to specs, tests, constraints, and risk management. The work isn’t gone. It moved upstream.
ThoughtWorks Retreat Report (PDF)
Code review is being unbundled. It was always four functions in a trench coat: mentorship, consistency, correctness, and trust. Each one now needs a new home. Agents handle correctness. Hooks enforce consistency. Mentorship and trust stay human.
ThoughtWorks Retreat Report (PDF)
Technical debt is becoming cognitive debt. The system grows more complex than anyone can hold in their head. And it’s not just you — your users and customers carry that complexity too.
Specifications describe what should change. Constraints define what must not be touched. Constraints limit blast radius and let agents work safely across domain boundaries.
People treat AI as a speed boost for their existing workflow instead of rethinking what their workflow should be. Speed is the easy part. Staying in control at that speed is the hard part.
Deer Valley, Utah — February 2026. ThoughtWorks hosted the Future of Software Engineering Retreat on the 25th anniversary of the Agile Manifesto. The central question: what happens when AI takes over code production?
| Read the report (PDF) | Martin Fowler’s Reflections |
A new middle loop emerges. Not writing code. Not release management. Something in between. Directing agents. Evaluating output. Calibrating trust. Encoding standards and defining constraints within which agents can safely operate.
If every cousin in this world can produce “average software,” it’s your job to deliver great software. You can only do that if you deeply understand what problems you are solving for your customers.
Pair programming, ensemble development, continuous integration. These create the tight feedback loops that agent-assisted development requires. Some teams compressed sprint cadences to one week.
Simon Willison: “Your job is to deliver code you have proven to work.” Untested AI-generated PRs are a dereliction of duty. The job shifts from writing code to proving it works.
| Read the post | Simon Willison’s Blog — follow this man. |
“AI Slop” — low-quality, mass-produced, algorithmically generated code that looks polished but lacks substance. Macquarie Dictionary’s 2025 Word of the Year. Bloated functions. Silent logic errors. Hallucinated imports. No tests. Three patterns where one should exist.
The Slop Jar Rule: get caught committing untested, unverified AI-generated code three times and you’re buying the team lunch. Name it. Shame it. Don’t ship it.
Let’s get practical.
Model Context Protocol: an open standard for connecting AI agents to your tools. 10,000+ active servers. 97 million SDK downloads/month. GitHub, Slack, Postgres, Google Drive, Jira, your internal APIs — all accessible through one protocol.
Claude Code + MCP = an agent that can read your tickets, query your database, check your monitoring, and commit the fix. Write your own MCP server in dozens of lines of TypeScript or Python.
| Official docs | MCP Protocol |
A persistent configuration file that Claude reads before every conversation. Think .editorconfig for AI — it tells Claude who you are, how you work, and what matters.
Three-layer hierarchy: ~/.claude/CLAUDE.md for personal preferences (your style, your tools), ./CLAUDE.md for project conventions (check this into git!), and ./src/auth/CLAUDE.md for subdirectory overrides (domain-specific rules). Most-specific wins. Loaded automatically. Every line costs context window budget.
Start with ~50 lines. For each line ask: “Would removing this cause Claude to make a mistake?” If not, cut it.
| Anthropic Blog: Using CLAUDE.md Files | Official docs | Writing a Good CLAUDE.md |
It forces teams to explicitly codify what everyone “just knows.” This might be the most valuable artifact a team creates. More useful than most documentation. You can give your agent a persona. A tone. Constraints. Domain vocabulary. The context IS the prompt.
A SKILL.md file with instructions Claude follows when invoked. Not documentation nobody reads. Executable standards.
---
name: "tdd-writer"
description: "Write failing tests first, no implementation"
---
## Instructions here
Skills can spawn subagents, inject live data, restrict tools. From static instructions to programmable agents.
| Official docs | Anthropic Skills Repository |
Shell commands that execute at specific points in Claude’s workflow. Not suggestions Claude might forget. Rules that always execute: PreToolUse to approve or block before execution, PostToolUse to validate after completion, SessionStart to inject context before Claude sees anything.
Auto-format after every edit. Run tests before commits. Block dangerous patterns.
Cycle with Shift+Tab: Normal (asks permission for everything), Auto-Accept Edits (file edits proceed, risky ops still escalate), and Plan Mode (read-only analysis, no modifications). Additional modes include Bypass (no permission checks, isolated environments only) and Auto Mode (research preview — Claude decides what needs approval based on risk).
Point Claude at any module. It reads the code, understands the intent, and generates tests. Unit tests, edge cases, error paths — the stuff nobody ever gets around to writing. There is no excuse left for low test coverage. The tedious part is gone.
Got legacy code with zero tests? Claude can bootstrap a full test suite in minutes, not sprints.
Claude Code and the Art of TDD
Automated documentation pipelines that keep docs in sync with code. README generation. Changelog automation. API docs that reflect actual endpoints. Mermaid diagrams generated from your actual code structure — architecture docs that stay current.
If documentation requires AI to stay updated, maybe the real problem is the documentation is too coupled to implementation details.
Automated Docs with Claude Code
Claude Code Security found 500+ vulnerabilities in production open-source code. Bugs missed for decades by traditional tooling and expert code review. It reasons about data flow and attack chains. Not pattern matching. Multi-stage verification: re-examines its own results, attempts to disprove itself.
The discipline has shifted from prompt engineering to context engineering.
It’s not about crafting the perfect prompt. It’s about giving the agent the right context: CLAUDE.md, skills, hooks, file structure, test suites, constraints. The context IS the prompt.
Want to learn how the best AI products work? Read their system prompts. Leaked system prompts for Claude, ChatGPT, Gemini, Cursor, Devin, Copilot — they’re all online. They’re masterclasses in context engineering: how to give an AI a persona, how to set constraints, how to structure instructions. Great inspiration for your own CLAUDE.md and skills.
| System Prompts Collection | Awesome System Prompts | Analysis of the Leaks |
Use one LLM to evaluate the output of another. “Thinking” models drastically outperform standard models as judges. Use it to evaluate: code quality, test coverage, PR descriptions, documentation completeness. Your test suite is already an LLM judge. Think about what else could be.
| Before | After |
|---|---|
| Write code | Prove code works |
| Prompt engineering | Context engineering |
| Code review | Supervisory engineering |
| Style guides | Executable skills |
| Best practices docs | CLAUDE.md + Hooks |
| Optional testing | Testing as survival |
| Refactoring | Pruning |
Pick one. Go deep. Apply it on production code.
For Beginners: Install Claude Code and run it on your project. Write a CLAUDE.md for your repository — what does the team “just know”? Ask Claude to explain your own code back to you. Generate tests for a module that has none.
For the Curious: Try Plan Mode on a refactoring you’ve been putting off. Set up a hook that auto-formats or runs tests after edits. Write a skill that enforces your team’s coding conventions. Use Claude Code to do a security review of a service. Go into plan mode to see what different testing strategies could be for your full stack.
For the Adventurous: Do a full TDD loop — write failing tests, let Claude implement, iterate. Prune: pick a folder, delete what’s dead, let Claude help you find it. Don’t code! Just tell it what to do. File by file. Folder by folder. Standardize a dependency: pick the one library, migrate everything in an afternoon. Agent vs. Agent: have one Claude instance write code, then a second instance review it — LLM-as-judge in practice. Connect an MCP server to a tool you use daily. Make Claude talk to your infrastructure.
The Recipé: Wander and be inspired. Pick a concept. Apply it in full on production code. Power through reality!
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
]]>