Engineering conversations are not just about engineering

In any meeting between two engineers, technical information is being exchanged on the surface. Underneath, something else is happening, and that something else is often what determines whether the work goes well or poorly. Engineers as a profession are undertrained in noticing the underneath. I have spent years training myself to notice it, and I want to write what I look for.

The simplest signal is the one most engineers already pick up on without naming it. When you propose a design and the other person says “yeah, sure,” there is a difference between the “yeah, sure” that means agreement and the “yeah, sure” that means they are not going to push back here but they will quietly fail to follow your design in the actual work. The first is conviction. The second is conflict avoidance. They sound the same. They are not the same. If you read the second one as agreement you will get a worse outcome than if you had read it correctly.

A few signals I look for in technical conversations.

When someone explains a decision, watch for the moment they explain something they were not asked about. The unprompted explanation usually points at the part of the decision they are least confident in. They are pre-empting your objection. The next question you should ask is the question they are pre-empting.

When someone says they will get to something next week, watch their body. If they are looking at you while saying it, they have a real intention. If they are looking past you, the thing has already been deprioritized in their head, and they have not told you yet.

When someone repeats your point back to you using slightly different words, they have understood it. When they repeat it back using your exact words, they have memorized it but they have not understood it. The first is a green light. The second is a request, usually unspoken, for you to say it differently.

When someone gets quieter while you are explaining something, you are losing them. When someone gets louder, they are excited or they are about to disagree. The two states look similar from a distance. Watch for the next sentence.

When someone reaches for their water bottle or their phone in the middle of a technical conversation, something just happened that they did not want to react to publicly. It is often the most important moment of the conversation. The thing they did not want to react to is the thing worth following up on.

When a senior person asks a question that has an obvious answer, they are testing whether you will give the obvious answer or whether you have noticed the non-obvious thing underneath it. The obvious answer is sometimes correct. The non-obvious thing is often the actual question.

I could keep going. The point is not the specific signals. The point is that engineering work happens between humans, and humans communicate at multiple layers at once, and an engineer who only listens to the surface layer is operating with a fraction of the information available to them.

There is an objection to this kind of attention. The objection is that it sounds manipulative. I have heard variants of it for years. The objection is wrong in this case, and I want to be clear about why.

Reading people is not manipulation. Manipulation is using what you read to get someone to act against their own interest. Reading people is using what you read to understand what they actually mean, so you can respond to what they actually mean rather than to what they are saying on the surface. The first serves them. The second deceives them. They are different skills, deployed for different reasons.

Engineers who can read people well end up with better outcomes for everyone in the room. They catch the disagreement before it becomes a project delay. They notice the team member who has been overcommitted before it becomes burnout. They hear the silent veto in time to address it. They communicate technical ideas to non-technical stakeholders in ways those stakeholders can actually act on.

None of this is in the engineering curriculum. None of this is in the technical interview. None of this gets a Jira ticket. It is some of the most leveraged work an engineer can do. I think more engineers should treat it as a discipline worth studying, the same way they treat algorithms or systems design. The return on the time is enormous.