How to Communicate as an Engineer
There is a running joke at my company that i communicate with analogies. I take it as a compliment. Reason being that i have found no better way to explain abstract technical topics to lay people.
Consider this common example. My coworker, Tim, doesn't understand why two similar-looking development tasks might take wildly different times to complete. I explain to Tim that software is like a house. The first task he asked for was like moving a painting from the living room to the kitchen. Easy. The second task was asking me to move the toilet into the stairs. This involves more than moving the porcelain. There is a lot of hidden plumbing that has to move as well. "Ahh', Tim says.
This ability to distil complex topics to the rest of a company is critically important as your role in your team increases. Without clear communication, the engineering department can appear as a black box to outsiders. If this happens, praise becomes infrequent and blame is cast too casually.
This is because black box systems suffer from a perceived gap between results and the humans responsible for them. Think of traffic lights. I don't praise anonymous programmers when lights are synchronized well. But i am quick to point my accusatory finger at The Man when i have to wait at a red turn signal staring down an empty street. Quick to blame, rare to praise. Teams without a clear communication outlet to the rest of the company suffer the same problem.
So how do we clearly communicate the ebbs and flows of development our company? These are a few guideline i have found most effective.
Stay out of the weeds
Developers are infamous for giving enormous explanations when asked simple questions. When we do this, we sound like Charlie Brown's teacher to our audience. We should try to stay as high-level as possible when answering questions. This sometimes means skipping details you feel are important. That is ok. If someone feels like they have missed something, they can always ask for more detail (spoiler: they rarely do).
Distill complex topics
In similar fashion to avoiding long-winded responses, it is a good habit to find your way of simplifying complex topics into easily consumable formats. I do it through analogies, as i've now done a couple of times in this post. Others find writing it down gives them time to review their answers, removing the superfluous details. Others still find drawing their answers allows them to best simplify the result.
Whatever flavor you are most comfortable with should be your starting point.
Celebrate wins publicly
While the above points focus on talking too much, the reality is dev teams are too often silent. Teams should publicize their victories more. Sales departments are best at this. Which is easy for them because money talks. Well, results speak volumes, too. We can take a page from their book. Find a results-first way to communicate your team's victories to your company. Make a habit of doing so regularly. This is an opportunity to lift the veil of mystery surrounding the dev process.
Remember it is important to keep the reports results driven, too. No one cares that you refactored 2-year-old code without test coverage. Instead, talk about how the system is faster or is now half its size, or we have an automated test suite that stands to reduce bugs in this system moving forward. Results over details.
Communicate empathetically
The principle lesson here is that empathetic communication is effective communication. The best communicators give their answer in a format that other may best understand it. Developers have a habit of answering so that other developers could best understand it. This is great when talking to devs, useless when talking to your head of marketing.
If you are at a company where the development team is a black box, make an effort to start communicating about your wins and losses to others. This can be tricky at first while you learn to distil things in a way that is consumable. If you are at a company that already has an outlet to the rest of the company, start paying attention to how they communicate so effectively. It is easy to take it for granted when you haven't been the one doing to talking.
Finally, if you are the communication source at your company, share the importance of it. Coach your team on becoming better communicators to the rest of the company. All said and done, it may be the single most valuable lesson you give them.
tl;dr: The ability to communicate with nontechnical coworkers is paramount to providing unique value to a company.
