All writing

Ship impact, not ceremony

A team with perfect sprints and a beautiful velocity chart, a product that barely changed, and one question to cut process down to what matters.

On paper, it was the most organized team in the building.

Two-week sprints. Planning on Monday, grooming on Wednesday, a demo and a retro every other Friday. A fifteen-minute standup every morning that somehow took thirty. Every task had story points. The velocity chart went up and to the right.

Six months in, I asked a simple question: "What's different for our customers since January?"

The room went quiet. Someone mentioned a settings page. Someone else mentioned a refactor. The chart looked great. The product looked almost the same.

When the ritual becomes the work

Every ceremony starts with a good reason. Standups help people unblock each other. Planning helps a team agree on what matters. Retros help a team learn.

But rituals have a way of outliving their reasons. The standup becomes a status report for a manager. Planning becomes a debate about whether something is a three or a five. The demo becomes slides about work instead of the work itself.

Slowly, the team gets very good at the process, and the process stops pointing anywhere.

That's ceremony: everything that looks like progress, done for its own sake.

The test I use

For every recurring meeting, document, or ritual, I ask one question:

If we stopped doing this tomorrow, would our customers notice?

Not the manager. Not the dashboard. The people we build for.

If the honest answer is no, it's a candidate to shrink, merge, or drop. If the answer is "yes, things would break", keep it and make it sharper.

With that team, we tried an experiment. For one month, we dropped estimation entirely and cut the standup to the people who were actually blocked. In their place, one rule: every day, someone shows something real that works. Not slides. Working software.

It was a little uncomfortable at first. By the end of the month, customers had noticed more changes than in the previous quarter.

Faster tools, smaller rituals

AI has made building fast. A feature that took a sprint can now take a day or two. That changes the math.

When the work is fast, the ceremony around it becomes a bigger share of the week. Two hours of planning for two days of work is a bad deal. The process should shrink as the building speeds up, not stay the same.

Keep what helps, drop what performs

None of this means process is bad. Good process is invisible. It helps people work together and then gets out of the way.

So look at your team's calendar this week. Find one ritual that only exists because it always has.

Try a month without it. Ship something real instead.

Then let your customers tell you whether you miss it.

Keep reading

More from the notebook.

Building3 min read

Praying to the servers

An index that froze the orders table, a shrine for praying while we waited, and why the best server prayer is the one nobody has to say.

Reflections3 min read

The age of personal software

In school, I built a tiny exam schedule app that almost every student on campus used for a couple of days. Then life got busy. Now AI is giving builders their weekends back.