Fast Engineering and the bottleneck between 2 brains

11 minutes ago

3 min read

Two engineers can know the answer between them and still take a surprisingly long time to solve a problem.

One has the project context. The other knows the equipment. Both are capable. Neither has quite enough of the other person's picture.

So they exchange messages.

Then screenshots. Then a call. Then someone finally draws a box and an arrow, and the missing connection becomes obvious.

The bottleneck wasn't simply how quickly either person could think. It was how effectively the information moved between them.

First, work out what needs to cross the gap

When you ask another engineer for help, what do they need to understand?

Usually it's the intended outcome, the observed behaviour, the relevant constraints and the decision you're stuck on.

Start there.

A long stream of everything you've investigated can make the important point harder to find. A message with too little context makes the other person reconstruct the situation through follow-up questions.

You want enough detail to support the next decision.

Ask a question someone can answer

“Any ideas?” may be fine in a casual conversation, but it leaves the scope wide open.

“I have checked these two inputs. The event appears in the controller log but not the display log. Which part of the path would you check next?” gives someone a useful starting point.

It shows the current state without pretending you know the cause.

If you want a decision rather than general guidance, make that explicit. “Can you confirm this interpretation before I update the drawing?” is a different request from “What do you think of the design?”

Choose a format that fits the problem

Text is useful for exact wording, searchable records and carefully bounded questions.

A marked-up screenshot can show a location. A simple diagram can show relationships. A short conversation can uncover an assumption that would take ten messages to identify.

Match the format to the uncertainty.

If the issue is where two systems connect, draw the interface. If the issue is a sequence, lay out the events in order. If two people mean different things by the same word, agree on the definition before debating the solution.

A technically accurate paragraph isn't automatically the clearest way to transfer a technical idea.

Make typing easier, but don't confuse it with solving

Keyboard fluency, useful shortcuts and reusable templates can reduce the effort of routine communication.

That doesn't mean typing faster will fix an unclear question. It may just produce more of it.

First make the structure clear. Then look for repeated work you can simplify: a standard fault-report format, a meeting-note template or a checklist for handing over a test result.

Don't put passwords or sensitive system details into convenience tools. Work within the information-handling arrangements for your project.

Confirm what arrived

Sending an explanation doesn't prove the other person received the same meaning.

Ask them to describe the next action, or summarise your understanding of theirs.

“So we're keeping the existing interface, changing the mapping in the test environment and reviewing the result before any deployment. Correct?”

That check is particularly useful when a discussion mixes observations, possibilities and decisions. Someone may remember a suggested option as an agreed instruction.

Put the actual decision somewhere both people can find it.

Leave a record that survives the conversation

A useful handover explains the current state and the next step.

Include the relevant revision or version, the result, the unresolved question and who is doing what next. Link to the working record rather than scattering copies across messages.

Avoid “We discussed it and agreed the change.” What change? Which version? Under what conditions?

Documentation for Engineering Projects and Future You goes further into making that record useful after the original conversation has faded.

Notice the questions you keep asking

Repeated clarification is feedback.

If every handover prompts “Which version?”, add a version field. If every review needs a sketch, include one earlier. If people keep finding the wrong file, improve the reference rather than explaining the folder again.

You don't need to optimise every interaction. Start with the recurring point of friction that costs your team time.

Ask whether the person on the receiving end can act with the information you've supplied.

Fast engineering needs shared understanding

There is a limit to what you can achieve by making one person work faster while the handover remains unclear.

A well-framed question, a useful drawing and a confirmed decision can move the whole task forward.

Before sending your next technical message, check three things: can they see the problem, do they know what you're asking and will the answer lead to a clear next action?

That's a good place to remove a bottleneck between two brains.