1. Listening

Not only just listening, but understanding. When you’re reading an RFC, listening to someone’s proposal, or just chatting with your mentee it’s important to not just listen but understand.

Have you ever just continued nodding when someone was explaining something and you had no idea what they were talking about?

You can’t do that anymore! Start asking follow up questions and try to truly understand the context before moving on.

2. Not Getting Defensive

A huge part of the job at staff is proving your proposals are worth people’s time. Obviously this can be harder if you’re part of an underrepresented minority (trust me I know 😭).

What I’ve found most helpful is always having a way to back your proposals up with numbers. If you have a graph proving you right it’s hard for people to disagree.

3. Speaking in Public

It’s time to get out of DMs and private channels. As a staff engineer almost all of your conversations should be in public. This helps for a couple reasons:

If people are asking the same questions now more people can see your answers
It gives you the opportunity to include others in the conversation
You gain visibility

4. Talking Outside Your Team

Have you ever used an internal tool, or worked in another codebase and thought, “man this kind of sucks.” Instead of complaining with others on your team, what about providing feedback to the other team at your company?

Or even better, what if you helped them out by fixing the problem yourself?

Staff engineers are solutions oriented and don’t think of their scope just within their team. How can you support teams outside of your pillar?

5. Clear and Concise Messaging

Similar to #2, you’ll have to learn how to get your point of cross clearly and concisely. If you write a wall of text… nobody is going to hear it. How can you explain your proposals and ideas in a way that anybody in the whole company could understand what you’re trying to accomplish? Leave the technical details for the RFCs.

Thanks for reading! Have a great week ☀️

Eden