The Anatomy of Practice
Someone in leadership read about how a famous product team works, and now your team has the same stand-up, the same board columns, the same fortnightly demo. You copied the practice faithfully. Six weeks (or six months) in, it is not landing. The stand-up runs long and tells you nothing you did not already know. The demo is a slideshow of activity. People are doing all the moves, and the work is no clearer than it was before.
The reflex is to decide you are doing the practice wrong, and to tighten it: a stricter timebox, a better template, a refresher session. Sometimes that helps. Often it does not, because the thing you copied was never the practice. It was the visible shell of one.
This quarter I am writing about seeing practice, and this is the piece underneath the others: what a practice actually is, and why "we have good practices" is one of the easiest sentences in product work to believe and be wrong about.
The mistake: practice means the things you can see
When teams say they "do product" or "run agile well", they usually point at the visible furniture. The ceremonies on the calendar. The artefacts in the wiki. The board with the right columns. The word practice gets quietly swapped for the word routine – a set of moves you perform on a schedule.
That swap is the misunderstanding. It makes a practice sound like something you install. Find a good one, copy its parts, run it on repeat, and you should get the result the original team got. It is the same logic as buying the same shoes as a marathoner and expecting to finish the marathon (I've got some really nice football boots btw).
There is a second version of the same error, pointing the other way: treating practice as private rehearsal, the soft work of "getting better" that you will get to once delivery calms down. Both versions miss what a practice is actually made of.
Anatomy: three parts that have to connect
A practice is not one thing. It is three, holding together.
The tools. The visible stuff: the board, the tickets, the templates, the stand-up slot, the roadmap view. This is the part that copies easily, because you can photograph it.
The skill. The know-how that makes the tools do anything: how to shape a problem before betting on it, how to run a conversation so the quiet engineer actually speaks, how to read what a customer is doing rather than what they said in the survey. This part lives in people, and it is slow to build.
The shared meaning. The reason the team does the move at all, and the team's agreement on what good looks like. Why we demo. What the stand-up is for. What counts as done beyond a ticket changing column. This part is invisible, and it is usually the first to rot.
A practice is alive only when the three are connected, and only while the team keeps re-connecting them. The stand-up works when the tool – a short daily slot – carries real skill – people who can name a blocker honestly – in service of a shared meaning – we surface trouble early so we can help each other. Pull out the skill and the meaning and you still have a stand-up. It just does nothing.
Why copied practices go hollow
This is why you can copy a practice perfectly and get nothing. You copied the part that travels – the tools – and left behind the two parts that do not fit in a screenshot.
Engineers have a blunt name for this. When something looks like the real thing but has none of the working insides, they call it cargo cult: islanders building a runway and a control tower out of straw because that was the scenery when the supply planes used to land, then waiting for planes that never come. Cargo-cult product work runs every ceremony and ships no learning. The board moves. The demo happens. Nobody can say what the team now understands that it did not understand last month.
It also explains something that otherwise looks like magic: two teams run identical ceremonies and get wildly different results. We tend to credit talent or culture. More often, one team has wired skill and shared meaning into the tools, and the other is performing the moves. Same furniture, different practice – because most of the practice was never the furniture.
Practices are grown, not installed
The useful shift is to stop thinking of a practice as a thing you adopt and start thinking of it as something a team grows and keeps alive.
That reframes a lot of common product pain.
- A practice that is "not working" is usually missing a part, not short of more parts. Before you add another ceremony, ask which of the three is thin. Is the tool wrong, or is the skill not there yet, or has the team lost the shared sense of why?
- Skill is the slow part, so a new practice will feel worse before it feels better. The first month of anything is mostly people learning the moves while the meaning is not yet shared. Abandon it there and you only ever feel the cost.
- Meaning is the part that rots quietly. A practice can keep its tools and its skill and still die, because everyone forgot the point. That is the demo nobody learns from, the retro that became a status update, the roadmap reviewed because the calendar says so. The furniture is intact; the practice has left.
None of this argues against process. It argues for knowing what a process is for. A template, a ritual, a board column earns its place when it carries skill toward a shared purpose. When it carries neither, it is not a practice. It is decoration with a recurring invite.
Diagnosing one of your own
Take one practice your team runs that quietly disappoints. The retro that goes nowhere, the refinement session everyone dreads, the roadmap review that changes nothing.
Pull it apart into the three parts, honestly:
- Tool. What is the visible shape – the slot, the artefact, the format? Is the shape itself wrong, or just tired?
- Skill. Does the team actually know how to do this well, or are we performing a move nobody was taught? Naming a missing skill is not an insult. It is the most fixable of the three.
- Meaning. Can people say, in one plain sentence, what this is for and what good looks like? If three people give three different answers, you have found the rot.
Usually one part is clearly the weak one. Strengthen that, and resist the urge to redesign the whole thing. Most struggling practices do not need to be replaced. They need the missing part put back.
A line you can reuse
When the room reaches for another ceremony to fix a broken one, try:
"Before we add anything, which part is actually missing here – the tool, the skill, or the shared sense of why? I do not think we have a tooling gap."
It moves the conversation from installing more process to repairing the practice you already have.
Seeing practice, part by part
I keep coming back, this quarter, to the idea that product work breaks down before the artefacts look wrong. This is the mechanism underneath that. A practice can keep all its visible parts – the board, the ceremony, the template – while the skill thins and the meaning fades, and from the outside everything still looks fine.
Seeing practice means looking past the furniture to whether the three parts are still connected. A team with a messy board and a shared, skilled sense of what it is doing is in far better shape than a team with an immaculate board and no idea why it keeps moving.
The question is not whether your team has good practices. It is whether anyone could still say what they are for.
What would change this week if your next "we need better process" conversation started by asking which part of the practice is actually missing?
