Now that the robots can build it, someone has to know what to build
We took two days to build something real. We spent the first one not building anything.
Building software was always hard. Writing code is difficult. (Anyone who tells you otherwise hasn't done much of it.) But hard and bottleneck are not the same thing.
The thing that decided whether software was any good? Almost never the code. It was whether anyone knew what they were building. And why. And how they'd know it had worked.
We didn't have to look at that much. The build took so long it filled the view. Months of work feel like the constraint. So we pointed at the code and called it the hard part. It was the hard part. It was rarely the bottleneck.
Coding agents change that. (Not the way the headlines say.) They don't move the bottleneck. They remove the thing hiding it. Take the build from months to days and the cover is gone. What's left is the question we'd been ducking.
What does success look like?
Sounds like a motivational poster. It's one of the hardest things a team can do. And now there's nowhere to hide from it.
So we took two days to practise. This is day one.
The bottleneck was never the code
Deciding what to build used to be a small group's job. A few product managers. A senior engineer or two. A founder with opinions. They held the question. Everyone else turned the answer into code.
That worked. The build was long enough to hide a bad answer. Three months to ship? Then a fuzzy goal costs you three slightly wasted months. (And you can always blame the timeline.) The deciding could be sloppy. The doing was slow enough to cover for it.
Collapse the doing and the cover is gone. Build the wrong thing in two days and you've built the wrong thing. Very efficiently. The cost of a fuzzy goal used to hide in the schedule. Now it turns up on Thursday afternoon.
And it isn't one person's job any more. A marketer pointing an agent at a campaign. A finance lead automating a report. A support rep wiring up a workflow. They all need a bit of the skill that used to live in the product manager.
Knowing what success looks like stopped being a specialist thing. It's a general thing now.
Nice to assert in a blog post. Harder to get good at. So we tried.
So we spent a day not building
Elanza is where I look after the tech and the team. Product isn't my remit. (I have opinions. Ask anyone.) Which makes it a bit funny that I ran a day about product thinking. Except that's the point. It isn't just the product manager's job any more. It's the whole product and engineering team's.
We ran our first hackathon where the whole organisation was involved. (We have done several hackathons with the dev team before.) Two days. Split in a strange way.
Day one: no building. No code. The whole day is for the question. Who is this for? What's the one thing it does for them? How will you know on Thursday whether it worked?
Day two (three days later): build.
The "no building" rule is the whole point. Let people open their laptops and they will build. Building feels like progress. Answering "what does success look like?" feels like a meeting. So you take the laptops away. (Metaphorically. Nobody confiscated anything.) It forces the uncomfortable thing to the front.
It didn't start that morning, though. It started a month earlier. Anyone could pitch a project. We had about twelve. Everyone ranked the ones they wanted to work on. I built the teams from that.
Twelve ideas became five. Sixteen people became five teams. The other seven weren't cut so much as out-voted. People ranked what they wanted, those ones didn't draw enough people.
What practising it looks like
Short kick-off. Then the teams found each other and vanished. Twenty minutes in, the open-plan office was empty. Every team had claimed a room and shut the door.
(For the record: I put two start times on two documents. Half the room came at 9:30. Half at 11:00. The man running the "define your goal clearly" day. Anyway.)
It looked like a flop. (I had thrown a hackathon and nobody was there.) It was the best signal of the morning. Nobody had to be herded. They picked their problem weeks ago. They wanted in.
The CFO spent the day doing laps. Part of one team, a stakeholder in another. Both touched invoicing. So he moved between rooms carrying the one thing those teams couldn't look up: what actually counts as a correct invoice. Most teams have to imagine their user. A couple could just shout down the office.
The hierarchy flattened into "people with useful things in their heads." Which is roughly the point (and a lot of fun to observe.)
And there was a whiteboard. (There is always a whiteboard.) By mid-morning it had a team named C-4, (not after the explosive, but after four words starting with the letter C). The word HADOOP! in big letters, aimed at a problem with no Hadoop in it (this was a pokemon or big data reference). A cheerful "Zin in!" (Dutch, roughly "can't wait"). "Everyone get in here!!" And a portrait of what our sales team imagines AI agents look like. (Yes, they are minions from Despicable Me.)
You don't get a whiteboard like that from a team going through the motions. (And I may have motivated them to draw something for this purpose.)
Exhibit A: there is always a whiteboard.
At 16:15 every team presented its goal and its plan. This was the bit I was nervous about. It is where a comfortable morning gets exposed. It held up. Every team could name its biggest risk. Almost every team had a plan for when that risk bit. Several had already contacted real customers and were waiting to hear back.
On a design day, "we asked a real user and we're blocked on their answer" is not a delay. It's the assignment.
They already knew
The morning after, I sent round a short, anonymous questionnaire. Not many people filled it in. (A gentle lesson about planning and my lack of patience.) Four responses. Not a dataset.
📝 Note
An interesting observation: The teams who said the hard part was agreeing on scope came out clearer than the teams who said they agreed on everything. Four answers is a hunch, but still. The conflict was helpful. The teams that argued about what to cut knew what they were building. The ones that breezed through were still a bit fuzzy.
But one question gave back something I didn't expect. Finish the sentence: "Success on Thursday looks like…"
Unprompted, this came back:
"every teammate having concrete plans of how to use Claude on Friday."
"a skill that will be used from Friday onwards."
"something that can be used in real life the same day by the person experiencing the pain."
Read them again. Nobody said "win the hackathon." Nobody said "a slick demo at 16:15." Two said Friday. The day after it all ends. The return to normal work. Hopefully with a new or improved skill.
They defined success as the thing that survives the event. Which is a big part of the argument of this piece.
That is the best evidence I have that the bet is solid. Not that the projects will be good. (They might be.) But that the people already get it. The building wasn't the point.
So, did it work?
I don't know yet.
The test isn't Thursday's demo. The test is what happens after the hackathon. Does the skill show up on a normal day, with no hackathon buzz and no silly whiteboard in the room? Will we need more practice?
What I can say after day one: the scarce skill is teachable. Or at least practisable. And a room of people from different disciplines took to it faster and better than I expected.
The robots can build it. Knowing what to build? Turns out you can get a whole company a little better at that. One slightly uncomfortable (but enjoyable) day at a time.
More on Thursday. When they're allowed to open their laptops and face the nitty gritty reality of software engineering.
