@May 26, 2021
I've learned a lot at Tesseract about effective engineering communication, especially what works and what doesn't work. Obviously, this is a work in progress, but here are some initial observations.
Written detail is an engineer's best friend
Writing detailed technical summaries of issues is incredibly important. Working with experienced engineers, I've learned a lot from looking at how and why they put these together. Invariably, effective, detailed summaries do two things:
- impress others with your ability
- create a basis for a useful common discussion
When you write detailed summaries, you engage in the above two things.
A simple way to write more is to default to writing. Too often as engineers, we start with implementation (i.e. quickly writing code). Take a step back. Write out what you will do, then start to implement. Interestingly, this dovetails well with the "future press release" method that Amazon pioneered for project management.
To be more specific, effective and detailed summaries tend to:
- Clearly state progress, ideally in metrics
- Always use pictures and diagrams
- Tell a story; no one wants to read dry performance metrics. Stories and narratives engage readers.
Meetings are the enemy
Limit the number of meetings on the engineering side. This is because working towards meetings, rather than a specifically defined end goal, is bad. Meetings enforce urgency, not always importance. That is, sometimes, the thing you have to be working is not the best thing to work on, and the reason can be meetings. Keeping meetings minimal allows engineers to more effectively reach the point where important is the same thing as urgent. In general, I think this tends to happen when you're working with someone nontechnical. That, however, is not an excuse for allowing it to happen. Communicate to stakeholders the importance of your time spent executing engineering tasks.
To reduce meetings, here are 3 simple recommendations:
- Explain more issues "on paper" with email and memos. Explaining issues is best dealt with on paper. You don't want meetings where you're explaining things. I think that that's an important rule, because by definition, explaining things over is often a subpar method compared to writing often.
- Run more effective, targeted meetings. A bad meeting interferes with progress and wastes time. It often reduces clarity around what actually needs to happen, leading to operational drift. Ask yourself, is there a clear agenda for the meeting? Is a successful end to the meeting a decision? Is it a shared consensus? Be clear about this and focus on it.
- Be defensive of your time schedule. Don't be afraid to delay meetings until the communication can occur at the right point.
Clarify tradeoffs
Engineers are charged with making clear the second order effects of decisions. This means making clear timelines, implementation methods, technologies; in a nutshell, the trade-offs of every decision.
I've found that the best engineers, through their ability to forthrightly communicate these trade-offs, often get what they want, keep their superiors happier, and are less tense about their work. After all, tension is simply "wanting things to be different than they are." When you know your role and communicate effectively within those bounds, you resolve this tension. You make a level effort to make the world a particular way, and if it happens not to be, it's only because it's out of your hands.
The best communication about tradeoffs is practical and project-oriented, not theoretical. This helps non-technical better understand what you are thinking.