You can assemble a brilliant team and measure all the correct things. If the team doesn’t have a way to get better, the brilliance decays. Improvement is a practice, not an event.
I’ve watched teams plateau. Not bad teams: good ones. Teams that shipped well, had decent metrics, and were comfortable. Comfortable is the word. They’d found a groove and were running in it, and nobody noticed that the groove had become a rut because the output was still acceptable. The difference between a groove and a rut is that the rut is deeper and harder to climb out of. By the time someone notices, the team has been settling for months.
The teams that don’t plateau are the ones with a deliberate improvement practice. Not a quarterly offsite. Not a yearly strategy day. A weekly rhythm of noticing what’s not working, trying something different, and checking whether the different thing helped. This post is about the specific tools and techniques that make that rhythm possible.
Psychological safety: the foundation
Before any improvement technique works, the team needs one thing: the ability to say “this isn’t working” without fear.
Amy Edmondson’s research at Harvard identified psychological safety as the critical factor in team learning. Not trust, exactly, though trust is related. Psychological safety is the shared belief that the team is safe for interpersonal risk-taking. You can admit a mistake. You can ask a question that might seem stupid. You can challenge a decision made by someone more senior. You can say “I don’t know.”
Google’s Project Aristotle confirmed this at scale. They studied 180 teams across the company, looking for patterns that predicted team effectiveness. They tested everything: team size, seniority, co-location, individual performance ratings. The strongest predictor, by a significant margin, was psychological safety. Teams where people felt safe to take risks consistently outperformed teams where they didn’t.
This is not “being nice.” Psychologically safe teams can have fierce disagreements. They can give each other hard feedback. They can challenge ideas aggressively. The safety isn’t about comfort; it’s about the absence of punishment for honesty. You can disagree without being punished. You can fail without being shamed. You can ask for help without being judged.
Here’s what psychological safety looks like in practice:
People admit mistakes quickly. On a psychologically safe team, “I deployed a bug to production” is followed by “let’s fix it.” On an unsafe team, the same mistake is hidden as long as possible because admitting it means blame. The hiding makes the mistake worse. The fear of blame is more expensive than the bug.
Questions outnumber statements. On a safe team, people ask questions in meetings: “Why are we doing it this way? What if we tried this instead? Has anyone considered…?” On an unsafe team, people wait until after the meeting to ask questions, privately, in hallways, because asking in the meeting feels too risky.
Silence is rare. When the tech lead asks “does anyone see a problem with this approach?” and gets silence, that’s not agreement. That’s fear. On a safe team, someone would say “actually, I’m worried about the performance implications.” On an unsafe team, they think it and say nothing.
Junior people speak. One of the most reliable indicators of safety is whether junior team members contribute in discussions. If only senior people talk, the team isn’t safe for juniors. And juniors often see things that seniors miss, because they haven’t yet learned to accept the things that senior people have stopped questioning.
Building psychological safety is a leadership behaviour, not a policy. It’s built through hundreds of small moments: how the team lead responds when someone admits a mistake, whether questions are welcomed or deflected, whether dissent is treated as a contribution or an irritation. You can’t mandate safety. You can only model it, consistently, until the team believes it.
Feedback: the skill nobody teaches
Most people are terrible at giving feedback. Not because they’re unkind, but because nobody taught them how. The default mode is either to avoid feedback entirely (comfortable, useless) or to deliver it as criticism (uncomfortable, counterproductive). Neither helps anyone improve.
Good feedback has a structure. There are several models; the one I find most practical is Situation-Behaviour-Impact (SBI).
Situation: Describe the specific context. “In yesterday’s sprint planning…”
Behaviour: Describe the observable behaviour. Not your interpretation. Not their intent. What you saw. “…you interrupted Priya twice while she was explaining the acceptance criteria.”
Impact: Describe the effect. On you, on the team, on the work. “It made it hard for the team to understand the requirements, and I noticed Priya stopped contributing for the rest of the session.”
That’s it. No judgement about their character. No assumption about their intent. No “you always do this.” Just: here’s what happened, here’s what I saw you do, here’s the effect it had.
The reason SBI works is that it gives the other person information they can act on. “You’re a bad communicator” is unfalsifiable and paralysing. “You interrupted Priya twice and she stopped contributing” is specific and fixable. Maybe they didn’t realise they were interrupting. Maybe they were excited about the topic. The behaviour can change without the person feeling attacked.
Feedback timing matters. Feedback delivered three weeks after the event is archaeology, not feedback. The person can’t remember the context, can’t connect the behaviour to the situation, and feels ambushed by something they thought was over. Feedback should land within a day or two, while the memory is fresh enough to be actionable.
Feedback direction matters. Most organisations only have downward feedback: manager to report. This is the least useful direction. The people with the most useful feedback about a developer’s work are the developers who work alongside them every day. Peer feedback (horizontal, not hierarchical) is where the real improvement signal lives. Building a team norm of regular peer feedback is one of the highest-leverage things a team lead can do.
And positive feedback matters at least as much as constructive feedback. A team that only hears what it’s doing wrong will stop trying. Specific, timely positive feedback, “the way you refactored that service made the whole codebase easier to navigate, and I noticed two other developers adopting the same pattern”, reinforces the behaviours you want to see more of. Most teams are starved of positive feedback. Not praise: feedback. “Good job” is praise and it’s vague and forgettable. “The way you broke that migration into reversible steps meant we could roll back cleanly when the issue hit production” is feedback and it teaches.
Deliberate practice for teams
Anders Ericsson’s research on deliberate practice, the structured, effortful improvement of specific skills through focused repetition and feedback, is usually applied to individuals. A musician practises scales. A surgeon practises sutures. A developer practises kata.
But teams can practise deliberately too, and most don’t.
The idea is simple: identify a specific team capability you want to improve, design an exercise that targets it, do the exercise, reflect on what you learned, and repeat. This is different from just doing the work and hoping you get better. The work is the performance. Practice is the rehearsal.
Here are examples of deliberate team practice.
Incident simulations. Set up a scenario: a service is down, alerts are firing, customers are affected. Run the incident response process. Not as a test, as a practice. Who takes which role? How quickly does the team orient? Where does communication break down? Do the simulation, then do the retrospective. Repeat quarterly.
Architecture reviews. Take a part of the system that nobody’s looked at in six months. As a team, review the architecture. Not to fix it, but to understand it. Where are the risks? Where has drift occurred? What would break if traffic doubled? The exercise isn’t the review; it’s the team building shared understanding of a system that’s become someone’s private knowledge.
Estimation calibration. After a sprint, compare estimates to actuals. Not to blame anyone for being wrong, but to calibrate. Were you systematically optimistic? Pessimistic? Off by the same factor every time? Estimation is a skill, and skills improve with feedback. Without the comparison, there’s no feedback, and the estimates never improve.
Pairing rotations. Deliberately pair people who don’t usually work together. Not because they’ll be more productive in the short term, they probably won’t, but because cross-pollinating knowledge and working styles makes the team more resilient and more creative. The discomfort is the practice.
The key to deliberate practice is that it must be effortful and targeted. “We’ll get better by doing more work” is not practice. “We’ll get better at incident response by running a simulation every month and reviewing our performance” is practice. The difference is intention.
The improvement kata
The improvement kata comes from Toyota, via Mike Rother’s work studying Toyota’s management practices. It’s a four-step pattern for continuous improvement.
Step 1: Understand the direction. Where is the team trying to get to? Not a specific goal but a direction: “we want shorter lead times” or “we want fewer production incidents” or “we want better cross-team communication.” The direction gives the improvement work purpose.
Step 2: Grasp the current condition. What’s actually happening now? Not what you think is happening, but what’s happening. Measure it. Observe it. Write it down. This is harder than it sounds because teams are remarkably bad at seeing their own current state clearly. “We’re pretty good at deployments” is not a current condition. “Our average lead time is four days and our deployment frequency is twice a week” is.
Step 3: Set the next target condition. Not the final destination: the next step. “We want to reduce lead time from four days to two days within the next month.” The target condition should be uncomfortable but achievable. Too easy and you’re not learning. Too hard and you’ll fail and stop trying.
Step 4: Experiment toward the target. Try something. A specific change, a specific intervention, aimed at moving from the current condition toward the target condition. Run the experiment for a defined period. Measure the result. Did it work? Why or why not? What did you learn?
Then repeat from step 2. Grasp the new current condition. Set the next target. Experiment again.
The kata is powerful because it breaks improvement into small, concrete cycles. Instead of a grand “transformation initiative” that takes six months and fails spectacularly, you get a series of small experiments, each building on what the last one taught you. The failures are small and instructive. The successes are small and compounding.
I’ve seen teams use the kata on everything from deployment pipeline improvements to meeting hygiene to code review practices. The pattern works regardless of the domain because it’s not a solution; it’s a method for finding solutions.
The most important aspect of the kata is step 4: experiment. Not “decide and implement.” Experiment. The framing matters. An experiment can fail and that’s fine; you learned something. A decision that’s implemented and fails is a mistake. The language of experimentation gives the team permission to try things that might not work, which is essential for improvement because most improvements require trying several things before finding the one that works.
Coaching vs managing
There’s a difference between managing a team and coaching a team, and most team leads don’t know which one they’re doing.
Managing is about the work. Priorities, deadlines, resources, reporting. A manager asks: “Is the work on track? What’s blocking it? How do I remove the blockers?” Managing is necessary. Someone needs to keep the trains running.
Coaching is about the people. Growth, capability, learning, improvement. A coach asks: “What are you learning? Where are you struggling? What would help you get better at this?” Coaching is about building the team’s capability to do the work, not about doing the work itself.
Most team leads default to managing because it’s more concrete and more immediately satisfying. There’s a problem, you solve it, you move on. Coaching is slower, less tangible, and the results take months to show. But a manager who only manages creates a team that depends on the manager. A coach who coaches creates a team that can manage itself.
The practical difference shows up in how you respond to problems.
A developer comes to you with a technical problem. The managing response: “Here’s how to solve it.” The coaching response: “What have you tried? What do you think the options are? What are the trade-offs?” The managing response is faster. The coaching response builds the developer’s problem-solving capability so that next time they don’t need to come to you.
A team is struggling with code review turnaround. The managing response: “Set a policy: all reviews within four hours.” The coaching response: “What do you think is causing the delay? What have you tried? What could you experiment with?” The managing response might fix the symptom. The coaching response helps the team understand the cause and find their own fix, which they’ll own and sustain because it came from them.
The best team leads I’ve worked with allocate about a third of their time to coaching. They have regular one-on-ones that are about growth, not status. They ask questions more than they give answers. They create space for the team to reflect on its own performance rather than telling the team how it’s performing.
This isn’t easy. It requires patience, a tolerance for watching people struggle when you could just give them the answer, and the discipline to invest in capability when there’s always a deadline screaming for attention. But teams led by coaches improve. Teams led by managers perform until the manager leaves, and then the performance collapses because the capability was in the manager’s head, not in the team.
Retrospectives as the improvement engine
I’ve written about retrospectives at every scale elsewhere, but they deserve mention here because they’re the single most important improvement practice a team can have.
A retrospective is a structured conversation about what happened, what worked, what didn’t, and what to try differently. It’s the team’s improvement engine: the mechanism by which the team notices its own performance patterns and acts on them.
Most teams do retros badly. They’re held inconsistently, facilitated poorly, and the action items are forgotten by Tuesday. This leads to the reasonable but wrong conclusion that retros don’t work. They do work. What doesn’t work is a retro that’s an afterthought.
A good retro has three properties.
It’s regular. Every sprint, without exception. Not when there’s time. Not when something went wrong. Every sprint. Regularity builds the habit. Irregularity sends the message that improvement is optional.
It produces experiments. Not action items: experiments. “We’ll try pairing on all code reviews for the next sprint and see if it reduces turnaround time.” An experiment has a hypothesis, a timeframe, and a success criterion. An action item has a name next to it and a hope that it’ll get done.
It follows up. The next retro starts by reviewing the experiments from the last one. Did we try the thing? Did it work? What did we learn? Without follow-up, experiments are just ideas. With follow-up, they’re a feedback loop.
If your team does one improvement practice and nothing else, do retrospectives. Everything else in this post, feedback, deliberate practice, the improvement kata, can be discovered and implemented through a well-run retro process. The retro is the meta-practice: the practice of improving how you practise.
Why most team-building exercises are waste
I need to say something about team-building, because it keeps coming up and most of it is a waste of time and money.
Escape rooms. Trust falls. Cooking classes. Go-kart racing. The annual team offsite at a fancy hotel with a facilitator who makes you build bridges out of spaghetti. These activities are fun. Some of them are very fun. But they are not team-building in any meaningful sense, because they don’t build the specific capabilities the team needs to work together better.
A team that can escape a room together cannot necessarily resolve a technical disagreement productively. A team that builds a spaghetti bridge cannot necessarily give each other honest feedback. The skills don’t transfer because the contexts are too different. Escape rooms build escape-room skills. Team-building exercises build team-building-exercise skills. What you actually need is for the team to build team-working skills, and those are built by working together, reflecting on the work, and improving the working relationships.
The team activities that actually build teams are the ones that involve real work. Ensemble programming sessions where the team solves a real problem together. Architecture reviews where the team builds shared understanding of a real system. Incident simulations where the team practises responding to a real scenario. Retrospectives where the team honestly examines its own performance.
These aren’t as fun as go-kart racing, but they’re more useful by an order of magnitude. A team that has ensemble-programmed a difficult feature together has built more trust, more shared understanding, and more collaborative skill than a team that has escaped fifteen rooms.
Social activities still matter. Having dinner together, getting coffee, talking about things that aren’t work: these build the human connections that make collaboration easier. But they’re social activities, not team-building activities. Call them what they are. Don’t confuse socialising with improving.
The improvement rhythm
Put it all together and you get a rhythm.
Weekly: retrospectives. Review last sprint’s experiments. Identify what to try next. Give and receive feedback on specific behaviours. Fifteen to thirty minutes.
Monthly: deliberate practice. Run an incident simulation, do an architecture review, try an estimation calibration exercise. One to two hours.
Quarterly: improvement kata cycle. Assess the current condition against the direction. Set the next target condition. Plan the experiments for the quarter.
Continuously: coaching conversations. One-on-ones focused on growth. Questions more than answers. Building capability, not just managing output.
This isn’t a lot of time; it’s maybe two hours a week, plus a few hours a quarter. The team will spend forty hours a week doing the work regardless. Investing two of those hours in improving how the work gets done is a return on investment that compounds over months and years.
The teams that improve are not the ones that attend the best conferences, use the best tools, or have the biggest budgets. They’re the ones that have built a regular practice of noticing, trying, and reflecting. The improvement is not in the technique; it’s in the rhythm.
Starting where you are
If none of this exists on your team, don’t try to implement everything at once. That’s the intensity approach, and intensity burns out.
Start with retrospectives. One per sprint. Follow the format: what worked, what didn’t, what to try. Pick one experiment. Follow up next sprint. Do that for a month. Then add feedback: introduce SBI, practise it in pairs, make it normal. Then add a quarterly deliberate practice session. Then start the improvement kata.
Build the habit before you build the system. The habit is the hard part. Once the team is in the rhythm of reflecting and experimenting, the specific techniques matter less because the team will discover what works for them.
The practice is the point. The tools are just how you get started.