Most sprint planning meetings follow a familiar pattern.

Work gets divided up. Owners volunteer for different pieces. Infrastructure starts talking about new environments, and QA begins thinking through test cases. Before long, it feels like everything has been accounted for.

Then someone asks a simple question. It may not be exactly phrased like this but it amounts to asking this:

"What has to be true before we can start?"

It’s interesting to watch what happens next.

The conversation shifts almost immediately. People stop talking about individual tasks and start talking about dependencies. Someone remembers the API contract. Another engineer points out the database migration depends on indexes that don’t exist yet. Infrastructure mentions firewall rules. QA asks whether feature flags will be available for testing.

Within a few minutes, the whiteboard is covered in arrows.

The original plan wasn’t wrong. It just wasn’t complete.

I’ve worked with engineers who naturally think this way. They don’t just see the work in front of them. They instinctively see how the work fits together.

I think of them as Chefs.

The Engineers Who See the Whole Kitchen

If you’ve ever watched the kitchen of a busy restaurant, you know it can look almost chaotic. Orders are coming in, multiple dishes are being prepared at once, and every station is focused on its own responsibilities.

Yet somehow everything comes together.

A great Chef isn’t simply cooking their own dish. They’re making sure every station has what it needs before it needs it. They notice when one part of the kitchen is about to become a bottleneck, and they adjust before anyone else realizes there’s a problem.

I’ve worked with engineers who think the same way. They’re fully engaged in their own work, but they also have an uncanny ability to see how dozens of moving pieces fit together.

They Orchestrate From Within

One mistake people make is assuming the Chef is directing everyone else.

That’s rarely what I’ve experienced.

The best Chefs aren’t standing above the team assigning work. They’re contributing alongside everyone else while quietly connecting pieces that don’t yet connect.

They notice when one engineer is about to block three others. They recognize opportunities for parallel work. They see prerequisites before they become blockers.

They don’t orchestrate from above. They orchestrate from within.

They Ask Different Questions

One thing I’ve noticed over the years is that great Chefs aren’t valuable because they always have the answers.

They’re valuable because they ask the questions that reveal the answers everyone else needs.

You’ll hear them ask questions like:

  • What do you need before you can start?
  • Who are you waiting on?
  • If you got that tomorrow, what’s next?
  • What assumptions are we making?

Sometimes they already think they know the answer. They ask anyway.

Not because they doubt themselves, but because they know the people closest to the work often reveal dependencies no one else has considered.

Those conversations uncover hidden assumptions long before they become production problems.

They Optimize Flow

Most engineers naturally focus on the work in front of them. Chefs naturally focus on how work moves through the system.

They think about sequencing, dependencies, timing, and opportunities for parallel work.

Sometimes the most valuable thing they do all day isn’t writing code. It’s recognizing that a small infrastructure change this morning allows three other engineers to make progress this afternoon, or noticing that multiple teams are all waiting on the same missing piece.

The Chef isn’t trying to maximize their own output. They’re trying to maximize the team’s ability to keep moving.

They’re Not a Job Title

It’s easy to mistake a Chef for an engineering manager, project manager, technical lead, or architect.

Often they are, but sometimes they aren’t.

I’ve known Chefs who were senior engineers, consultants, architects, and individual contributors. Some were exceptional communicators. Others were quiet. Some probably wouldn’t have wanted to manage people at all.

The common thread wasn’t authority. It was orchestration.

A project manager might naturally ask, “When will this be done?”

A Chef is more likely to ask, “What has to be true before this can be done?”

One question tracks progress. The other uncovers dependencies.

Neither is better. They’re simply solving different problems.

The Invisible Ingredient

When you enjoy a great meal, you rarely think about everything that had to happen behind the scenes to make it possible.

You notice the finished product, not the coordination that made it possible.

Great engineering teams work much the same way.

Most people notice the feature, the deployment, or the difficult technical problem that was solved. They rarely notice the engineer quietly making sure everyone had what they needed before they needed it.

The one asking the question that revealed the dependency everyone else had overlooked. The one helping the entire team move together.

That’s the Chef.

In the final article of this series, we’ll bring these archetypes together and explore something I’ve become increasingly convinced of while writing them:

Great engineering organizations aren’t built by hiring one type of engineer. They’re built by understanding how very different kinds of engineers make one another better.