Ryan Singer

Another key technique here is designing holes to fill. Also known as interface before implementation. The holes are the downhill parts. And the "edges" are the integration points. Eg I think I need the agent to parse the resume and display x, y, z, and I need the human to review at this step and approve actions a, b, c. What do I need to know to be sure this will actually work? And what do I NOT need to know yet to be sure this will work? There are places for "I know it when I see it." But "I know it when I see it" doesn't work if there are time commitments, obligations, or time pressures. In those situations we have to be selective and targeted about what we're trying to "see to know", when, and in what order.

The danger with these two levels is going to extremes. If you become too "agile iterative", you keep changing the macro plan because of local information. Meaning you go in circles. If you become too "master plan", you fix the macro plan before you have enough local information. Then you end up in the wrong place. This is why hill-climbing techniques are so important. Eg asking the right questions at the macro level, drafting a macro design, then diving down to spike at the integration boundaries to surface unknowns and detect time bombs.

You can split any design into two levels. There's a macro level, which is how it works as a system. And there's a detail level of how those things are actually implemented. In hardware, there's system design vs. parameter design. In non-fiction, there's outline vs. prose. In UX, there's breadboard vs. high-fidelity.

When you look at the earth from space, you don't see a blur. You see features you can't see from close up. Therefore design at the high level should show features you can't SEE at the low level. It should show you DIFFERENT things, SHARPLY.

My new favorite analogy for the design process is Jensen’s thing about the apple tree. I don’t know exactly where the apple is going to fall, but it’s my job to get us closer to the tree, so we can make the diving catch. Captures so many subtleties. Like how the final form is unknowable up front. But we have to do things intentionally to keep getting warmer and close in on it.

@destraynor @bmoesta 🙏

It always comes back to jobs-to-be-done. And I’ll always appreciate @bmoesta for his work, and @rjs for originally identifying the ‘milkshake man’ for me.

Design is making choices.

Many companies doing Shape Up aren't doing 6-week cycles to begin with. (I've seen hundreds of them.) The amount of time in the box isn't the main point. It's about whether projects are going in circles or dragging on due to lack of alignment on the right things early on. It's very team-specific. I see teams who don't need Shape Up at all. They just iterate their way because they're cross-functional with good judgement and alignment on a clear vision of the problem. Other teams can code with AI all day and still not know what to solve or where they're going. The gap between someone who understands the business problem and the actual systems that have to get wired together can be big. There can be multiple parties involved who will each introduce a new unknown at each step. So the interesting part of the work didn't change. We just have power tools. Some projects because 10% what they were before. Other projects become even bigger because the ambition is raised. And as always, different teams have different mixtures of skills, judgement, and alignment leading to different problems to solve.

How has the "Shape Up" 6-week sprint methodology changed, if at all, given advances in AI? @dhh @jasonfried @rjs

@kitlangton Correct.

The source of complexity is: COMPLECTING. Just stop complecting, you bozo! youtube.com/watch?v=SxdOUG…

@ryanflorence @tobi That’s been my approach so far.

@rjs I was talking to @tobi about git histories and squashing, he was adamant that you keep every commit, that history tells the story and agents can get the utility out of it

Thinking about all the times when I'm working on a design, and I see a misfit. So I do something to fix it ("ensure the categories are always shown in the same sequence so you can compare across entries...") but there's no trace of the fact that the misfit happened and was solved. Meaning it can easily be lost later when we implement or change something. Wonder if we might soon be able to have AI capture a misfit history as we work, effectively populating a test suite to catch regressions later.

Of course, when something is implemented in code, the "correction" is there as some rule. But when you're prototyping or creating a design artifact, all you have is the artifact. Not necessarily the checklist of what the artifact satisfies and therefore what further work should continue to satisfy.