There is a story about Toto Wolff, the leader of the Mercedes Formula One team, that has stayed with me. I have seen it shared in different forms, and while I would be careful about treating every version of the story as a verified direct quote, the leadership principle behind it is well aligned with how Wolff has publicly talked about culture. The principle is simple, but not easy: when something goes wrong, do not start by blaming the person. Start by looking at the process.
That idea is powerful because Formula One is not exactly a forgiving environment. It is one of the most performance-driven industries in the world. Every detail is measured, every decision is scrutinised, and the difference between success and failure can be a fraction of a second. A slow pit stop, a misunderstood radio message, a wrong tyre call, a missed signal, or a tiny setup mistake can cost points, podiums, or championships. In a world like that, you might expect the culture to be brutal. You might expect the first question after every failure to be: “Who made the mistake?”
But the more useful leadership question is often different: “What did our process allow to happen?” That question changes the conversation completely. Blaming the person gives you a fast emotional answer. It creates the feeling that someone has been held accountable. It allows a team or an organisation to say, “We found the problem.” The uncomfortable truth is that the visible mistake is often not the full problem. The person may only be the point where a weakness in the system finally became visible.
That is why blame can be so seductive and so dangerous at the same time. It simplifies complex situations into a single name. It gives leaders a villain, or at least a responsible individual, and it provides a quick sense of closure. But closure is not the same as learning. If the process stays the same, the same failure can reappear with a different person, in a different region, in a different customer conversation, in a different quarter. The individual incident may be solved, but the organisation has not become stronger.
I find this especially relevant in Solutions Consulting, because the role sits in one of the most complex parts of a go-to-market organisation. Solutions Consultants operate between sales, product, customer needs, technical validation, security requirements, partner motions, competitive pressure, and internal enablement. They are translators, challengers, storytellers, technical advisors, value consultants, demo builders, risk detectors, and sometimes emergency responders. A good SC can make a complex customer problem feel simple. A great SC can help a customer make a better decision. But even great people struggle when the system around them is unclear, fragile, or overloaded.
A process failure in Solutions Consulting rarely introduces itself politely as a process failure. It usually shows up looking like a human mistake. Someone forgot to update the CRM. Someone used an outdated slide deck. Someone joined a customer call without enough context. Someone missed a follow-up. Someone ran a demo that did not connect to the customer’s real business problem. Someone accepted a demo request before the discovery was strong enough. Someone handed over an opportunity with only half the story. Someone failed to document a technical blocker until it had already become a deal blocker.
Most leaders recognise these moments. Many of us have also reacted to them in predictable ways. We remind, repeat, escalate, inspect, correct, and sometimes write a very carefully worded message that starts with “quick reminder” even though nothing about it feels quick anymore. “Please update Salesforce.” “Please use the latest template.” “Please complete the handover.” “Please capture the technical criteria.” “Please follow the process.” “Please do not forget to add the next steps.” None of these requests are unreasonable. The team should update the system. They should use the current deck. They should complete the handover. They should capture the customer’s requirements.
But if leaders have to send the same reminder every week, the reminder itself becomes evidence. It is evidence that the process is not working well enough. It depends too much on memory, goodwill, personal discipline, timing, and heroic effort. All of those things matter, but none of them should be the foundation of a scalable operating model. A process that only works when everyone remembers everything at exactly the right moment is not a strong process. It is a fragile process with polite language around it.
This is where the microwave comes in.
A microwave does not start when the door is open. There is no laminated sign on the front that says: “Dear user, please remember to close the door before heating your food.” There is no weekly reminder from the microwave leadership team. There is no compliance dashboard tracking open-door start attempts by department. There is no performance improvement plan for people who repeatedly forget to close the door. The machine simply does not allow the unsafe action.
That is good process design. It does not depend on memory. It does not depend on motivation. It does not depend on whether the user has had enough coffee. The process prevents the error before it becomes a problem. The same principle appears in many everyday situations. Some fuel nozzles are shaped so they do not easily fit the wrong tank. Many ATMs guide the sequence so forgetting your card becomes harder. Software forms can validate an email address before submission. Calendar tools can warn you when you try to schedule over an existing meeting. These are not motivational messages. They are examples of systems that either prevent mistakes or make them immediately visible.
In quality management, this idea is often described as mistake-proofing, or poka-yoke. The goal is to design a method, mechanism, or control that makes an error impossible or makes it obvious as soon as it occurs. That idea is usually discussed in manufacturing or operational excellence, but it is just as relevant in knowledge work. In fact, it may be even more important in knowledge work, because our mistakes are often less visible. A missing field in a CRM record does not make a loud noise. A vague discovery note does not flash red. A bad handover does not physically block the next stage. It simply creates friction later, usually for someone else.
That delayed impact is one of the reasons process problems are so hard to fix in sales and Solutions Consulting organisations. The person who experiences the pain is often not the person who created the gap. A weak discovery call might lead to a poor demo three days later. A vague handover might create confusion for customer success six weeks later. A missing security requirement might slow procurement near the end of the quarter. A poorly documented proof of value might make renewal conversations harder a year later. Because the consequence is separated from the action, the process needs to make quality visible earlier.
This is where leaders have to move beyond reminders and start designing better systems. The goal is not to remove human judgment. That would be impossible and undesirable. Solutions Consulting is not factory work, and the best SCs are not machines. They need to read the room, adapt the story, challenge assumptions, and use experience in moments where no checklist can fully describe what to do. But that does not mean everything should depend on individual improvisation. The best processes create enough structure to protect quality while leaving enough space for professional judgment.
I often think about this as the difference between a prison wall and a garden fence. A prison wall says: “Do not move.” It restricts behaviour so much that people stop thinking. A garden fence is different. It marks the space. It shows where the edges are. It protects what matters, but it does not prevent movement inside the area. That is what a good Solutions Consulting process should feel like. Clear enough to guide people, flexible enough to allow judgment, and strong enough to protect the customer experience.
Discovery is a good example. Most sales and pre-sales organisations say they want better discovery. That is easy to say and hard to operationalise. When discovery is weak, the common response is to tell people to ask better questions. Sometimes that is true. People may need coaching, examples, and practice. But the process questions are just as important. Where in the opportunity flow is discovery expected to happen? Is there a shared definition of what good discovery looks like? Do account executives and Solutions Consultants agree on what must be known before a tailored demo makes sense? Are business pains, technical requirements, decision criteria, stakeholders, risks, and next steps captured in a way that actually helps the team? Does the CRM support the workflow, or does it turn discovery into admin after the real work is already done?
Those questions matter because weak discovery is not always caused by weak people. Sometimes it is caused by unclear entry criteria, rushed demo requests, pressure to support every opportunity, missing qualification discipline, or a process that rewards activity more than learning. If a Solutions Consultant receives a demo request with only “customer wants to see the platform” as context, the problem is not just whether the SC is skilled enough to recover. The process has already allowed the conversation to move forward without enough clarity. A stronger process would make the missing context visible before the meeting is on the calendar.
The same applies to demos. A generic demo is easy to blame on the person delivering it. Maybe they did not prepare enough. Maybe they defaulted to a feature tour. Maybe they showed what they knew instead of what the customer needed. That can happen, and coaching still matters. But a leader should also ask whether the system helped that person create a relevant demo. Did the SC receive the business context early enough? Were success criteria captured before the demo? Did the account team agree on the narrative? Was there a simple way to reuse strong demo assets? Was the latest product positioning easy to find? Were competitive risks discussed in advance? Was there a mechanism to learn from demos that worked well?
A leader who only says “prepare better” is building a warning sign. A leader who improves the intake process, simplifies the demo library, clarifies discovery expectations, creates reusable narratives, and builds feedback loops is building a microwave door. The difference is not softness. The difference is leverage. One approach asks every individual to compensate for a weak system. The other improves the system so every individual has a better chance of doing excellent work.
Handovers are another classic example. In many organisations, handovers fail quietly. Sales to pre-sales. Pre-sales to customer success. Partner to direct team. Regional team to global account team. Initial discovery to proof of value. Proof of value to procurement. Procurement to implementation. Everyone agrees that handovers are important. Almost nobody enjoys doing them. And when they fail, the consequences often appear later. A customer has to repeat themselves. A technical blocker reappears. A success criterion is forgotten. A promise made in the sales cycle becomes a delivery headache. The customer feels the organisation is not aligned.
The usual response is another reminder to complete the handover template. The better response is to examine whether the handover process is actually designed for use. Is the template too long? Is it asking for information nobody reads? Is the information stored where the receiving team actually looks? Does the receiving team have the right to challenge missing context? Is there a review moment before the opportunity moves forward? Does the team learn when handovers are good or bad? If a handover template is completed only because the process requires it, but nobody uses it to make the next step better, it is not really a process. It is documentation theatre.
CRM hygiene is perhaps the most familiar battlefield of all. Poor CRM data is one of the most reliable sources of leadership frustration in sales organisations. It is also one of the areas where blame is least useful. Yes, CRM discipline matters. Yes, data quality affects forecasting, prioritisation, resource planning, compensation, customer experience, and leadership decisions. But if updating the CRM feels like writing a diary after the real work is done, leaders should not be surprised when quality drops.
The process question is not only “How do we make people update the CRM?” The better question is “How do we make the CRM useful at the moment of work?” Can we reduce duplicate entry? Can we make required fields meaningful rather than merely mandatory? Can we connect CRM updates to deal strategy instead of compliance? Can we create fields that help the SC prepare, not just fields that help management report? Can we use event-based tracking instead of asking people to manually label every activity afterwards? Can we make the next best action clearer from the information already captured? When a system gives value back to the person entering the data, the process improves. When the system only extracts data for someone else, adoption will always depend on enforcement.
This is also where leadership has to be honest about the difference between accountability and blame. A no-blame culture does not mean no standards. It does not mean every mistake is acceptable. It does not mean leaders avoid difficult conversations or pretend performance issues do not exist. In fact, a true learning culture requires high standards. The difference is that the first response to failure is curiosity before accusation. The leader still asks what happened. The leader still distinguishes between honest mistakes, lack of skill, unclear expectations, poor judgment, and repeated negligence. But the leader also accepts that most failures contain information about the system.
That distinction matters because “human error” is often where weak analysis stops. Saying “the person forgot” may be factually correct, but it is not very useful. Why was the task easy to forget? Was it disconnected from the flow of work? Was there no prompt at the right time? Was the information hard to find? Was the priority unclear? Were there competing incentives? Was the person overloaded? Had they been trained on the task, or had we assumed they would just know? A serious leader does not ask these questions to excuse poor performance. They ask them because the answers reveal where performance can actually improve.
One way of introducing accountability and visibility of missing steps is using checklists and checks for process steps in qualification, discovery or hand-over. A great source and ideas for a methodoligy based on checklists is “Read and Do” from Captain Joe.
The risk, of course, is going too far in the other direction. Some organisations hear “process” and immediately create bureaucracy. They build forms, gates, checklists, approval steps, dashboards, mandatory fields, and templates until the process becomes heavier than the work. That is not the answer either. A bad process with more steps is still a bad process. Sometimes it is worse because it creates the appearance of control while pushing real work into side channels.
Good process design requires restraint. It should remove friction where friction is wasteful and add friction where friction protects quality. That distinction is critical. Making a demo request harder can be bad if it simply creates admin. But making it impossible to request a strategic demo without basic discovery may be good friction. Adding another CRM field can be useless if nobody uses the information. But requiring a clear business outcome before a proof of value starts may protect the customer, the SC, and the deal. The question is not whether a process has fewer or more steps. The question is whether each step improves the work.
This is where leaders should involve the people closest to the work. Processes designed far away from reality often look elegant in a slide deck and fail in practice. The SCs who live inside the process know where it breaks. They know which fields are useful and which ones exist only for reporting theatre. They know which handover questions matter. They know which demo assets are current, which enablement materials are ignored, and which internal approvals slow down deals without improving quality. If leaders want microwave doors instead of warning signs, they need to design with the users of the process, not only for them.
A practical way to start is to look for repeated reminders. Every repeated reminder is a clue. If you keep reminding people to use the latest deck, maybe the latest deck is not easy enough to find. If you keep reminding people to update CRM fields, maybe the fields do not help them do their job. If you keep reminding teams to complete handovers, maybe the handover has no clear owner or no visible value. If you keep reminding new hires where to find information, maybe the onboarding path is not clear. If you keep reminding people to follow a process, maybe the process is either too hard, too hidden, or not trusted.
Another useful signal is the printed sign, whether literal or digital. The office kitchen sign that says “Please put your cups in the dishwasher” is funny because everyone has seen some version of it. But many business processes have their own digital equivalents. The Teams message with three exclamation marks. The weekly Slack reminder. The email that starts polite and becomes progressively less polite over time. The dashboard that measures non-compliance without fixing the cause. These signs are not useless, but they are rarely enough. At best, they create temporary attention. They do not create better design.
The more mature leadership move is to ask what would make the reminder unnecessary. Not because communication is bad, but because repeated communication should not be the only control. If the latest deck matters, make the old one harder to access and the new one easier to use. If CRM updates matter, place the update in the natural rhythm of deal progression. If discovery matters, make missing discovery visible before the demo is accepted. If handover quality matters, make the receiving team part of the validation. If onboarding consistency matters, create a path that does not depend on who happens to be available that week.
This is not always easy. Process work is rarely glamorous. It does not create the same visible excitement as a big customer win, a new product launch, or a successful event. It often involves small decisions, uncomfortable trade-offs, and patient iteration. It requires leaders to admit that the current way of working may be part of the problem. It requires teams to give honest feedback without turning every frustration into a complaint. It requires the organisation to distinguish between a useful standard and unnecessary control.
But the payoff is significant. Better processes create better customer experiences. They make internal collaboration smoother. They reduce avoidable rework. They help new team members ramp faster. They make performance more consistent without forcing everyone to behave identically. They give leaders more reliable data. They help talented people spend less time fighting the system and more time doing the work that creates value.
In Solutions Consulting, that value is not abstract. It shows up when a demo tells the customer’s story instead of the product’s menu. It shows up when a proof of value starts with clear success criteria instead of vague enthusiasm. It shows up when a customer does not have to repeat the same requirement to five different people. It shows up when an SC can prepare faster because the opportunity context is complete. It shows up when a new hire understands not only what to do, but why it matters. It shows up when a team can scale without losing quality.
The strongest teams are not the teams that never make mistakes. That is an unrealistic standard and, frankly, a dangerous one. Teams that pretend they do not make mistakes usually become teams that hide them. The strongest teams are the ones that learn faster when mistakes happen. They do not waste energy pretending the issue was only human error. They look at the environment, the incentives, the tools, the timing, the handovers, the expectations, and the feedback loops. They still coach the person, but they also improve the process.
“From success, you learn absolutely nothing. From failure and setbacks conclusions can be drawn. That goes for your private life as well as your career.”
Niki Lauda, F1 Driver and Enterpreneur
That is the leadership lesson I take from the Formula One story, from the microwave door, and from the many small process frustrations we see in business every day. High performance does not come from blaming faster. It comes from learning faster. And learning faster requires leaders to look beyond the person at the centre of the incident and examine the system around them.
The next time something goes wrong in a team, it is still fair to ask what happened. It is fair to ask which standard was missed. It is fair to ask whether someone needs coaching, support, or a clearer expectation. But it would be a mistake to stop there. Ask what the process allowed. Ask what the system made harder than necessary. Ask where the next person might fall into the same trap. Ask whether the organisation has built a warning sign where it really needs a microwave door.
Because if the only thing we do after a mistake is tell people to be more careful, we have not learned very much. We have simply added another reminder to a fragile process.
Leadership should aim higher than that.
Build fewer warning signs. Build more microwave doors.
