Blog

From Line Cook to Chef: Lessons for Presales Engineering

By Jay

Aug 28, 2025 | 11 minutes read
Share this:

Tags: presales-engineering, leadership, organizational-behavior, career-advice

Chef in kitchen flanked by line cooks

A line cook can create perfect menu items by following recipes. A chef can create new dishes on the fly, improvise when needed, and handle unexpected situations. The chef also usually gets to wear a cool hat.

I recently noticed a pattern among some presales engineers (SEs) that reminded me of my early days in food service. There are SEs who excel at delivering polished, rehearsed demos that they can execute flawlessly as long as the script doesn’t change and nothing unexpected happens. These are very much like line cooks who follow recipes to the letter.

On the other hand, there are SEs who have a broader range of experience, who can handle unexpected questions, technical deep-dives, and complex scenarios because they’ve worked in various roles and have a deeper understanding of technology and industry. These SEs are more like chefs who can create new dishes on the fly and adapt to changing situations.

The difference between these two types of SEs can have significant implications for customer trust, deal success, and internal team dynamics. In this post, I’ll explore this analogy further and discuss why it matters for presales engineering. An important note before we dive in; both types of SEs can be very skilled and valuable. There is a place for SE’s trained in the “Recipe Card” approach, especially in transactional sales. The key is recognizing when that approach is sufficient and when a more versatile skill set is required.

In the culinary world, a recipe card provides a step-by-step guide to creating a dish. It outlines the ingredients, quantities, and procedures needed to replicate the dish consistently. A line cook relies on these recipes to ensure that every plate leaving the kitchen meets the restaurant’s standards. In the world of presales engineering, a “recipe card” can be likened to a well-rehearsed demo script or a set of standard responses to common customer questions. Just like sales has frameworks such as BANT or MEDDIC, SEs have other approaches based on books such as “Demo to Win” or “Great Demo” that guide their approach to customer interactions.

These scripts and frameworks are invaluable tools for SEs, especially in high-volume, transactional sales environments. They provide a structure that helps SEs deliver consistent messages and demonstrations, ensuring that key product features and benefits are highlighted effectively. This is the same way franchise restaurants use standardized recipes to ensure consistency across every dish served.

Here’s how you can spot the difference in the field.

A customer asks: “How does your product work with [other product / environment / tool]?”

Line-cook SE: Waves their hand, says “I think it should work,” and punts the question to engineering or support. When the customer follows up later, they still don’t have an answer and they will “follow up” with product or engineering again. And again. And again. Until the customer loses patience and walks away.

Chef SE: Spins up a test environment, replicates the customer’s setup, and finds out. They might pull in other resources, but as partners, not proxies. By the next meeting, they’re back with logs, screenshots, and an answer grounded in reality. If they don’t know, they say so, but critically they are also able to say they will find out and actually do it.

Another example:

A customer says: “We need this to work in our air-gapped environment.”

Line cook SE: “I think it should work fine. Let me have engineering confirm that.” (Note that they may not even know what “air-gapped” means in this context.)

Chef SE: “What exactly do you mean by air-gapped? Can you share your network architecture? Let me set up a similar environment and test it out. I’ll get back to you with details.” (Understands that “air-gapped” can mean different things in different contexts.)

One burns credibility. The other builds it.

Where Recipe Cards Work - and Where They Don’t

The recipe card approach works beautifully in short-cycle, transactional deals with non-technical buyers. It’s fast-casual: every order is the same dish, executed consistently. Space for improvisation is minimal, and the customer’s expectations are aligned with what’s on the menu. Very few diners walk into a McDonald’s and ask for a custom meal beyond “no pickles.”

But complex enterprise sales flip the script. When customers need deep integration or technical buyers push past the “happy path,” the demo is not enough. This is where things can go from good to disastrous quickly, depending on the SE’s ability to realize they are out of their depth and ask for help. When they don’t realize it, they can put themselves into a situation where things go embarrassingly wrong and the customer loses trust.

It’s important to note that being a line cook or a chef isn’t about skill or intelligence. Many line cooks are highly skilled and intelligent individuals. The distinction lies in the breadth and depth of their experience along with their ambition to grow. A line cook may excel at executing specific recipes but may struggle when asked to improvise or handle unexpected situations. This is not an issue, because their role does not require it.

Likewise, an SE who specializes in scripted demos may be very effective in certain sales scenarios but may find it challenging when faced with complex technical questions or scenarios that fall outside the script. This is not a reflection of their intelligence or capability, but rather a limitation in their experience and exposure to diverse technical environments.

Some line cooks spend their whole careers in that role. Many become excellent. But there is a distinct subset who fall into the trap of assuming their skills are sufficient for all culinary situations. This sets the line cook up for failure, with their confidence outpacing their actual ability to handle unexpected situations.

Likewise, some SEs spend their whole careers in presales. Many become excellent. However, just like with the line cooks in the example above, some SEs fall into the trap of assuming their skills are sufficient for all sales situations. This sets the SE up for failure, causing them to overpromise and underdeliver when faced with scenarios outside their scripted demos. Worse, they almost never realize they are out of their depth until it’s too late and they have already damaged customer trust.

An SE who has worked in various roles—such as development, support, consulting, or product management—brings a wealth of experience that can be invaluable in presales. They understand the technical nuances of the product, the challenges customers face, and the internal workings of the company. Nothing develops rapport with engineers and product teams like having been the person who knows what it’s like to be paged at 2 AM to fix a production issue. Conversely, nothing frustrates those same teams more than an SE who has never set foot in a data center or written a line of code confidently explaining how their product will fix everything, despite never having done it themselves.

Asking a line cook to suddenly become a chef without the necessary experience and training is unrealistic. Similarly, expecting an SE who has only worked in scripted demo environments to handle complex technical scenarios without additional training and experience is equally unreasonable.

This problem is compounded when these line cooks or SEs move into leadership roles. In these positions, they set the tone for the team based on their own experiences and biases. The approach that worked for them becomes the default approach for the entire team, and is frequently enforced as the only acceptable way to operate.

What tends to happen is that the team becomes a collection of line cooks, each following their own recipe, but no one
is capable of creating new dishes or handling unexpected situations. If there are any Chefs on the team, they are often undervalued or pushed out because their approach doesn’t align with the established norms.

Metrics and incentives often reinforce this behavior. If success is measured by the number of demos delivered or deals closed, there is little motivation to develop the deeper skills needed to handle complex scenarios. The focus of the team becomes delivering polished demos rather than truly understanding the technology and the customer’s needs.

When things go wrong, the line cook SE often resorts to excuses and blame. They may point fingers at the product, engineering, or support teams, claiming that the issues are beyond their control. This is a natural defense mechanism, but it does little to resolve the underlying issues.

IF the SE leader is a line cook, they may double down on the same approach rather than adapting. Instead of learning from mistakes, they blame external factors like product limitations or lack of support from other teams. Or, a more common scenario, they start to focus on the tools and resources they don’t have, rather than the skills they lack. How many of these excuses have you heard?

  • “We just need more tools.”
  • “We should change the metrics.”
  • “Support / engineering / product needs to fix things for us.”

This is analogous to a line cook blaming the quality of the ingredients or the kitchen equipment when a dish doesn’t turn out as expected while ignoring their own lack of culinary skill or understanding of the recipe. No matter what the leaders say, the team continues to struggle with the same issues because the root cause is never addressed.

When the customer follows up in the next meeting and the “line cook SE” still doesn’t have an answer, the excuses start, and blame starts flying: AE blames product. Product blames SE. SE blames support. The customer sees through it immediately — and the company’s credibility takes a hit that’s hard to recover from. Depending on the organization, this may all happen without the SE ever realizing they were the root cause, and with the SE leader doubling down on the same approach.

This isn’t just about individual performance. When line cook SEs make promises they can’t keep, entire deals unravel. Engineering teams burn out cleaning up unrealistic commitments. Company credibility craters.

Those internal teams (product, engineering, support) start to resent presales. They’re tired of promises made on their behalf, of being thrown under the bus, of the effort required to clean up unrealistic commitments. It’s like a kitchen staff forced to make impossible dishes because the front-of-house promised the moon. Everyone ends up burned out, and no one trusts the person who put them in that position.

I’ve been the line cook.

Early in my career, I was a consultant for a large tech vendor. On paper, I was “the expert” on our RDBMS and supporting tools. In reality, I knew only what I could read in documentation and piece together from training materials. I was sent out to customer sites as the authority, armed with polished presentations and standard demos.

It became clear quickly to me that I was following recipes I didn’t truly understand. Customers would ask questions that went beyond the script, and I’d have to bluff my way through or promise to “get back to them.” Internally, I could see the frustration from engineering and support teams who had to help me clean up after my unrealistic commitments.

The turning point wasn’t a single moment but a gradual realization: I could either stay comfortable with my script or actually become the expert I was supposed to be. I started setting up my own environments, volunteering for projects outside my comfort zone, and doing a lot more listening than talking. I took detailed notes and asked questions that probably seemed basic to my more experienced colleagues. I spent more time talking with engineers, product managers, and even customers than I did my own peers, most of whom were also line cooks and were both proud of it and defensive about needing to grow.

The transformation from line cook to chef isn’t about memorizing more recipes, instead it’s about understanding the fundamentals well enough to improvise when the situation demands it. It’s about humility, curiosity, and a willingness to do the hard work of learning. It’s about recognizing that the customer’s trust is a privilege, not a given.

This dynamic isn’t unique to SEs, as my example above illustrates. Rather, it’s any tech role that combines customer interaction with technical representation. When I talk to others in the field, it always seems to come down to the same challenge. Do you “fake it until you make it” or do you put in the uncomfortable work of actually making it? One is easy and comfortable. The other is hard and uncomfortable.

Varied experience doesn’t just make you “well-rounded.” It gives you the curiosity, technical depth, and humility to create recipes when none exist. It helps you respect the customer’s trust and your team’s effort.

In restaurants and in presales, the best people don’t just follow recipes—they write them.

That’s the difference between demoing to win the meeting and engineering to win the customer.

Great SEs know which side they’re on. Great companies make sure they hire accordingly.