The girl at the gate

The most useful demonstration of the framework in the book is not the software project. It is a college arts festival, run by a second-year art student with a committee that has never organised anything, no records from the previous year's disaster, and a city that has decided to pay attention.

Kavya has a list. Forty-odd things, in no order, all of them urgent. Sponsors, walls, permissions, printing, the artists nobody has confirmed, the budget that exists only as a rumour about what last year's cost.

What she does not have is an answer to a question that sounds, the first time you hear it, like a waste of an afternoon.

Not what do you need. What is it for.

The first step of the framework is to define the end state, alone, before any tool is opened. In practice this is the step people skip fastest, because it produces nothing. No list, no document, no visible progress. Just a person sitting with a problem.

The version that worked for Kavya was not abstract at all. Imagine the last night of the festival. Someone walks out of the college gate. Who are they, and what do they say to the person beside them?

Her answer: a second-year girl from a small town, who came half believing the art world was a locked room, walking out thinking that maybe there is a place in here for her too.

The girl at the gate.

After that, every rupee, every wall, every name on the poster got held up against her. Not against the budget, not against what last year did, not against what would look impressive on a committee report. Against one specific person walking out of one specific gate on one specific night.

What that does to the rest of the work

Almost everything downstream becomes easier, and not for motivational reasons.

The forty tasks that had refused to connect for weeks start connecting once you ask which of them cannot start until another is finished, because now you know what the finish is. The question of which student's work goes on which wall stops being a committee argument and becomes a judgement about the girl at the gate, which is Kavya's to make and no tool's.

The split between her work and the machine's work resolves itself almost automatically. The eye, the taste, the conversations with artists: hers. Reconstructing a budget from nothing, finding how festivals in other cities solved the sponsor problem, turning forty unordered tasks into a dated timeline, producing the first ugly draft of a vendor email: not hers. In her words, the intern rather than the artist.

And at the end, when the whole thing has to be checked as one object rather than as a set of parts that were each individually fine, there is something to check it against.

Why this case is in the book at all

Because the framework was invented by someone in technology, and there is a fair objection that it is an engineer's trick: eight tidy steps for tidy problems, useless the moment the work involves taste.

The festival is the answer to that objection. Nothing about it is tidy. The end state is not a specification, it is a person Kavya invented and then held everyone to. The hardest task in the project was deciding whose work goes on a wall, and no amount of clear thinking about inputs and outputs will tell you that.

What the framework did was clear enough ground around the judgement that she had the time and the attention to make it well. That is the whole claim. Not that structure replaces taste. That structure is what stops forty administrative fires from consuming the hours in which taste happens.

If you want to try one step of the eight this week, try that one. Take something you are in the middle of and describe, in one sentence, a specific person at the end of it and what they say as they walk away.

If you cannot, you have found the reason the rest of it feels harder than it should.

Continue