The Kitchen Doesn’t Care About Your Excuses

There is a moment in every high-stakes environment when something goes completely, objectively wrong, and the only viable response is to keep working.

In my case, it was a pantry clerk who walked into the dry storage room carrying a stack of boxes, clipped a fire sprinkler head, and discharged what I can only describe as an impressive quantity of initially greasy water across an active commercial kitchen. We were told to continue service. It took four hours for the sprinkler system technicians to arrive and resolve the situation. We dried our shoes afterward.

I have thought about that shift many times since leaving commercial kitchens for the technology industry. Not because it was the strangest thing I witnessed. It wasn’t. Not by a significant margin. However, because the response to it was so instinctively correct. Nobody called an all-hands. Nobody convened a retrospective on the water. We just kept swimming.

It turns out that lesson travels extremely well.

A few weeks ago I wrote about how a non-linear career isn’t actually non-linear, that the industries change but the underlying questions stay remarkably consistent. I want to make that argument concrete. Here’s what commercial kitchens specifically taught me about performing under pressure, and why none of it required translation when I showed up in technology.


The Kitchen Never Lies

I spent years in commercial kitchens before I spent years in technology. Western Culinary Institute. Private golf clubs. A Lebanese restaurant. Bulk production facilities turning out ten thousand pounds of macaroni and cheese a day, five days a week. Country clubs. A casino. Catering. Culinary competitions.

The environments were different. The underlying dynamics were identical.

High pressure. Constrained timelines. Mismatched team experience levels. Leadership of wildly variable quality and sobriety. Outcomes that mattered regardless of what had happened behind the scenes to produce them. Customers who neither knew nor cared about any of it.

I did not know I was learning transferable skills at the time. I thought I was learning how to cook. It turns out those were the same thing.


Same Kitchen, Different Ingredients

The technology industry has a vocabulary problem. It generates terminology at a pace that would impress a culinary school graduate. Culinary schools name everything too, usually in French. But underneath the terminology, the operational reality of a software team and a commercial kitchen are structurally almost identical.

You have a head chef and a CTO. You have line cooks and engineers. You have front of house and you have marketing. You have the person who is technically in a support role but is actually holding the entire operation together through sheer competence and quiet heroism, and that person exists in every kitchen and every engineering org I have ever encountered.

The hierarchy is real. The hierarchy is also frequently ignored when things get busy, because when things get busy everyone does what needs doing. The title matters less than the skill and the willingness to move.

The product has to ship. In a kitchen, that means service ends at a specific time regardless of what happened during prep. In software, the deadline is usually softer, and I would argue that softness causes more problems than it solves. A kitchen cannot negotiate with a hungry dining room. The discipline that creates is not optional. It is the whole job.


Expertise Is Flexibility, Not Rigidity

There is a format in culinary competition called black box. You arrive at the competition, you are handed a box of ingredients you have not seen before, and you have a defined window of time to produce something coherent and excellent from whatever is inside. No advance preparation. No recipe. Just skill and whatever is in the box.

The competitors who do well are not the ones with the most elaborate plans. They are the ones who know their fundamentals deeply enough that an unknown input doesn’t produce paralysis. It produces curiosity.

The harder version of this is what happened in some competitions when judges would walk in midway through cooking and announce a required addition. Not a gentle one. Sometimes it was Durian, a fruit so aggressively aromatic that its presence reorganizes every other decision you have made. And the timeline did not move.

The competitors who handled this gracefully shared a specific characteristic: they understood what they were already working with deeply enough to see how the new element could integrate. They were operating from understanding, not from recipe-following. Mastery, it turns out, produces adaptability rather than rigidity. The more you know, the more options you can see.

I have watched senior engineers navigate a surprise architectural requirement three days before launch with exactly the same quality. The ones who handled it well weren’t attached to their original design. They were attached to the outcome. The design was just the current best path to get there.

The ones who struggled, in the kitchen and in the codebase, were the ones who had confused knowing a recipe with knowing how to cook.


The Demo Is Not the Product

Culinary competitions sometimes include a format called hot food displayed cold. You cook an elaborate multi-course meal, seven courses, classical technique, genuine craft, and then you coat everything in aspic, a clear gelatin, to preserve its appearance for judging. The food looks extraordinary. It is presented on mirrored platters with architectural garnishes. Judges evaluate it with great seriousness.

Then it gets scraped into the garbage.

Nobody eats it. The entire exercise is about the appearance of the thing, assessed by people who will never consume it, after which it is discarded.

I have sat in enterprise software demonstrations that felt identical. A beautiful thing, carefully prepared, evaluated on appearance by people who will not use it daily, followed by a procurement process that has increasingly little to do with whether the thing actually works in a real kitchen at volume on a Saturday night.

The aspic looks great. Ship the thing that survives the sprinkler.


The Judges Don’t Care

This is the part that took me longest to fully internalize, and I think it is the most important.

In those culinary competitions where the judges walked in mid-execution and added a surprise requirement with no time extension, there was no sympathy in the scoring. None. If the Durian addition made the dish worse, you did not receive credit for the degree of difficulty. You did not get points for the fact that the constraint was late and unfair. The dish either worked or it did not.

End users operate the same way. They do not know about the sprinkler. They do not know about the scope change that arrived on Wednesday. They do not know that the original timeline was unrealistic or that the requirements shifted twice or that a key engineer was out sick during the final week.

They know if the dish works.

This is not a counsel of despair. It is a counsel of clarity. The customer’s indifference to your constraints is actually useful information, because it means the only variable worth optimizing is the outcome. Not the process narrative. Not the effort invested. The thing that lands on the plate.

Kitchens are honest environments in this way. The food either satisfies or it doesn’t. That directness, uncomfortable as it sometimes is, produces better cooks. I think it produces better engineers too, when the culture is willing to apply it.


From Soup to Python

I did not plan a career that would move from commercial kitchens to developer relations and technical writing. It happened the way most interesting careers happen. Through a sequence of decisions that made sense at the time, producing a trajectory that only looks coherent in retrospect.

But the through-line, looking back, is consistent: helping people understand difficult things under pressure, with incomplete information, against a deadline, in an environment that will not pause to accommodate the difficulty.

That is the job in a kitchen. That is the job in DevRel. That is the job in most places worth working, regardless of what you are serving.

The ingredients change. The kitchen doesn’t.

If you are standing in ankle-deep water right now wondering whether to keep going. Yes. Keep going. Dry your shoes after.

The dining room is waiting.

Facebooktwitterredditlinkedinmail

The Long Way Around

For most of my professional life, I assumed I had a collection of unrelated careers.

Over the years I worked in politics, professional kitchens, construction, technical education, developer advocacy, and technology leadership. More recently, I’ve found myself spending time on institutional memory, provenance, AI architecture, museums, archives, and historical research.

Looking at that list on paper, it feels random. A career counselor might call it a lack of focus. An Applicant Tracking System would almost certainly struggle to figure out what box to put me in.

For a long time, I viewed it the same way. Every career change felt like starting over. Every transition came with the uncomfortable feeling that everyone else had chosen a lane and stayed in it while I was wandering between industries.

It wasn’t until recently, while working on the Sovereign Systems Specification and updating my personal website, that I began to notice something unexpected.

The industries had changed.

The questions had not.

The Same Questions in Different Places

When I worked in politics, information was everything. Every statement, every policy position, and every talking point ultimately came down to a simple question:

“According to whom?”

When I worked in professional kitchens, the same question appeared in a different form. Recipes, inventory, supplier relationships, food safety procedures, and training all depended on knowledge being documented, shared, and trusted. Making the same “house ranch” recipe from memory isn’t the same as having it written in a procedure.

Construction wasn’t much different. Plans, permits, change orders, inspections, and customer agreements all relied on accurate information and a clear understanding of where that information came from. A builder who’s working from memory instead of the stamped plans builds the wrong room. That’s not a rounding error — that’s a tear-out.

Technology brought the same challenges into a new domain. Documentation, system architecture, databases, APIs, observability, and developer education all revolve around helping people understand complex systems and trust the information they are using to make decisions.

More recently, my interests have expanded into museums, archives, historical research, and AI systems. Yet even there, the same themes continue to emerge.

The questions kept reappearing in different forms:

  • How do people store knowledge?
  • How do they trust knowledge?
  • How do they lose knowledge?
  • How do they pass knowledge to the next generation?

The technology changes. The industries change. The underlying questions remain remarkably consistent.

A Phrase That Refused to Stay in One Project

While writing the Sovereign Systems Specification, I coined a phrase that I initially thought was simply a good line:

Information without provenance is just gossip.

At first, it was intended as a commentary on AI systems. Large Language Models are increasingly capable of producing convincing answers, but confidence is not the same thing as evidence. If an answer cannot be traced back to a source, its reliability becomes difficult to evaluate.

The more I thought about it, however, the more I realized the phrase applied far beyond AI. Every field where trust matters has a provenance problem.

The phrase kept showing up because the principle kept showing up.

Eventually I stopped thinking of it as an AI concept and started viewing it as a general truth.

Maybe It Wasn’t Several Careers

For years I looked at my resume and saw a collection of disconnected experiences.

Politics, culinary arts, construction, technology, education, and research.

The assumption was that these represented different chapters of my life.

What I’m beginning to suspect is that they were all chapters in the same story.

The industries were different. The tools were different. The job titles were different.

What remained constant was an interest in understanding how knowledge is created, organized, trusted, preserved, and shared.

Seen through that lens, the transitions no longer look quite so random.

Politics was about information and trust.

Kitchens were about process and knowledge transfer.

Construction was about documentation and accountability.

Technology was about systems and understanding.

Museums and archives are about preservation.

AI is forcing us to revisit all of those questions at scale.

The Questions That Follow Us

One of the unexpected benefits of getting older is that you eventually accumulate enough experiences to identify patterns that were invisible while you were living through them.

In your twenties and thirties, careers often feel like a sequence of decisions.

In your forties and fifties, they sometimes start to look more like a sequence of questions.

The jobs change.

The industries change.

The technologies change.

The questions worth asking tend to remain remarkably consistent.

Looking back, I don’t think I’ve spent thirty-five years working in a series of unrelated professions.

I think I’ve spent thirty-five years exploring the same problem from different angles.

And perhaps that’s the lesson hidden inside a long and winding career:

The most important thing you carry from one job to the next isn’t a title, a skill, or a technology.

It’s the set of questions you never stop asking.

That’s the foundation the Sovereign Systems work is built on.

<>
That’s the foundation the Sovereign Systems work is built on.

Facebooktwitterredditlinkedinmail