Separate driver evidence from setup requests

Generated from content/lms/coaching-science/06-communicate-inside-the-performance-team/03-share-coaching-findings-with-engineers.md; edit the source file, not this page.

Source path: content/lms/coaching-science/06-communicate-inside-the-performance-team/03-share-coaching-findings-with-engineers.md

Course: Coach drivers with evidence, not instinct

Module: Communicate inside the performance team

Estimated duration: 55 minutes

Skill goal

You are learning to hand coaching findings to engineers in a way that improves the whole performance system without bending the setup process toward your first theory. The skill is not silence. The skill is disciplined communication. You still speak up. You still protect the driver. You still bring useful trackside evidence to the people who can change the car. But you do it without turning a driver-side observation into a premature setup demand.

The working rule is simple: share evidence before interpretation, and interpretation before requests. A clean coaching handoff lets the engineer inspect the same problem from an engineering viewpoint. A contaminated handoff tells the engineer what the conclusion should be before the evidence has been sorted.

That difference matters because driver performance is not one thing. Your lap can change from session to session even when your underlying skill has not changed. State of mind, pressure, awareness, preparation, sensory input, technique, and the car can all change the result. If you treat every poor entry, every missed apex, or every complaint after a difficult session as a setup defect, you make the team chase the wrong cause. If you hide useful driver evidence because you are afraid to interfere, you leave the engineer blind. The middle path is to make your observation precise, scoped, and labeled.

This lesson teaches that middle path.

Principle: protect the boundary between coaching evidence and setup diagnosis

A coach sees things the data may not explain by itself: how the driver prepared, how tense the driver sounded, whether the mistake repeated only under pressure, whether the driver changed the input when asked, and whether a better cue improved the corner. An engineer sees things the coach may not see: the car state, setup history, mechanical limits, sensor traces, and whether the symptom matches a known vehicle pattern. The team needs both perspectives. It does not need either person pretending to be the other.

The key boundary is this: coaching evidence describes what the driver did, felt, perceived, and changed. Setup diagnosis explains why the car behaved that way in mechanical terms. You can give the engineer very strong driver evidence without prescribing the spring, bar, damper, alignment, aero, tire pressure, or diff change. You can also say when a driver-side intervention did not solve the problem, which is often the most useful thing you can contribute.

A contaminated handoff usually has one of three forms. The first is the hidden setup command: the coach says the driver needs a setup change when the only evidence is that the driver struggled. The second is the emotional translation error: the driver is frustrated, pressured, or disappointed, and the coach turns that state into a car complaint. The third is the overcompressed report: several different events get collapsed into one vague conclusion, so the engineer cannot tell what happened, where it happened, or whether it repeated.

A clean handoff has four layers. Layer one is the event: where and when the thing happened. Layer two is the evidence: what you saw, heard, felt from the right seat if applicable, or reviewed on video or data. Layer three is the coaching interpretation: the driver-side pattern you think may be involved. Layer four is the setup question, if there is one: what you want the engineer to inspect. You do not skip from layer one to layer four unless there is an immediate safety or mechanical concern.

The mechanism: why contamination happens so easily

Race driving rewards clear causes, but trackside work rarely gives you clean causes at first glance. A driver may say the car will not rotate, but the useful question is not whether that sentence is true or false. The useful question is what evidence supports it and what else could create the same sensation.

A driver who turns in too quickly can create a corner-entry symptom that sounds like a car problem. A driver who carries pressure from team owners, sponsors, friends, family, or personal expectations can drive tighter, force inputs, and then report that the car has changed. A driver whose awareness has improved may notice more imperfections and temporarily believe performance is getting worse. A driver who expects perfection may focus on the outcome instead of the process and misread a normal performance valley as a setup failure.

This is why the handoff has to be disciplined. Bentley repeatedly ties improvement to understanding what causes performance, increasing awareness, and using that awareness through a strategy. Information by itself does not make the driver better. Information becomes useful when it is turned into a good practice, coaching, or communication strategy. In this lesson, your communication strategy is to protect the quality of the input before anyone chooses an output.

The most dangerous version of contamination is the search for the quick fix. Racing culture can pull people toward the magic part, the secret adjustment, or the one setup change that explains everything. That temptation is understandable, especially after a bad session. But consistent winners are described in the corpus as organized, controlled, disciplined, prepared, and focused on refining basics. Your coaching communication should reflect that same discipline. You do not help the engineer by arriving with panic and a conclusion. You help by arriving with a clean problem statement.

The clean handoff sequence

Use this sequence when you need to share a coaching finding with engineering.

1. Name the exact performance event. Start with the part of the lap, the phase of the corner, or the session condition. Do not begin with a global claim about the car. A useful event statement sounds like this in structure: on the second half of corner entry, after the initial brake release, the driver added steering quickly and then had to wait before returning to throttle. The exact words will change by track, but the point is location and timing first.

2. Describe the driver-side evidence. This can include what the driver reported, what you observed, what video showed, what the data review should inspect, or what changed after a coaching cue. Keep the evidence in the language of actions and sensations. The driver tightened hands on entry. The steering trace looked faster than the previous good lap. The driver reported waiting for the car before throttle. The driver relaxed and the next two entries were cleaner. This is coaching evidence.

3. State repeatability. One lap is a clue. A repeated pattern is a finding. Say whether it happened once, across a run, only on cold tires, only in traffic, only after a mistake, or only when the driver was pushing for a lap time. Repeatability keeps the engineer from wasting time on a single unrepresentative moment.

4. State the driver-side intervention already tried. This is the part many coaches skip. If you asked the driver to slow the steering input, change the visual target, breathe before brake release, or focus on execution rather than outcome, say what happened. If the symptom disappeared, the setup request probably becomes less urgent. If the symptom stayed even with cleaner driver input, the engineer has stronger reason to inspect the car side.

5. Label confidence. Use plain confidence language. You might say you have a strong repeatable pattern, a possible driver-side cause, or a weak one-lap clue. Do not pretend your confidence is higher than it is. Engineers can work with uncertainty when you label it. They have a harder time working with certainty that was never earned.

6. Ask for inspection rather than prescribing the fix. The best default close is to ask the engineer to look at a defined slice of evidence, not to perform a named change. You are not withholding your thinking. You are keeping the setup process clean enough that the engineer can do engineering work.

The four buckets you should keep separate

Bucket one is observation. Observation is what happened before your explanation touched it. The driver turned in earlier. The driver hesitated before throttle. The driver reported that the car felt lazy on direction change. The lap time fell off after the driver started forcing the issue. Observation is the raw material of the handoff.

Bucket two is driver pattern. This is your coaching interpretation. You may think the driver is overdriving, reacting to pressure, adding effort, taking on too many strategies at once, or relying on poor sensory input. You may think the driver has become more aware and is now detecting flaws that used to pass unnoticed. These interpretations belong in the handoff when they are relevant, but they must be labeled as coaching interpretation.

Bucket three is performance effect. This is what the issue costs or changes. The driver waits before throttle. The car placement changes. The lap becomes less consistent. The driver loses confidence in the next corner. The important move is to describe the effect without pretending it proves the cause.

Bucket four is setup question. This is not a command. It is a request for engineering attention to a defined pattern. The engineer may find a car-side cause, may rule it out, or may ask you for more driver-side testing. All three outcomes are useful when the handoff was clean.

Sub-skill: capture sensory input before it becomes a story

The corpus emphasizes sensory information: visual, kinesthetic, and auditory input. In coaching communication, the same rule applies. The first version of a post-session story is often already contaminated by frustration, hope, or embarrassment. If you wait too long, the driver may remember the meaning of the event more clearly than the event itself.

Ask for sensory details early, before the story hardens. Where did it start? What did the driver feel first? Was the problem at initial turn, midcorner, throttle application, or exit? Did the driver hear tire noise earlier or later than usual? Did the driver feel tense, rushed, or late? Did the visual target narrow? You are not interrogating the driver. You are collecting input quality.

Better sensory input improves the whole chain. It gives you better coaching. It gives the engineer a better inspection target. It also teaches the driver to notice performance causes instead of only judging outcomes. This matters especially for intermediate drivers because your awareness may improve faster than your execution. You may start noticing more errors and assume you are worse. A coach who understands that pattern can keep the debrief from becoming a setup complaint.

Sub-skill: use driver language, but do not trap the engineer in it

Bentley notes that topics like vehicle dynamics and chassis setup might be explained differently by an engineer, and that his goal as a driver coach is to use language a driver can understand and use. That distinction is exactly the point of this lesson. Driver language is valuable because it preserves the lived experience of the lap. Engineering language is valuable because it connects symptoms to the car. The mistake is to mash them together too early.

If the driver says the car will not do what they ask, your first job is not to translate that into a setup change. Your first job is to locate the sensation in the lap and connect it to observable behavior. Did the driver ask too much too quickly? Did the issue change when the driver relaxed? Did it appear only when the driver chased the result? Did the driver make the same report after a cleaner lap? Once those questions are answered, the engineer can decide whether the car-side language fits.

You can make the engineer's work easier by translating driver emotion into structured driver evidence. That is different from translating driver emotion into a mechanical conclusion.

Sub-skill: filter pressure before it reaches the setup notebook

Pressure is part of the job. The corpus explicitly treats pressure from team owners, sponsors, friends, family, and the competitive environment as something the driver must learn to handle. That pressure can enter the communication loop. The driver wants an answer. The team wants speed. The clock is moving. The temptation is to show decisiveness by naming a fix.

But relaxed, focused, assertive execution is different from forced effort. The same is true in communication. You can be assertive without being aggressive. Assertive means you bring the finding promptly, clearly, and with useful evidence. Aggressive means you push a conclusion beyond the evidence because the room is tense.

Before you speak to engineering after a poor session, ask yourself three pressure checks. Am I trying to protect the driver from embarrassment by blaming the car? Am I trying to sound useful by naming a setup change? Am I letting the last lap, the stopwatch, or someone else's expectation shrink my view of the evidence? If yes, slow down. Return to the event, the evidence, the repeatability, and the driver-side intervention.

Sub-skill: keep improvement process separate from immediate outcome

A clean handoff protects learning. Bentley's process emphasis matters here: you improve by being aware of what and how you are doing, not by expecting perfection every session. If the driver runs a worse lap while testing a cleaner input, that does not automatically mean the coaching finding failed. It may mean the driver is in the awkward part of learning. It may also mean the cue was wrong. The point is that the conclusion needs evidence.

Do not let lap time be the only language in the debrief. Lap time matters, but it can hide causes. A driver can go slightly faster while reinforcing a poor pattern, or go slightly slower while building a better one. Your report to engineering should say what changed in execution, not just what changed on the clock. That keeps setup work from being driven by noise.

Sub-skill: throttle the number of findings

The corpus warns against taking on every strategy at once. That applies to team communication too. If you bring the engineer ten coaching findings with mixed confidence after every session, you have not created clarity. You have created another overload.

Choose the highest-value finding, or at most the two findings that are most repeated and most connected to the car-side question. If a finding is real but not urgent, record it for the next review. This is how you stay in scope without hiding information. The engineer needs the important signal, not every thought that crossed your mind.

Sub-skill: make a record the team can revisit

Trackside memory is unreliable, especially under pressure. The source corpus includes communications, data, and records as part of the racing craft, and Bentley's broader coaching approach keeps returning to awareness, practice, preparation, and repeated use. Your handoff should leave a small record: what was observed, what was tried, what changed, and what remains open.

This record does not need to be a novel. In fact, a short structured note is better. The structure can be: session, location, evidence, driver-side test, result, engineering question. If the same symptom appears later, the team can compare instead of starting over. If the setup changes, the team can see whether the change addressed a repeated pattern or a vague complaint.

What good sounds like

A clean coaching-to-engineering handoff sounds calm, specific, and incomplete in the right way. Incomplete does not mean vague. It means you have not pretended to know the part of the problem that belongs to engineering.

Good: after two laps of pushing, the driver started adding steering faster at initial turn-in for this corner. We asked for a slower input without giving away entry speed. The next two laps were cleaner but the driver still reported waiting before throttle. Could you look at that segment and see whether the car-side traces match what the driver is feeling?

Weak: the car will not turn and we need to change it.

Good: the driver reported the symptom only after the session got tense and only on laps where they were chasing time. When we reset the focus to execution, the complaint reduced. I think we should hold the setup conclusion for now and keep watching it.

Weak: the car is bad under pressure.

Good: we have a repeatable driver report and a repeatable video pattern, and the driver-side cue did not remove it. I do not want to prescribe the fix, but it is worth an engineering look before the next run.

Weak: I coached it and it is still wrong, so it must be setup.

Calibration cues: how you know your handoffs are improving

You know the skill is improving when engineers ask sharper follow-up questions because your report gave them a clear target. Instead of arguing about whether the car is bad, the conversation moves toward where the pattern appears, how often it appears, what changed when the driver tried a different cue, and what evidence should be compared.

You know it is improving when the driver stays more process-focused after hard sessions. The debrief becomes less about defending the lap and more about understanding performance causes. That does not make the driver passive. It makes the driver more useful to the team.

You know it is improving when setup discussions become less global. The team stops saying the car is terrible as a first move and starts saying that a specific symptom repeated under specific conditions after a specific driver-side test. That is a higher-quality engineering input.

You know it is improving when your own notes get shorter and stronger. Early notes may be long because you are thinking through the process. Better notes often become more compact: event, evidence, intervention, result, question. Compact is not the same as thin. Compact means the important distinctions survived.

You know it is improving when you can say why a session was good or bad. The corpus is clear that good drivers should know why they won and why they lost. In this lesson, that means you should know whether you are handing engineering a car-side question, a driver-side pattern, a pressure-state issue, or an unresolved blend.

Common failure modes and recovery

Failure mode one is the setup leap. You see a driver struggle and jump straight to a mechanical request. The cost is that the engineer begins from your conclusion instead of from the evidence. Recovery: restate the handoff using the four layers. Event first, evidence second, coaching interpretation third, engineering question fourth.

Failure mode two is the confidence bluff. You have one lap of evidence, but you speak as if it is a trend. The cost is wasted setup time and a team that learns not to trust coaching input. Recovery: label it as a one-lap clue and ask what evidence would make it worth action.

Failure mode three is the emotional escort. The driver is upset and you carry the emotion into the engineering conversation. The cost is that pressure becomes part of the setup process. Recovery: take a short reset, focus on controllable execution, and translate the driver's report into observable evidence.

Failure mode four is the overloaded handoff. You bring too many findings after one session. The cost is loss of priority. Recovery: choose the one repeated pattern with the strongest performance effect and record the rest for later review.

Failure mode five is the untested coaching theory. You believe a driver input is the cause, but you never test it before escalating. The cost is that the engineer cannot tell whether the driver-side path has been explored. Recovery: run one simple driver-side intervention if time and safety allow, then report the result.

Failure mode six is false neutrality. You avoid saying anything interpretive because you do not want to contaminate the setup process. The cost is that the engineer misses useful coaching context. Recovery: give the interpretation, but label it. The problem is not interpretation. The problem is unlabeled interpretation pretending to be fact.

How this connects to the rest of the module

This lesson sits inside performance-team communication. It does not replace the lessons on mapping people who affect performance, protecting the driver's preparation window, or using team review like an athletic program. Those lessons answer who matters, when to communicate, and how the team reviews over time. This lesson answers what to say when a coaching finding enters the setup conversation.

The practical standard is this: after your handoff, the engineer should understand the driver-side evidence better than before, while still being free to reach an engineering conclusion. The driver should feel heard without being taught that every discomfort is a setup fault. You should leave a record that the team can revisit. That is how coaching adds signal without contaminating setup work.

Worked example: corner-entry steering feedback without a setup prescription

The corpus gives a useful driver-side example in the cornering discussion: you can slow steering inputs without slowing entry, midcorner, or exit speed. Use that idea as a communication test.

Suppose you watch a driver enter a corner and the car appears late to take a set. The driver comes in and says the car will not turn. The contaminated version of the handoff is to tell the engineer the front end needs help. That may eventually be true, but you have skipped the coaching evidence.

The clean version starts with the event. On corner entry, the driver added steering quickly and then had to wait before returning to throttle. Then you add the sensory and coaching evidence. The driver felt the car hesitate. Video or data should be checked around initial steering and throttle return. You asked the driver to slow the steering input while preserving speed. If the next laps got cleaner, you report that result. If the driver still had to wait even with a calmer input, you report that too.

Notice the discipline. You did not hide the complaint. You did not protect the car from criticism. You simply made the driver-side test part of the handoff. The engineer now has a better question: does the car-side evidence match a real setup limitation, or was the primary change caused by input timing and effort?

This is the kind of example that keeps coaching useful. It respects the engineer's domain while giving engineering a sharper target than the driver's first emotional sentence.

Worked example: the magic-spring debrief after a frustrating session

Now take the situation the corpus warns about: the team is looking for the quick and easy way to win, the magic part, or the secret adjustment. Your driver has a poor session. The lap time is off. The driver is tense and says the car is impossible. The owner wants to know what is wrong. This is exactly when contamination is likely.

Your first job is to keep pressure out of the evidence. You do not dismiss the driver. You also do not convert frustration into setup diagnosis. Start by separating state, execution, and symptom. The driver was pushing for a result. The driver reported the issue after the run became tense. The observable mistake appeared on the laps where the driver forced the entry. When the focus was reset to execution, the issue reduced or did not reduce. Those two outcomes lead to different handoffs.

If the issue reduces when the driver relaxes and returns to process, the engineering report should say that the symptom is not ready for setup action. Keep watching it, but do not spend the session chasing a conclusion that pressure may have created. If the issue remains after a calmer driver-side repeat, then the report gets stronger: the symptom persisted after the driver-side reset, so engineering should inspect the relevant traces or setup area.

The point is not that setup is never the answer. The point is that pressure is not evidence. A disciplined handoff protects the team from using the car as a container for every bad feeling after a hard run.

Common mistakes: what bad looks like and what good looks like

The hidden setup command is the most common mistake. Bad looks like a coaching report that begins with the desired mechanical change. Good looks like a report that begins with the event and evidence, then asks engineering to inspect.

The outcome-only report is another common mistake. Bad looks like saying the driver was slow and the car felt wrong. Good looks like explaining where the speed was lost, what the driver did, what the driver felt, and whether a driver-side cue changed it.

The untagged interpretation mistake happens when you mix observation and theory. Bad looks like presenting your coaching theory as fact. Good looks like saying the observation first, then labeling your view as a coaching interpretation.

The one-lap verdict mistake happens when a single moment becomes a setup conclusion. Bad looks like treating one bad entry as a car problem. Good looks like calling it a clue and looking for repeatability.

The emotional relay mistake happens when you carry the driver's frustration directly to engineering. Bad looks like a hot debrief that turns pressure into a setup demand. Good looks like a short reset followed by calm, observable detail.

The overload mistake happens when you report every possible finding. Bad looks like giving engineering a cloud of unrelated notes. Good looks like choosing the one repeated finding with the largest performance effect and recording the rest for review.

The false-neutrality mistake happens when you avoid interpretation altogether. Bad looks like giving only raw driver complaints and forcing the engineer to guess what you saw. Good looks like giving the interpretation, but labeling it so it does not masquerade as a setup fact.

Drill: three-column coaching handoff

Run this drill at your next event for three sessions. It takes about eight minutes after each session and it has one success criterion: by the end, another team member should be able to tell which parts of your report are evidence, which parts are coaching interpretation, and which part is the engineering question.

After session one, choose one performance issue only. Write three columns: evidence, coaching interpretation, engineering question. In the evidence column, record the event location, what the driver reported, what you observed, and whether it repeated. In the coaching interpretation column, write the driver-side pattern you suspect and your confidence level. In the engineering question column, write what you want inspected without naming a fix unless engineering has specifically asked for your setup suggestion.

Before session two, choose one driver-side intervention related to the issue. Keep it small. It might be a calmer steering input, a narrower focus on execution, a breathing reset before a braking zone, or a visual cue. After session two, update the same three columns with what changed. Do not change the setup question until you have recorded whether the driver-side intervention affected the symptom.

After session three, make the handoff verbally in less than sixty seconds. Include the event, the evidence, the intervention, the result, and the engineering question. The drill is successful when you can do that without adding a hidden setup command, without overstating confidence, and without burying the engineer in secondary findings.

This drill trains the habit the corpus keeps circling: awareness becomes useful only when it becomes a strategy. Here, the strategy is structured communication.

When this principle bends but does not disappear

There are cases where you should shorten the sequence. If there is an immediate safety or mechanical concern, report it plainly and quickly. Do not hold back a serious concern because you are trying to preserve a perfect communication model. The boundary still matters, but urgency changes the amount of explanation.

There are also cases where the engineer directly asks for your setup view. If you have the experience and the relationship supports it, answer, but keep the labels. Say what you observed, what driver-side work was tried, and what you think may be worth considering. The label protects the engineer's process and protects your credibility.

A third case is long-term review. In a review meeting, you may connect several sessions and patterns in a broader way. That is different from a live setup handoff between runs. In long-term review, your job is still to separate evidence from interpretation, but you can take more time to discuss preparation, awareness, pressure patterns, practice quality, and whether the team is refining basics rather than chasing quick fixes.

The principle does not mean the coach never talks about the car. It means the coach earns the right to influence setup work by preserving evidence quality.

Author Review

No quiz questions are attached to this lesson.

Sources

#	Document	Chunk	Pages	Score	Collection
1	Ultimate Speed Secrets - Ross Bentley	4400491c-451f-86fc-590c-1fa83983aef9	12	1	uio_books_raw_v1
2	Inner Speed Secrets - Ross Bentley	6922c3e5-4f39-f49c-4760-bf5e233bc987	20	1	uio_books_raw_v1
3	Inner Speed Secrets - Ross Bentley	1f89d950-4532-a2f9-3f06-33a6a39f92d6	24	1	uio_books_raw_v1
4	Inner Speed Secrets - Ross Bentley	faf47214-2619-0395-43b8-f1f6523e5a80	32	1	uio_books_raw_v1
5	Inner Speed Secrets - Ross Bentley	7a1e5fa9-cd1f-1a05-3258-5215475b490e	128	1	uio_books_raw_v1
6	Inner Speed Secrets - Ross Bentley	a4147ea3-257f-67b9-5fef-f56d4cfb427f	134	1	uio_books_raw_v1
7	Inner Speed Secrets - Ross Bentley	f74de7b7-deb7-8b53-8851-548f3670c623	178	1	uio_books_raw_v1
8	Inner Speed Secrets - Ross Bentley	42cd9797-25c1-9bbb-d1f4-7aa50b893094	189	1	uio_books_raw_v1
9	Inner Speed Secrets - Ross Bentley	84688c44-9714-5f70-19a9-b7503c7b7482	186	1	uio_books_raw_v1
10	Inner Speed Secrets - Ross Bentley	cd07b52b-0521-1105-68b8-f38b8f666672	164	1	uio_books_raw_v1
11	Inner Speed Secrets - Ross Bentley	d228ad67-02d0-59cc-e79a-36eaa2832e98	31	1	uio_books_raw_v1
12	Ultimate Speed Secrets - Ross Bentley	4c99d7b1-8b24-7dbd-b21f-93757abf3896	608	1	uio_books_raw_v1
13	Speed Secrets Professional Race Driving Techniques Ross Bentley	8b546b81-602a-e872-facb-d67640333134	6	1	uio_books_raw_v1
14	Ultimate Speed Secrets - Ross Bentley	47f6de8d-9d56-5b6d-547a-f1e7bb92faaf	152	1	uio_books_raw_v1
15	Ultimate Speed Secrets - Ross Bentley	0a7b123f-e40b-ee9d-96a9-122dd397d29d	4	1	uio_books_raw_v1
16	Speed Secrets Professional Race Driving Techniques Ross Bentley	b1cb6788-fbdc-5863-f6e8-318d4d5edf83	3	1	uio_books_raw_v1