OK, another metaphor. I remember the moment pretty clearly. It was another one of those offhand comments that lands a little heavier than it probably should have.
“Arjay, you talk about restaurants so much… maybe you should just leave software and go open your own. . . ”
It was said with a laugh. I laughed too. But somewhere underneath that, there was a flicker of discomfort. Not because I wanted to leave software, but because I wondered if I had missed an opportunity to explain WHY I go back to restaurants and service so often to explain what I’m talking about. The more I sat with it, the more I realized it wasn’t accidental. I kept coming back to restaurants because, in a lot of ways, restaurants are one of the closest mirrors I’ve found for what we’re actually trying to do in software. -specifically what makes a great team develop the right software to delight our customers.
Not the technology. Not the tools. The experience.
Because at the end of the day, software—just like food—is something we make for people, and people are complicated.
They walk in with expectations, preferences, constraints, and sometimes things they don’t even know how to articulate yet. One person wants something fast. Another wants something crafted. One cares about presentation. Another just wants it to work. Some have strict limitations—dietary restrictions in one world, regulatory or security constraints in the other.
And somehow, in both cases, we’re expected to take all of that and create something that feels like it was made just for them.
That’s not a trivial problem.
If you’ve ever watched a restaurant try to get this right, it’s almost humbling. Menus are curated, not just assembled. Dishes are tested, refined, adjusted. There’s an intentionality behind what gets offered—not because it satisfies everyone perfectly, but because it strikes a balance that delights as many people as possible.
Software is no different. Or at least, it shouldn’t be.
We don’t just “build features.” We’re shaping experiences. We’re deciding what belongs on the menu, what gets refined, and what gets left off entirely. And just like a restaurant, if we try to be everything to everyone, we usually end up being memorable to no one. But it doesn’t stop there.
Because anyone who’s been to a really good restaurant knows that the food is only part of the experience. There’s something about the way it arrives. The pacing. The presentation. The subtle details that tell you someone thought about this before it reached your table. The same dish, served carelessly, feels different than when it’s placed in front of you with intention.
You still eat it. Of course you do.
But something’s missing.
And we feel that same absence in software more often than we admit–when something technically works, but feels clumsy, when the flow is just a little off, when it solves the problem, but doesn’t make us want to come back.
We tend to separate “functionality” and “experience” as if one is the real work and the other is optional polish. But in practice, they carry equal weight. One gets the job done. The other determines whether anyone wants to use it again.
It’s the difference between being fed and being welcomed.
And then there’s the moment before any of that happens: the order.
This is the part that fascinates me the most, because it’s where things quietly go wrong. A good server doesn’t just write things down. They listen. They clarify. They notice hesitation. They ask the question that helps you say what you actually meant instead of what you initially said.
“Do you want that spicy?”
“Do you have any dietary restrictions?”
“Is there anything you’re trying to avoid?”
They’re not being difficult. They’re protecting the outcome.
In software, we often rush past this part. We capture requirements. We create features, epics, and stories. We nod and move forward. But how often do we really pause and ask the second question? Or the third? How often do we uncover the constraint that changes everything?
Because just like in a restaurant, once the order goes to the kitchen, the cost of getting it wrong goes up.
And speaking of the kitchen…
If you’ve ever spent time in one, you know it’s not the calm, quiet place people imagine. It’s coordinated chaos. Heat, pressure, constant motion. But when it’s working well, there’s something almost rhythmic about it. People anticipate each other.
A plate is ready before it’s asked for. A hand reaches out at just the right moment. Communication is short, precise, and constant. There’s very little wasted movement because there can’t be. When it clicks, it’s kind of beautiful.
Software teams, at their best, feel the same way. Not because they’re moving fast for the sake of speed, but because they’re aligned. They understand the flow. They know where things are headed. They trust each other enough to move without friction.
Handoffs don’t feel like drops. They feel like continuations.
[taking the metaphor further] It’s less like passing work and more like plating it together.
But here’s where the metaphor starts to strain a bit.
Because kitchens, for all their coordination and craft, have a reputation for something else too: they can be brutal.
Long hours. High pressure. Environments that push people past what’s sustainable. And while that intensity can produce incredible results in short bursts, it comes at a cost.
In software, we don’t get to operate that way—not if we expect to keep going. This isn’t a dinner service that ends at the end of the night. It’s ongoing. Continuous. The people doing this work need to be able to show up again tomorrow, and the next day, and the next.
So we have to be careful about what we borrow from the metaphor.
Intensity? Maybe, in moments.
Sustainability? Always.
And that brings me to something I heard recently that stuck with me.
We were having dinner the other night at a place called Peregrine, and we were lucky enough to have the chef—Saif Rhaman—come to our table and welcome us to his restaurant. He was talking about how he approaches his work. Over the course of the conversation, he mentioned that he had spent time working with Will Guidara, former co-owner of Eleven Madison Park, a place known for its precision and care, and Saif shared with us a philosophy he promotes with his staff:
Every time they cook, they aim for greatness. And every time they serve someone, they do it as if this could be the best meal that person will have for the rest of their lives. There’s a closeness in that idea. A sense that what we’re doing isn’t just a transaction.
But what struck me even more was what he said next.
“We do not call ourselves–the staff and me,– ‘family’; we never use that phrase. We are a team!”
Because in a family, you don’t get to choose. You tolerate things you shouldn’t. You carry dynamics that don’t serve the work. But a team is different. A team is intentional. It’s built on shared purpose, mutual respect, and the understanding that everyone there wants to be there.
That distinction matters.
In software, we sometimes lean on the idea of “family” as a way to build connection. But it can blur lines in ways that aren’t healthy. It can make it harder to address problems, to hold standards, to evolve.
A team, on the other hand, invites accountability. It creates space for people to grow, to support each other, and to align around something they believe in.
And when that happens—when you have a team that cares about what they’re making, understands who it’s for, and works together with that shared intent—you start to see something familiar.
Not just good software. But something that feels… considered.
Something that people return to, something that, in its own way, delights.
So no, I’m probably not opening a restaurant anytime soon, but I’m also not going to stop talking about them, and here’s why. Every time I do, I’m reminded that what we’re really trying to build isn’t code. It’s an experience someone chooses to come back to.
That, to me, is a craft worth paying attention to.
