Today I had a fun chat with one of engineers on my team. He had posted a 20 page LLM generated PDF on Slack. And I was like, “yeah, roughly looks good, I couldn’t read all of it”. But what was the point? I think the fun (and hard) part was when I had to give him feedback about it.
I suggested him to give updates to leadership as if they had zero context. I suggested to keep it one page with a clear “problem / options / chosen solution” statement.
His response actually suprised me, he said “how can I give an update in this format, when assuming they have zero context makes me need to provide all this context!”.
This is the funny thing about communicating with humans. With LLMs you have to provide all the prompts and .md’s and all the context needed. But with humans its the opposite, and with leadership it’s even more extreme. You have to assume people won’t read, won’t listen, and it is your job to get their attention and engagement. That is the work of a senior engineer.
The engineer was obviously doing a lot, solving real problems, and just documenting his work as he was going through it. This is where a lot of engineers get stuck. And its a bit related to brag docs which is another superpower for engineers. Communication is not about fitting everything into one message, it’s about figuring out what the message actually is or should be.
It starts from figuring out who your recipient is. You are writing it as if you were them. Get yourself into their shoes. Be empathic. Think about what their day looks like. How many updates like yours they have to read. Then, with all that context (pun intend) you go ahead and write your update.
Your stakeholder usually needs a simple thing like: what is happening, why it matters, what do you recommend and whether you need anything from them. Example:
Problem: Releases are being delayed because we don’t have enough test capacity.
Options: Add capacity now, or spend engineering time changing optimizing.
Recommendation: Add capacity so we can finish the current migration. Revisit scheduling afterward.
Decision needed: Can you approve the additional capacity?
Obviously the stakeholder might ask “why do you recommend this”? Then you drill into the details, you share a link to some doc etc. It is their decision whether they will go down that rabbit hole or not. If they trust you, they might even just approve the request without thinking too much about it.
I had to learn this too
When I moved from IC to EM, I had to learn a lot of this and spent a lot of hours perfecting my communication, you have to be good at this if you want to be an effective EM.
But that’s not what I’m trying to say, what I’m trying to say is that everyone on my team is a leader (like written in Team of Teams or Turn the Ship Around!). I want all engineers on my team to communicate with stakeholders without my input. My job is to make them successful at that. That’s the hard part of being an EM.
And even with all that knowledge I have about this and all the hundreds of hours of coaching others about this topic, I still failed. I still found myself working with an executive that I just couldn’t communicate with. I was the one sending 20 page PDFs and gigantic messages on Slack with updates and questions. But now, a good few years after this, I am looking back and thinking “I messed this part up”. If only I figured out what is their communication style and what were their expectations, this relationship might have worked! I just couldn’t see it back then…
That’s why I give this advice. Investing in your communication is the best investment you can do as a senior+ engineer. You will get more things done with other people, you will get their support and quite frankly everyone will just enjoy working with you just that tiny bit more.
References & Further Reading
Will Larson — Irrational Exuberance
Gergely Orosz — The Pragmatic Engineer
Book
L. David Marquet — Turn the Ship Around!: A True Story of Turning Followers into Leaders
Stanley A. McChrystal - Team of Teams: New Rules of Engagement for a Complex World
Course
Communication as a Technical Leader — Coursera. I found this through a quick Google search and hadn’t evaluated it. Sharing it as an option to look into, not a personal endorsement.