Creating small moments of delight

A few years ago I read Will Guidara's Unreasonable Hospitality. The story at the heart of it is simple. A table of tourists at Eleven Madison Park, the fine-dining restaurant he ran, mentioned on their last day in New York that they'd never had a street hot dog.

Guidara ran down the block, bought one from a cart for a couple of dollars, got the kitchen to plate it, and served it. He's said nothing he ever served got a better reaction.

If you've watched The Bear, you've seen the remake. In "Forks", Richie sprints out for a deep-dish pizza for a family sad to leave Chicago without one.

That approach from Eleven Madison Park stuck with me. People can value a small, timely thing as much as a big-bang launch, and the job is to build a culture that encourages those small moments.

Guidara gives that a budget:

Manage 95 percent of your business down to the penny; spend the last 5 percent “foolishly.” It sounds irresponsible; in fact, it’s anything but. Because that last 5 percent has an outsize impact on the guest experience, it’s some of the smartest money you’ll ever spend.

At Eleven Madison Park that 5 percent was cash. In a software business it's engineering capacity and, more and more, AI spend.

AI made small things cheap

Back in 2013, Darragh Curran spoke about how Shipping is your company's heartbeat. The focus there was on CI/CD. He gives an example of a customer who can't save their name because the form rejects hyphens. If you can deploy in a minute, you fix the regex, ship it and reply before they've closed the tab. If deploys take days or weeks, the same bug becomes a ticket for a future sprint.

Continuous deployment took care of getting a fix live. Writing the fix still took time, and love it or hate it, that's the part AI has changed. A clearer error message or a missing option on an internal library used to sit in the backlog because it was never worth the context switch. Now a lot of that takes less than an hour.

Earlier this year I wrote this sudden access to speedy delivery makes "should we build this at all?" more important, not less. I still believe that, but a small request from someone who uses your product has already answered the question. All that's left is whether you get around to it.

What it feels like from the other side

I've been on the receiving end of this. Recently, Cubic shipped an API for managing seats, something we'd asked for a few days earlier. When they posted it in our shared Slack channel and asked for feedback, a colleague asked whether they could add authentication that wasn't tied to a particular user. Their answer was that it wasn't possible yet, but shouldn't be hard, and they'd add it to the to-do list. Six hours later, service account keys were live.

That's happened more than once over the past year. None of the requests were big, but they've added up, and Cubic now feels more like a partner than a vendor. Other tools could probably match the feature list, but I'd struggle to find another team that ships what we ask for the same afternoon.

Bringing it to platform teams

I lead developer experience teams. Our customers are the product engineers who use our tools, libraries and services. They can't take their business elsewhere, which makes it easy to treat their small requests as noise. But they can work around you, and stop asking.

So I've asked my team to lean into this mentality of delivering small moments of delight. If a developer asks for something you reckon you can do in an hour or two, you don't have to put it in the backlog first. Use your judgement, and if it won't derail committed work, just do it. When you do, post it in the team channel so everyone sees it, including the person who asked.

The sharing matters as much as the shipping, but it's not about an audit trail, or for accountabilty. On long-running projects that don't ship visible changes often, it's easy to feel like you aren't delivering anything. Small wins change that, because their value compounds. Each one shared in the channel shows this is work we value and builds momentum, and not just for the team doing the shipping. The developers using our tools see their requests land, and learn that asking is worth it.

The big stuff is still there

None of this solves the hard problems. Platform teams have plenty of them, like sprawling architecture and CI pipelines that keep getting slower. I'm not underestimating those, and small fixes don't replace the investment they need.

But those problems take quarters to move, and much of the work that moves them is invisible to the people using your tools. Developers can spend those quarters feeling like nobody's listening. A quick win or a small moment of delight shipped the same day reminds them that you value them, and that someone is paying attention in the meantime.

So when you get the chance to ship something small for someone, take it, and let them know.