#121 - The Ambidextrous Engineer!

3 Sep 26

Some of the most valuable skills I ever used as an Engineer weren't Engineering skills at all. They include project management, and the ability to ask a subject matter expert exactly the right question at exactly the right moment. Neither shows up on a technical qualification, yet both were the difference between a maintenance programme that held together and one that collapsed under its own complexity.

Trial Brief

Technical depth makes you a competent Engineer. It doesn't, on its own, make you a good decision-maker. The Engineers who go on to see the bigger picture, and consistently make better calls because of it, are usually the ones who deliberately built skills well outside the technical core: structuring complex work, and drawing the right information out of the people who hold it.

Trial Execution

I was seconded from the Royal Navy into industry at a point in my career where I assumed my value would come entirely from technical knowledge. It didn't take long to realise that wasn't where the hardest problem lived. The hardest problem was building a detailed engineering project plan that could meticulously schedule complex maintenance across marine engineering (propulsion and reactor), and weapon engineering, for four nuclear submarines at once. This had to be done whilst simultaneously ensuring that the integrity of their operational programmes was safeguarded.

That meant more than sequencing tasks. It meant identifying and exploiting the critical path, finding where work could genuinely run concurrently without compromising safety or quality, and building enough flex into the programme to absorb 'work in way' and emergent work i.e. additional defects which were discovered only once the major repairs were under way. All of this had to be done without the whole schedule unravelling and posing risk to the maintenance of the submarines' operational programmes. None of that was solvable through technical knowledge alone. It required understanding the plan as a system in its own right, and it required getting fast, accurate information out of the subject matter experts closest to each piece of work. This was done through the posing of targeted questions sharp enough to actually move the decision forward rather than just generate more discussion.

Trial Findings

Most Engineers can name their technical skills without hesitation. Far fewer can name the non-technical skills sitting underneath their best decisions, because those skills tend to be invisible even to the person using them well.

Project management is one of the clearest examples. It's often treated as an adjacent discipline, something a project manager handles while the Engineer focuses on the engineering. In complex, resource-constrained environments; four submarines, tight programming windows, safety-critical defect rectification, that separation breaks down fast. An Engineer who understands scheduling, critical path activities and concurrency isn't just supporting the plan. They're able to see opportunities in the plan that a purely technical view would miss entirely; where a defect can be worked in parallel with an unrelated task, where slack exists to absorb emergent work without cascading delay, and where the true constraint is programme, not people or parts.

The second skill, eliciting information through focused questioning, matters just as much and is even less often taught deliberately. Subject matter experts frequently hold the exact information a decision depends on, but rarely package it in a form that's immediately usable. Getting it out cleanly is a skill in itself. Knowing which question to ask is key since it serves to narrow the problem rather than widen it. Also, which follow-up question to ask which turns a vague answer into a decision-ready one. An Engineer who can do this consistently makes better decisions not because they know more, but because they're better at extracting what others already know.

Both skills share the same underlying value: they pull an Engineer out of the narrow, purely technical view and into a broader, more holistic one. Here, the bigger picture is visible and decisions account for more than just the immediate technical question.

The Common Thread

Being an effective Engineer increasingly depends on skills that were never labelled 'Engineering specific' in any curriculum. Project management gives you the structure to see where the real opportunities and risks sit across a complex programme. Focused questioning gives you access to knowledge you don't personally hold. Neither replaces technical depth but both multiply what it's worth.

Trial Sign-off

One practical action

Look at a current piece of complex work you're responsible for. Identify its critical path, and one place where work could realistically run concurrently rather than sequentially. If you can't answer that quickly, that's the gap to close first.

One question for reflection

Which subject matter expert around you holds information critical to a decision you're currently facing, and what's the one focused question you haven't yet asked them?

Have a great week!

Steve