The Silent Kitchen - What Sébastien Bras Reminds Us About Building Products and Teams

The Silent Kitchen: What Sébastien Bras Reminds Us About Building Products and Teams

This morning, during my bike ride, a memory surfaced: years ago, when I was working for a B2B SaaS company building restaurant management software, I had the privilege of visiting Sébastien Bras at Le Suquet, his three-Michelin-starred restaurant in Laguiole, Aubrac. Bras was an investor in our company, and he’d invited us to experience what he’d built in that sumptuous, pastoral corner of southern France.
The visit began in his garden—a living encyclopedia of herbs and spices from around the world, each plant carefully tended in the bucolic landscape of the Aubrac plateau. It was enchanting in a way that felt both meticulous and effortless.
We then had a chance to visit the kitchen of the restaurant.
That’s where everything happens, after all. That’s where the craft you came for actually gets articulated, where the vision becomes the plate, where reputation is earned or lost with every service. I expected theater. I expected intensity. I expected the kind of kitchen I’d seen on television, where noise and shouting prevail.
What struck me most wasn’t necessarily the technique, but rather the choreography of the service and above all else the silence.

The Sound of Mastery

We’ve all absorbed the mythology of the chaotic kitchen—the screaming, the clanging, the barely controlled chaos of a dinner rush. Gordon Ramsay has built an empire on it. “Yes, chef!” shouted at maximum volume. Pans slammed for emphasis. The kitchen as controlled explosion. The brigade system as military operation, with hierarchy enforced through decibels.
This mythology is so pervasive that we accept it as the natural state of excellence under pressure. We assume that when stakes are high and standards are higher, chaos is not just inevitable but necessary—the very proof of seriousness, of commitment, of refusing to accept mediocrity.
But in Sébastien Bras’s kitchen, I heard something else entirely. In that campagnard atmosphere, with morning light filtering through the windows overlooking the Aubrac plateau, the articulation of craft was so quiet you could hear it breathe. Gestures from the personnel were graceful, intentional, minimal. A nod replaced a shout. A hand gesture replaced an explanation. People moved with the kind of economy of motion that only comes from doing something thousands of times, from working together long enough that language becomes optional.
There was a harmony to it—the kind you only hear when noise is absent. The silence wasn’t empty; it was full of focus, of respect for the work, of people who knew exactly what they were doing and didn’t need volume to prove it. You could hear the knife on the cutting board. The whisper of herbs being added to a pan. The almost imperceptible click of a plate being positioned just so.
It was art. And it was calm.
I remember standing there, trying to reconcile what I was seeing with everything I thought I knew about how excellent work happens under pressure. This was a three-Michelin-star kitchen during service. The stakes couldn’t be higher. People had traveled from around the world, paid considerable sums, waited months for reservations. One poorly executed dish, one moment of inattention, and the reputation suffered.
And yet: silence. Calm. Grace.

The Myth of Necessary Chaos

This memory returned to me this morning because I’ve been thinking about how we build software, and specifically about a book that challenges one of our industry’s most persistent myths: “It Doesn’t Have to Be Crazy at Work” by Jason Fried and David Heinemeier Hansson of 37signals.
Like the screaming kitchen, we’ve somehow decided that software development must be chaotic. We’ve normalized a particular kind of madness and given it aspirational names.
We’ve created cultures where responsiveness is valued over thoughtfulness, where “getting back to people quickly” on Slack is seen as more important than doing deep work, where the appearance of constant activity is mistaken for productivity. We’ve built tools that allow us to interrupt each other with unprecedented ease and then wondered why our best work happens outside business hours.
The irony is sharp: we’re building asynchronous communication tools while demanding synchronous availability. We’re creating software to make other people’s work more efficient while accepting brutal inefficiency in our own processes. We’re writing about the importance of focus while creating workplace cultures that make focus nearly impossible.
And like that mythological screaming kitchen, we’ve convinced ourselves this is just how it is when the stakes are high. That chaos is the price of ambition. That if you’re not constantly on, constantly available, constantly juggling, you’re not serious about your craft.
But what if, like Bras’s kitchen, it doesn’t have to be that way?

The Practice of Calm

“It Doesn’t Have to Be Crazy at Work” isn’t about lowering standards or moving slowly. It’s about recognizing that sustainable excellence requires something closer to that silent kitchen than to the mythology of chaos. The book is radical not because it proposes something entirely new, but because it insists that sanity and excellence can coexist—that they might even require each other.

Asynchronous as Default

Fried and Hansson advocate for asynchronous communication as the default mode of operation. Not because real-time communication is evil, but because constant real-time communication makes deep work impossible. When every question expects an immediate answer, when every message demands immediate attention, you’re not working—you’re performing availability.
In Bras’s kitchen, people weren’t constantly checking in with each other, constantly confirming, constantly updating status. They’d planned. They’d practiced. They trusted each other to execute their parts without constant supervision. The silence was possible because the communication had already happened—in training, in preparation, in the establishment of systems that didn’t require constant verbal reinforcement.
This is the insight: async-first isn’t about responding slowly to important things. It’s about being intentional about what qualifies as important enough to interrupt someone’s deep work. It’s about defaulting to documentation, to recorded video updates, to written proposals that people can engage with when their cognitive resources are available, not just when the notification arrives.

Reasonable Hours as Non-Negotiable

The book also advocates for something that shouldn’t be radical but somehow is: reasonable working hours. Not as a nice-to-have or a perk, but as a foundational principle. Because tired people don’t do their best work—they just do frantic work. They make mistakes that require fixing. They make decisions without considering second-order effects. They choose the fast path over the right path because they don’t have the cognitive capacity for nuance.
I think about the personnel in Bras’s kitchen. They weren’t there because of some toxic “passion” that demanded self-sacrifice. They were there because they’d mastered their craft and that craft deserved respect—including respect for their capacity, their lives outside the kitchen, their sustainability as humans and professionals.
In software, we often confuse hours with commitment, exhaustion with dedication. We celebrate the all-nighter as proof of caring, when it’s often proof of poor planning or unsustainable expectations.

Cutting Scope, Not Corners

Perhaps the most challenging practice Fried and Hansson advocate is ruthless scope cutting. Not cutting quality. Not cutting corners. Cutting scope—doing fewer things, but doing them completely and well. When you’re under pressure, the instinct is to add: add people, add hours, add parallel workstreams, add “just this one more thing” that will supposedly make everything work.
But adding usually makes things worse. More people means more communication overhead. More hours means more tired people making worse decisions. More parallel workstreams means more context switching and integration challenges.
Cutting scope forces clarity. It forces you to identify what actually matters. It forces the hard conversations about priorities that you’d otherwise defer. And paradoxically, doing less often means shipping more—because what you do ship actually works, doesn’t require extensive bug fixes, and doesn’t create technical debt that slows down everything that comes after.

Protecting Time and Attention

The book talks about protecting people’s time and attention the way you’d protect any other valuable resource. This means things like “library rules” during core working hours—quiet as the default, not the exception. It means recognizing that your calendar is not something for others to fill but something for you to defend. It means understanding that saying yes to everything is the same as saying that nothing is important.
When I watched the personnel in that kitchen, I realized they were operating in an environment deliberately designed to protect their attention. No one was being paged. No one was getting alerts. No one was expected to context switch between tasks. The environment itself enforced focus, made distraction difficult, made excellence possible.
In software development, we often do the opposite. We create environments that make distraction easy and focus heroic. We put engineers in open offices and then wonder why they come in early or stay late to get work done. We install Slack and make it the default for all communication, then wonder why no one has time for deep work. We schedule meetings back-to-back and then ask why people seem perpetually behind.
The question isn’t whether we can create environments that protect attention—it’s whether we value the work enough to make the choices that protection requires.

What Silence Reveals

In Bras’s kitchen, the silence allowed you to hear what mattered: the sizzle of butter, the knife on the board, the precise moment when something was ready. The absence of shouting didn’t mean absence of standards—it meant the standards were so internalized, so deeply embedded in practice, that they didn’t require enforcement through volume.
The silence revealed competence. It revealed trust. It revealed a shared understanding of what excellence meant that didn’t need to be constantly articulated because it was constantly practiced.
In software development, what might we hear in the silence?

The Actual Problems

First, we might actually hear the problems we’re trying to solve. Not the problems we think we’re solving, or the problems that fit neatly into our current sprint, but the real problems our users face. When you’re not in constant motion, responding to constant interruptions, you have space to sit with a problem long enough to understand it. To question your assumptions. To realize that the feature you’re building might be solving the wrong problem entirely.
Some of the best product decisions I’ve witnessed came from someone having time to think. Not time to have more meetings about thinking. Actual time to think—to sit with a problem, to sketch solutions, to play with prototypes, to read related research, to let the subconscious do its work. That kind of thinking is impossible when every hour is scheduled and every moment between meetings is filled with “quick questions” on Slack.

The Unasked Questions

In the silence, we might hear the questions we haven’t asked yet. The edge cases we’re overlooking in our rush to ship. The architectural decisions that seem fine now but will constrain us later. The places where our abstractions are leaky, where our data model doesn’t quite capture reality, where we’ve made assumptions that will come back to bite us.
Rush breeds oversimplification. Calm allows nuance. When you’re not frantically trying to hit a deadline that was set before anyone understood the problem, you can ask: “Wait, what happens if…?” You can explore the branches of the decision tree. You can discover that what looked like a simple feature actually touches six different systems and requires careful sequencing to avoid breaking things.

The Quieter Voices

Perhaps most importantly, in the silence we might hear the voice of the teammate who’s been trying to raise a concern but can’t get a word in over the noise of our process. The junior engineer who’s noticed something wrong but doesn’t feel senior enough to stop the sprint. The designer who understands that the UX we’re building won’t work for a key segment of users but hasn’t been able to get time on anyone’s calendar to discuss it. The technical writer who sees that our documentation is increasingly diverging from reality but documentation always gets cut when we’re “moving fast.”
Chaotic environments don’t just make work harder—they make hierarchies steeper. When everything is urgent and decisions need to be made quickly, the loudest voices win. The people with the most confidence, the most willingness to interrupt, the most political capital. And those aren’t always the people with the most insight, the best understanding of the problem, or the clearest view of consequences.
Calm environments create space for the full team to contribute. They make it possible for insight to come from anywhere, not just from whoever can shout loudest or schedule meetings fastest.

The Craft Underneath

Both cooking at Bras’s level and building software at the highest level are acts of craft—they require deep focus, accumulated expertise, attention to detail, and the ability to hold complex systems in your mind. Neither benefits from artificial urgency or performative intensity.
The word “craft” itself is instructive. Craft implies mastery accumulated over time. It implies standards that are internalized, not imposed. It implies pride in the work itself, not just in shipping or in metrics. It implies a relationship to the work that goes deeper than the transactional.
When we talk about “software craftsmanship,” we’re gesturing at something real—the idea that building software is not just about getting code to run but about building it in a way that respects the people who will maintain it, the users who will depend on it, and the craft itself. But you can’t practice craft in chaos. Craft requires space.

The Space to Master Fundamentals

In Bras’s kitchen, the silence was possible because fundamentals were mastered. People knew how to hold a knife, how to work a station, how to time their dishes, how to communicate with minimal friction. The fundamentals were so solid they were invisible.
In software, this means actually learning the languages and frameworks we use, not just copying from Stack Overflow. It means understanding why the patterns exist, not just applying them. It means investing in fundamentals—data structures, algorithms, system design, debugging, testing—even when it feels slower than just shipping something.
The paradox is that investing in fundamentals feels inefficient in the short term but is the only path to efficiency in the long term. Teams that understand fundamentals deeply can move quickly when it matters because they’re not constantly debugging surprising behavior or refactoring brittle code.

The Space to Build Systems, Not Just Features

The calm in Bras’s kitchen wasn’t accidental. It was the result of systems—training systems, prep systems, communication systems, recovery systems. The mise en place wasn’t just about having ingredients ready; it was about having thought through the entire flow of service so that during service, execution could be graceful.
In software, we often optimize for shipping features quickly rather than building systems that make shipping features reliably fast. We skip the documentation. We defer the refactoring. We don’t build the tooling. We don’t invest in the CI/CD pipeline. We don’t create the monitoring and observability infrastructure. And then we wonder why everything feels fragile, why every deploy is nerve-wracking, why we’re constantly fighting fires.
Building systems requires calm. It requires the ability to step back from immediate feature demands and ask what would make everything easier. It requires the slack (in the business sense, not the Slack sense) to invest in foundations.

The Space to Learn and Grow

Perhaps most importantly, craft requires the space to learn. To experiment. To fail safely. To try something, see it not work, understand why, and try differently. This is how mastery is built—through iteration, through reflection, through deliberate practice.
In chaotic environments, learning is the first thing to go. When everything is urgent, there’s no time for experimentation. When deadlines are always imminent, there’s no space for trying the new approach that might be better but requires time to learn. When you’re judged on short-term velocity, investing time in learning is punished rather than rewarded.
The personnel in Bras’s kitchen had clearly had time to learn, to practice, to develop their skills to the point where excellence was automatic. That learning didn’t happen during service. It happened in the prep time, the training time, the time when mistakes were okay because the stakes were lower. But organizations need to create that time and protect it.

What This Means in Practice

As I rode this morning, I kept thinking about those graceful gestures in that silent kitchen, and I wondered: What would our sprints look like if we designed them with that same intentionality? What would our code reviews sound like? Our standups? Our planning sessions?
Here are some concrete implications:
Design for Async First: Make synchronous communication the exception, not the default. Write things down. Record video updates. Use tools that don’t expect immediate responses. Trust people to engage with information when their cognitive resources are available.
Protect the Calendar: Defend large blocks of uninterrupted time. Make meetings the exception. When meetings are necessary, make them effective—clear agendas, clear outcomes, recorded for those who can’t attend.
Define “Done” Properly: Done doesn’t mean “code written.” It means tested, documented, reviewed, deployed, monitored. When you expand the definition of done to include all the things that make software actually maintainable, you’re forced to be realistic about capacity.
Build Slack into the System: Not the tool—the concept. Slack in the sense of reserve capacity. Buffer time between projects. Time for learning, for paying down technical debt, for responding to the unexpected without everything becoming a crisis. Organizations that run at 100% capacity are brittle.
Question Urgency: When everything is urgent, nothing is. Get better at distinguishing actual urgency from habitual urgency. Most things that feel urgent aren’t. Most things that feel like they need to be decided now can wait until tomorrow, when you’ll have better information and clearer thinking.
Measure What Matters: Velocity is not the same as value. Lines of code shipped is not the same as problems solved. Busyness is not the same as productivity. Get clear on what actually constitutes success and stop optimizing for proxies.

Conclusion: The Harmony of Good Craft

The memory of that kitchen stayed with me not because it was exotic or unusual, but because it revealed something I’d forgotten: that excellence and ease can coexist. That the highest standards don’t require chaos. That craft practiced well looks effortless not because it is easy but because the difficulty has been managed, anticipated, systematized.
When I returned to our office after that visit, I saw our work differently. The constant Slack interruptions weren’t proof of engagement—they were proof of poor boundaries. The long planning meetings weren’t proof of thoroughness—they were proof of unclear priorities. The late nights weren’t proof of dedication—they were proof of unsustainable expectations.
We were choosing chaos. Not because it was necessary, but because we didn’t believe the alternative was possible. Because we’d internalized the mythology that seriousness requires suffering, that excellence requires exhaustion, that craft requires chaos.
But I’d seen the alternative. I’d stood in that silent kitchen and watched mastery at work. I’d heard what excellence sounds like when it doesn’t need to announce itself.
Maybe we’d hear the harmony of good craft.
And maybe, just maybe, we’d build better software—and live better lives while doing it.