#119 - Welcome to the grey zone!

20 Aug 26

Engineers are trained to trust cause and effect. Press the button, get the response. Write the sub-routine, get the behaviour...reliably, every time (once it's been tested and debugged of course). People don't work that way, and that mismatch catches more Engineers out on the way into leadership than almost anything else.

Trial Brief

Engineers spend a career earning trust in predictability. Equipment behaves. Code, once debugged, behaves. Input X reliably produces output Y, and if it doesn't, there's a fault to trace and fix until it does again. Leadership takes that certainty away and replaces it with something far less comfortable: people.

Trial Execution

Every system I trained on and maintained had a logic to it. Faulty or not, it was consistent. The same input produced the same output, and if it didn't, that inconsistency was itself the fault, something to be found and corrected. That was the world I understood, and the world that made me good at the job.

Leading people broke that model almost immediately. The same approach that got a strong response from someone on Monday could land flat with the same person on Thursday, with nothing obviously different in how I'd approached it. Early on I treated that as a fault too as if I'd done something wrong, or they had, and the 'bug' just needed finding. It took a while to accept that there often wasn't a bug at all. People are not deterministic. They carry a night's poor sleep, a conversation from an hour earlier, a worry that has nothing to do with the task in front of them, and none of it shows up as an error code.

Trial Findings

Engineers are drawn to binary states because binary states are solvable. 'Yes or no', '1 or 0', 'pass or fail'. Human interaction runs almost entirely on something else...'possibly', 'maybe' or 'it depends'. That ambiguity is genuinely unsettling to a mind trained to eliminate it.

The mistake most technically-minded leaders make isn't a lack of care, it's applying the debugging mindset to people. There is a tendency towards creating an inconsistent response as a problem to be isolated and permanently fixed rather than treating it as a normal feature of dealing with someone who is, on any given day, ruled as much by emotion as by logic. Chase that kind of certainty with a person and you'll either exhaust yourself trying to find a 'fix' that doesn't exist, or you'll start to see the person themselves as the fault. Neither approach builds trust.

The leaders who get comfortable in this grey zone stop asking 'why isn't this working the way it did last time' and start asking 'what's different about today'. That's a small shift in language, but it's a real shift in mindset from treating variability as malfunction to treating it as information. It also means building in slack: checking in before diving into the task, reading the room rather than the script, and accepting that the same words delivered the same way will land differently depending on what someone is carrying that day. None of that is technical work. In fact it's the opposite of technical work, which is exactly why it feels so uncomfortable to Engineers who built their reputation on getting to a definite answer.

The Common Thread

Predictability is a property of machines, not people, and leadership only starts to work once that distinction is fully accepted rather than quietly resisted. The grey zone isn't a fault in the system. For an Engineer moving into leadership, learning to work inside it, without needing it to resolve into a 1 or a 0, is itself the job.

Trial Sign-off

One practical action

Think of someone whose response to you has varied recently, even though your approach hasn't changed. This week, before your next interaction with them, pause and ask yourself what might be different for them today. Rather than assuming the difference is something you did or said, adjust your approach and notice what changes.

One question for reflection

Where are you currently treating a person's inconsistency as a fault to be fixed, rather than as ordinary human variability to be worked with?

Have a great week!

Steve