Good engineers I’ve worked with over the years have always had one thing in common — they prefer precise communication. I do too.
Good engineers will demand that requirements and specifications are spelled out exactly and then make sure that they meet all the criteria perfectly. But great engineers communicate defensively.
I don’t mean defensive as in “it wasn’t my fault” — I mean defensive as in defensive driving.
As an engineer it’s quite natural to apply the engineering mindset to pretty much everything that’s happening around you — and we’ve actually seen this have tremendous results in non-engineering disciplines like sales, marketing, and fundraising, and even PeopleOps (I mean come on, PeopleOps is totally an engineering phrase)
The one place where I’ve seen the engineering mindset fail over and over is in workplace communication, and I’m the first to admit that I likely fail at this at least once a day for as long as I can remember.
One of the biggest improvements, however, for me came from a simple realization.
If you want to engineer precise communication, you have to practice defensive communication.
One of the biggest mistakes I used to make was to assume that incoming communication was “the truth, the whole truth, and nothing but the truth” — aka exactly what I “needed to know” or exactly what I “needed to do”.
I assumed that I was getting a spec that was always perfect.
If I was a driver, that would be like assuming that everyone always stops at a red light. You can’t assume that if you want to drive safely, you still have to watch the road and correct for other drivers’ mistakes to avoid accidents.
That’s the basic idea of defensive driving — to assume that other drivers are always making mistakes, but instead of painting a giant middle finger on your windshield, you defensively anticipate and check for them as you’re driving.
If everyone does this, the number of accidents is dramatically reduced.
Pretty much every communication accident I see on engineering teams can be boiled down simply to the fact that the people in question didn’t communicate defensively.
If the first driver assumes that the second driver will pay attention to their rearview mirror, some accidents happen.
If the second driver assumes the first driver will always flash their blinkers before turning, some accidents happen.
But it’s guaranteed to be safe if both assume that the other is not.
Here’s an example for an engineering communication accident
PM: This feature should guarantee that A=B and B=C
Engineer: Ok it’s done
PM: Uh your code is sloppy because A does not equal C!
Engineer: That wasn’t in the spec. It’s your fault.
PM: It’s your fault. You should have inferred that A=C from the spec.
Here’s a defensive version of the same communication.
PM: The goal of this feature is to make sure that A, B, and C are all equal. So we’ll need to check A=B, B=C, C=A, and maybe more depending on how you choose to implement it.
Engineer: It’s done. Since your specified checks didn’t assume that order matters, I’ll also guaranteed the reverse too, like B=A, because I’d expect that to be part of the stated goal of the project, even though it was left out of the spec. Let me know if that’s not the case.
PM: Sweet, thanks for catching that!
Do you agree about this style of communication? Let me know your thoughts.
About the author: Vinayak is the founder and CEO at Drafted, the referral network. You can find his other writing on LinkedIn and the Drafted blog