My CFO complained once that the best way to improve the company’s finances is to have the software engineers work harder. Looking at myself, I completely understand his perspective. But I’m getting more and more hardworking each day because of the social pressure to be a good loyal teammate to my colleagues. They’re not the best engineers, but truly the first team where I exclaimed “You’re so pleasant to work with.”
Let’s not say I am a pleasant teammate yet. But here are some pointers I’m stealing from my colleagues.
Two meetings that really impressed me: with my skip Engineering Manager, and with the Chief Product Officer (CPO).
In both cases, I walked in with the expectation that it’d be an informational interview where a lowlife junior engineer asks for advice from the senpai. However, they flipped my expectations and prepared for the meeting even more than I did (All I did was to come up with a list of generic questions).
They came in knowing who I was, what team I was on last summer, and asked how I was doing. The EM, knowing that I’m an absolute clueless chicken, gave me the context of my team within the company. She made not knowing feel comfortable because she always checked in “Are you familiar with the term X?”
The CPO flipped my expectations even more - he straight-up interviewed me for a good 10 minutes, intently listening to what thoughts, concerns, and dreams exist at my level. It was like those Chinese kungfu movies, where the king costumed himself as a civilian to see the state of the country outside the palace.
Because of this, even though the meeting time was short, I came out refreshed and unhurried. Making people feel like they truly spend time with you instead of just another slot on Google Calendar is a superpower.
Another colleague told me she’s done the bulk of her job at the beginning by building trust. “Once they trust that you have good judgment, you don’t have to do the persuading job every time anymore.” And a big part of building this reputation comes from being prepared.
Two main ways I’m being intentional about communication: Bullet point & Context
Bullet points:
I learned this from our CPO, who got communication training at Meta. During all hands, I almost always zone out with other C-suite speakers but engage with and can follow through with what the CPO says.
His rules? Everyone functions in a virtual Table of Contents.
This is why you always start with TLDR. Then use bullet points. Your classic boring “First is, second is, third is” works. Without this, the audience drowns in a sea of information. If they don’t get what you’re trying to say, they won’t have the patience to stick with you.
Context: When you communicate at work, it’s either to inform a stakeholder, have a specific question, or ask them to do something for you. To situate myself in these cases, I ask myself a set of 3 questions:
For example, at the beginning of my job, I informed the Customer Support team in a real stupid way
Hi Customer Support team, I’m about to launch X feature. Just a heads up so you can update your workflow.
Well intent information, but what is X feature (software engineers are bad at naming)? Why is it relevant to CS team? How would it affect our workflow? Hence 18 messages in a follow-up thread.
Let’s revise it.
TL;DR: Account Onboarding team is about to launch X feature, which will influence CS team’s workflow. Hi CS team, I’m working X feature. Because we’ve been experiencing Y, this feature is supposed to help ZZZ. What will happen to customer is: ___ For CX/ Operations team, when customer reach out, I suggest you can do ABC. However, these are only suggestions. Let me know if I can help or clarify anything else.
This message is slightly longer but will save the 20 follow-up messages.
There’s also the context of the project. My manager taught me to think about “upper, lower, and cross” communication. Who are all the stakeholders for this project? From each axis - upper management, lower dependencies, cross functionalities? Remember to keep each of them updated, not only for the sake of the project but to also build trust and rapport with everyone.
In both meetings above, they ended with “I’m only a Slack message away. Don’t hesitate to reach out.” The CPO even went further, knowing that I might never do that because of the thinking “he’s a busy CPO.” He said “just send the message, I’ll do the filter based on my bandwidth. But I want to encourage feedback and good ideas from everywhere in the organization.” That made me feel super respected and the door is truly opened.
But it’s not just those big people, my teammates are awesome too. Now that I’ve been here for 3 months, my onboarding buddy never stopped ending our chat with “feel free to reach out if you have any more questions. Happy to help.”
Another teammate also says “Let me know if you have more questions,” even though he’s just helped me debug in the past 50 minutes looking at squirmy bug logs and I could tell he was tired.