We meet on Monday and talk about what we’re going to build. Then much of the work goes quiet. Every other Thursday, we get on a call and take turns showing what we made.
I keep having the same thought during those calls: why am I hearing about this now?
I’m interested in the version that existed on Tuesday, when it was still rough. That was when someone else might have spotted a bad assumption, suggested a customer to try it with, or said the whole approach felt wrong. By the time we see the tidy version, the useful argument is harder to have.
This rhythm wasn’t always absurd. A prototype used to take weeks. We’d meet, people would build, and the next meeting was a reasonable time to see the result. Now I can have a rough idea in front of someone the same afternoon. I can shape one piece of work for an agent, set another in motion, and test a third while those run. My own way of building has changed faster than the way we work together.
I recently wrote a note to my team about this. I was frustrated by the distance between finishing code and getting something useful into a customer’s hands. A decision can wait for a meeting. A merge request can sit with a failed pipeline. A change can reach prerelease and stay there. Then something finally ships, and we still have to find out whether anyone uses it. None of those waits disappears because an agent wrote the code quickly.
I’m asking the team to work differently, but I don’t have a proven new system to announce. We’re in the middle of changing it. I’m writing this partly to work out what I think has to change in me.
Showing the unfinished thing
I post a lot of half-built ideas in Slack. Prototypes, questions, things I think we should try. Lately I’ve noticed how one-sided that can feel. I want to see what other people are trying while there’s still time to help, and I want them to tell me when my idea is wrong before I spend another day on it.
What I don’t want is a daily roll call. “I worked on the backend” tells me nothing I can act on. A rough preview and a question do. So does a short explanation of what changed and what still worries you. The point of showing work is to give someone a chance to change its direction.
We use shared Slack channels for the conversation and Linear for decisions we need to find later. That matters more as agents take on work from the context we leave behind. A product choice buried in a DM is hard for the next person to recover. Confidential details stay private, of course. The part that affects the work needs to be visible.
This only works if I respond well when someone takes the risk of showing me something unfinished. If I turn every rough idea into grief or process, people will wait until it looks safe. I owe them honest feedback about what could be better, or an experiment we could try. I also have to accept that the useful feedback might be aimed at me.
It’s easy for me to ask for more visibility. Making it worth someone’s while to be visible is the harder part.
Several agents, one owner
I’ve also been rethinking the habit of working on one thing until it’s done. If I can properly shape and bound a task, give an agent the context and checks it needs, and come back to review the result, I can make progress on another piece in the meantime. I might be testing a preview or talking to a customer while agents work on separate problems.
That sounds wonderfully efficient until the results arrive. Several branches can come back plausible, incomplete, and in need of the same person’s attention. Twenty running sessions make a nice screenshot. They don’t mean we’ve helped anybody.
I don’t think the answer is to run fewer agents by default. The job is to choose work worth starting, keep each stream bounded, notice bad assumptions early, and stop work that isn’t going anywhere. When an agent finishes, somebody still has to understand what it built, test it, and integrate it with the rest.
One person has to keep hold of each piece of work. They get the merge request through review, respond when CI fails, decide who needs to look at it, and check what happens after it ships. That person may need help from Product, QA, another developer, or an agent running an end-to-end test. Knowing whose eyes a change needs is a skill I want everyone on the team to build.
The old job boundaries are already shifting. I’ve seen a product owner ship code and developers shape product decisions. QA is something all of us do when we try a feature, challenge it, and see whether it actually works. Our skills differ, but the responsibility for the result belongs to everyone involved. Some changes can be checked end to end by an agent. Others need several people trying the thing together. I don’t want one manual gate that every change queues behind, or an owner who assumes passing CI means nobody else needs to look.
I’m still learning where that judgment belongs on each piece of work. I know the cost of getting it wrong in both directions: unnecessary waiting, or a change that reaches customers with a problem someone could have caught.
The part after the merge
The more code we can make, the stranger it feels to call a merge request “done.” A change on prerelease is still waiting. A production release isn’t the end if the people it was built for don’t know it exists or can’t get started with it.
For our product, I’m pushing toward nightly production releases as the default. Other products can sensibly release several times a day. I care less about the number than the gap between something being ready and a customer being able to use it. If a release is blocked, I want the reason in the open so we can clear it.
I’m also trying to ask earlier who a substantial piece of work is for. What’s the smallest useful version they could try? How will they hear about it? The exact solution can emerge while we build, but waiting until after release to think about adoption has cost us time. Then we need to find out whether people use it and what they struggle with. Their answers start the next round.
The outcome I keep coming back to is cycle time down, customer love up. I don’t have one tidy clock for that. The work loops from an idea to a customer and back into the next idea. I can, however, see when a decision sat unanswered, when a change waited for release, and when we failed to learn whether it helped. Those waits are real even when the coding was fast.
I worry that what I’m asking for could turn into theatre. We could fill Slack with updates, run more agents, merge more code, release more often, and congratulate ourselves on motion. If I ask people to show unfinished work but don’t answer their questions, I’ve just made them narrate the bottleneck. If nobody follows a release into customer use, all that activity ends at the same old handoff.
I still want meetings when we need to decide something together. I just don’t want the meeting where we take turns proving we worked. I want to have seen the rough thing, argued about it, and helped steer it while those conversations could still matter.
We’re trying this now. I expect parts of it to be wrong. When the next Thursday call comes around, I’d like it to feel less like the first time any of us saw the work, and more like another chapter in something we’re already building together.
