Three signals we use to read any team.

When teams need to improve, someone almost always buys a program: a course, a framework, a platform, an offsite. Those sit outside the job. People go back to the same calendar, same tools, and same quiet rules about who counts. Within a month the program is a memory.

Meanwhile the work keeps teaching whatever it taught before: who gets interrupted, which risks are named aloud, which shortcuts the software rewards.

We start from a simpler idea: people grow when the environment (physical and digital), social world (who is copied, who is believed), and technical layer (tools and data paths) line up with the behaviour you want. Change those together and behaviour follows. Leave them as they are and no slide deck will stick.

"You cannot get a different output from a system that is still shaped to produce the previous one. The first act is not teaching; it is rearranging the room." from field note 02.2

Environment is where attention lives: rooms, calendars, software. Social is who is in the chain when something risky is said. Technical is how information moves without another meeting. We map all three, then rebuild the smallest set that will move the behaviour you care about.

If people are genuinely getting better, you can point to something different in the work: a faster recovery after a mistake, a cleaner handoff, a decision record that matches what was said in the room. If nothing like that moves, calling it "development" is a story, not an outcome.

We hold that line plainly. Satisfaction scores and happy anecdotes are easy; they mostly measure whether people liked us. We pick a handful of concrete behaviours per engagement and read them in real documents and workflows, not in a survey months later.

Examples we have used: time from quality failure to a written post-mortem; whether revenue-affecting calls leave a one-page decision note; how often cross-team briefs name a downside, not only upside.

We write those behaviours into the work itself: decision logs, briefs, post-mortems. We re-read them on a fixed cadence. Within six weeks of a change going live, something observable should move. If it does not, we change the intervention instead of arguing about adoption.

"Anything you don't measure in the work itself, you will measure in a survey. Anything you measure in a survey, you are measuring your own popularity." from field note 03.1

Company-wide KPIs still matter for the boardroom. They arrive too late to steer a team week to week. We work on the smaller, earlier behaviours that roll up to those numbers if they are healthy.

Small habits beat big launches. A weekly ritual that survives a hard quarter changes a team more than a one-off program everyone remembers fondly.

The usual failure is not bad intent. It is a ritual that only works while one senior sponsor guards it. When they disappear, the habit dies. That is a design problem, not a motivation problem.

So we anchor habits to outputs the business already owes: a brief, a review, a log. We put ownership with someone whose job gets easier when the habit exists. We match the rhythm to the work (weekly, fortnightly, monthly), not to a template from a book.

Our test: does it still run late in the year, when no executive is in the room to cheer? If not, it was rehearsal. If yes, it is the practice.

"Capability that only exists when someone is watching is not capability. It is compliance wearing a coat." from field note 01.8

The upside of kept loops is quiet and cumulative. Meetings shorten. Decisions clarify. The team's written record becomes a source of judgement rather than an archive. People join the team already knowing how to do the work because the work teaches them as it happens. That is what we are building.