At 2:06 p.m. on November 21, 2019, I wrote down what five teammates said about a new tool.

Nice to see everything at a glance. Need to use it more before I can tell. Too many miscellaneous features. Better than GitHub Projects, at least.

The tool was ZenHub, and on top of it we added story points and planning poker. That autumn, the people who had held the strongest leadership on the team had either left or were preparing to leave, and work had just started to stop running properly.

Eight days later, my memo from November 29 records what the team said. "Needs more advance explanation. Feels too rushed. People have to feel the need first. The urgent thing is estimates." Below that, a to-do list of three lines. One, formalize and standardize the sprint planning process. Two, schedule estimation. Three, blank.

Looking back, every decision in those three weeks was so textbook that it makes me laugh. Read through the language of the 37signals books and Team Topologies, which I spent the following years reading, those decisions were all variations on the same mistake. Instead of reducing load, I tried to measure it. I want to go through those decisions one at a time.

When a leader leaves, what walks out the door is not decision-making authority. It is working memory. What comes first, how far to go, where we are right now. Everything that person carried in their head lands on the whole team as load, all at once. Chapter 1 of Team Topologies describes a five-year-old team of eight that kept picking up responsibilities because it was good at its job, until sprint planning became a place where requests from every direction were thrown into the same pile, priorities could not be set, and motivation fell. We rode that curve over two months. The only difference was that our responsibilities had not grown. The heads that carried them had disappeared.

So it was not strange that the team said "the urgent thing is estimates." The people who knew where we stood were gone, so the team wanted to know where we stood. What was strange was my answer.

The way Team Topologies measures load, in chapter 3, is simple. Do not measure by lines of code or number of modules. Ask the team, without judgment: do you feel effective and able to respond in time to what you're asked to do? If the answer is no, the next step is not to measure. It is to reduce.

Story points are the exact opposite. Turn the size of each task into a number, add the numbers up, and you know how much the team can handle. And the team in November 2019 was already giving its answer. "Feels too rushed." "People have to feel the need first." I wrote those answers down and kept pushing the numbers.

Ron Jeffries, who coined the term "story points," had posted "Story Points Revisited" on his site on May 23 of that same year. He wrote that he was sorry for inventing them, and that the answer was not to estimate but to slice stories small enough. Six months before I adopted them.

If the tool had been neutral, that would have been an excuse. It wasn't. If following a tool breaks your back, it is not because you tried to lift too much. It is because the tool applied pressure in the wrong place. ZenHub's defaults were story points, velocity, and sprints. I chose the tool, and the tool chose the ceremonies.

Planning poker is a meeting where the whole team agrees on a number for every single task. Five people in a room for an hour is not a one-hour meeting. It is a five-hour meeting. A conversation with more than three people is usually a conversation with too many people, and collaboration that requires everyone to know the inside of everyone else's work is the most expensive kind of interaction there is. We put a meeting that required the whole team to know the inside of every task in front of every sprint. The meeting for measuring load was itself load.

It Doesn't Have to Be Crazy at Work sets deadlines by budget, not by estimate. People are terrible at estimating but quite good at setting a budget and spending it. The deadline is fixed, the scope is what moves, and it only moves in one direction: smaller. Shape Up calls this appetite. Not how long will it take, but how much are we willing to spend. I never flipped the question. The team asked when it would be done, and instead of refusing the question I tried to answer it more precisely. Planning poker was the name of that precision. (The Korean edition of It Doesn't Have to Be Crazy at Work came out on December 15, 2019, sixteen days after my last memo. Shape Up had been published on the web that July. I read both only after COVID.)

Team Topologies says to assign work to teams, not individuals, and that every area must be owned by exactly one team, with no shared ownership. When several teams change the same thing, nobody owns the change and nobody owns the mess it leaves behind.

When a leader leaves, what actually goes empty is this ownership. The area that person owned suddenly belongs to no one. What was needed was to designate a small team that would fully own that area. Not to throw people at the problem, but to cut the problem down until three people could carry it across the finish line. We did neither. We did not cut, and we did not reassign ownership. With ownership sitting empty, everyone gathered and put numbers on the work in that area. Put a number on a task that nobody owns and what you get is a task that nobody owns, with a number on it.

I think there are two questions to ask in front of any decision. Is the person deciding the one with the right information and context, and who is merely chiming in? And are we asking several people to make a decision that one person should make? Planning poker fails the second question. The size and timing of a task should be decided by the person who will do it, and we had turned that into a vote.

Some companies have put a name on this. Apple's DRI, the Directly Responsible Individual, attaches one name to every item on a meeting agenda, and Toss imported it wholesale. On October 1, 2025, in the middle of the backlash over the KakaoTalk redesign, Toss founder Lee Seung-gun wrote that the core of Toss's culture is the DRI: the people doing the work make the decisions that represent the company, not the executives receiving reports. Netflix's No Rules Rules puts an informed captain on every important decision, one person who gathers enough information and then decides alone and owns the outcome. Netflix does not decide by consensus. Amazon calls the same thing a single-threaded leader. Working Backwards says one person with one job is fully accountable for that job's success or failure, and adds this:

In November 2019 we had neither. No new name was attached to the areas the leavers had owned, and everyone who stayed took part in numbering every task. Ownership without a name, participation without a ceiling. Planning poker packed both into a single meeting.

Reading the November 29 feedback again, the team was saying three things. Too fast. We don't feel the need. The urgent thing is the schedule. The first two are about the tool. The third is about what the tool was standing in for. What the team wanted was not a tool. It was the answer the leavers used to have: where are we right now.

That question can be answered without a meeting. Everyone writes a paragraph before leaving on what they did today, writes on Monday what they plan to do this week, the lead writes a summary at the end of each cycle where everyone can read it, and progress is shown on a chart rather than in a status meeting. Anyone who wants to know where we are can read. We met and estimated instead.

So it would be more accurate to say that the wrong word in "the urgent thing is estimates" was not "urgent" but "estimates." Urgent was right. What we needed was not an estimate but a budget, and an owner to spend it.