Ten communication tips for staff-plus engineers

As a staff-plus engineer, you likely advanced through your career solving challenging technical problems. And now that you've reached the staff-plus level, it'll just be more of that - won't it?

Sorry!

While in well-crafted staff-plus roles you will have sufficient focus and time for helping teams solve technical challenges, as a technical leader your scope now includes additional areas where so-called "soft skills" are very important. And your work up until this point may have been more on the technical side, so the importance of soft skills can be one of the bigger adjustments that staff-plus engineers such as yourself need to make to be successful in their role.

Over the past few years I've held several staff-plus (staff engineer and principal engineer) roles and had the privilege of working with many great folks. From engineering teams, fellow staff-plus engineers, cross-functional partners, to senior leaders.

Along the way I've learned much from these great folks and through other resources to help be more effective at the aspects of a staff-plus role outside just the technical parts of the role. I've compiled a set of tips related to communication as a staff-plus engineer that have helped me. Hopefully they'll be helpful to you as well!

Getting the right answer vs having the right answer

As you're moving up the engineering ranks, you often solve difficult engineering challenges with your solution. After all, building and delivering your solutions is often how you rose through the engineering levels.

But now that you are at the staff-plus engineering level, you will be involved in more projects. And often at a more surface level than earlier in your career. If you try to find the answers to problems you encounter with just your own knowledge and experience, you will automatically become the limiting factor on problem-solving.

But if during brainstorming sessions you instead focus your energies on creating space for your teammates to share their ideas. Then you can benefit from all of their collective ideas - not just yours. And asking questions instead of making statements can be a great way to hone in on the solution with your teammates.

In addition to getting a wider breadth of possible solutions from the folks closest to the issue, if the chosen solution came from the team they will feel more ownership of it. They will be more invested in seeing the solution a success than if they are just implementing your idea. And they will also feel more free to adapt that idea as the problem evolves. All benefits of guiding them towards a solution vs relying on your ideas.

Now that's not to say you'll never have the answer. Sometimes that will happen, as it has throughout your career. But don't aim for it every time. Instead, help guide the teams you work with and give them space to come up with their own solution. And in my case, those solutions from teammates are often better than anything I came up with!

Most charitable interpretation

You see it often on social media or text-based communication at work - a reader highlights a small portion of a comment, takes it to the extreme, then argues against that dire conclusion.

I'm sure you've seen it at work too - in a meeting someone starts arguing against a straw-man argument that no one is actually proposing. It derails the conversation, taking time and effort to get the discussion back on track.

We've all been there - where it feels good to create a straw-man position out of someone else's idea and argue against it. But one of the key differences I've noticed between discussions amongst senior leaders and ICs and wider discussions is that you will rarely (if ever) see this intentional worst-interpretation approach from more-senior folks.

Why? This approach adds nothing to the discussion and even takes away from it by requiring time and effort to get past it and move the discussion forward.

This is especially important in text-based communication like Slack. It's easy to repeatedly read a Slack message, take the worst interpretation, then respond to that interpretation. But that's not productive to the conversation at all.

Instead, now that you're a senior IC - you will be a much more productive discussion participant by taking the most charitable interpretation of someone's idea or comment. That is - "when interpreting someone's statement, you should assume that the best possible interpretation of that statement is the one that the speaker meant to convey." (from Principle of Charity) Then you can help advance the discussion and get to a solution much more quickly. And it'll be much more pleasant for the everyone in the conversation!

Praise in public

Now that you're a senior IC, your words have even more of an impact. And one of the ways you can use that impact for good is to praise the impactful efforts of the folks you work with.

From congratulatory responses to email or Slack announcements, comments on pull requests highlighting key contributions, and more - your words of encouragement or congratulations can mean a lot to folks.

You might think - isn't it the job of managers and other leaders to publicly praise teams' work? While that's true, being positive seems to often be part of the job requirements of management leaders. That's not a bad thing, but in your role as a senior IC you are often viewed as more objective and independent that management. So praise from you means even more.

Timely constructive feedback in private

I used to feel uncomfortable giving folks constructive feedback. I'm not perfect, who am I to judge them? But then a trusted leader told me that I was holding people back by not giving them timely feedback when there was something that needed to be corrected. And he wasn't wrong.

While giving constructive feedback still doesn't feel great for me while I'm doing it, I do it to try to help the person correct behaviors that may hold them back in their career. Then it's worth the discomfort.

Another time when timely constructive feedback is key is when the behavior is impacting the rest of your team. More junior folks on your team likely won't have the same comfort level with providing feedback, nor will they have the organizational pull that your title provides. Use your organizational power for good and help folks correct behavior if it is significantly negatively impacting your team.

And when delivering constructive feedback, I find private conversations to be the most effective venue. I've found the receiver is much more receptive to change and less likely to feel defensive than if the feedback comes in front of an audience. The goal here isn't to embarrass anyone. It's to help individuals and teams be the most successful they can be in the workplace. And with timely feedback in private, you can help.

Share context

In your staff-plus role, you'll likely be involved in discussions about the context of a project - its impact on users and/or the business, how it fits into a wider initiative, etc. At its root, you'll know the "why" of the project.

Knowing the "why" can help the engineers on the ground implementing the project ensure they are building the right thing that satisfies the project's goals. But the "why" may get lost along the way to the implementation team, distilled into bland requirements.

You can help the engineer teams you work with be even more effective by sharing this project context with them. Plus knowing why the project is important to users helps motivate folks beyond just implementing a set of stories or requirements.

Document context as well. Including the "why" in docs I write helps the docs be more valuable to current readers as well as future readers.

Context in a doc helps folks know the purpose of the doc, as well as the environment and constraints in which I wrote the doc. And in the future the context changes, it's easier to revisit the doc vs having to start from scratch.

Do repeat yourself

You're used to the programming principle "don't repeat yourself" or the DRY principle. While that can be effective for working with code, it is not effective for working with people.

If something is important, drive it home by repeating it in different contexts and with different mediums. Email, docs, presentations, Slack messages, etc. For key concepts to take hold amongst your teams, repetition is key.

After all, put yourself in your teams' shoes. You've heard someone mention something new that requires a shift in work or a shift in thinking - and change isn't cheap. How do you know which changes are serious vs just something mentioned in passing? How often you hear about it. So reinforce key topics with your team by repeating them across different mediums.

When I want to disseminate a key topic, I'll take this approach: give a presentation then follow up with a written doc. That way folks can start absorbing the topic in the presentation and have a chance to ask questions. Then they can refer to the doc later to remember specifics.

Ask dumb questions

You'll be brought into a wider variety of discussions, often without the full backstory. Get comfortable asking basic questions that may seem dumb to others, but bring you up to speed with the info you need to make informed decisions.

And as one of the more senior people in the room, asking basic questions also frees up more junior engineers to ask those types of questions without feeling dumb themselves.

I'll often preface a basic question by specifically saying "I have a dumb question." That way people will expect a basic question.

Avoid accidental orders

Participating in brainstorming sessions is a normal part of your staff-plus engineer role. If you're not careful, your verbalized musings could be misinterpreted as an order now that you have a higher-level title.

If you're thinking out loud, then specifically say "just thinking out loud here" or something along those lines. Otherwise, the engineers in the meeting with you may think that is a settled direction and run with it.

Similar to some items above, asking questions can be a great way to elicit discussion without unintentionally shutting it down with an accidental order.

Bring clarity

As a staff-plus engineer, you'll be in more meetings than in your previous roles. This is not a judgement on whether the number of meetings is good or bad, it's just reality.

I think of part of my job is to ensure that if I'm in a meeting, folks leave that meeting with more clarity than when they entered the meeting. Whether that's action items on next steps, specific follow-up questions to investigate, a direction to pursue, etc.

That way, folks become unblocked and the work can move forward. Even if I'm not solving a problem with my own solution, coalescing the ideas from a group discussion and aligning the participants on next steps is a great way to help.

Smooth conversations

Tensions run high. Voices are raised. We've all been in conversations or meeting like this. And one of the ways you can make as a senior IC is to help cool down the temperature.

When this happens in group meetings, keeping your emotions in check and redirecting others who are amped up can help preserve the peace for everyone. I've found that noting their concerns (I often write them down) and offering to take their issues offline - to be discussed in a smaller setting - is a great way to get the discussion back on track without making anyone lose face.

And every so often you may be in a conversation that is exceptionally antagonistic and counterproductive. Earlier in my career, I was in a meeting like that with about a dozen other people. No one shut down the conversation when it turned, and one key engineer on the team was significantly demotivated by how they were spoken to. Now I keep a watch out for such conversations and wrap them up quickly if they do occur.

By using the influence of your senior IC title and keeping an even emotional keel, you can help smooth over the bumps that sometimes crop up in work conversations. And help stop those situations from escalating further and potentially causing longer-term damage on the people you work with.

This isn't to say that you should never have contentious conversations at work. Hard decisions need to be made in business.

But audience is key. Save those contentious group meetings for discussions with other senior ICs and leaders. Work to smooth rough group conversations that include more junior team members.

Bonus tip

For those who've made it this far, we've covered ten tips. And I'll let you in on more bonus little secret. Over the years I've been doing this last technique several folks from inside and outside my teams have commented on how they've liked it. So I figured I should include it here as well.

Any time someone asks you a question, I start my response with "Good question!" I first started saying this years ago when folks asked questions after my conference presentations. It takes a bit of courage to ask questions after a presentation, and I appreciated when folks took that leap and asked a question. I wanted to encourage questions, so I'd comment that it was a good question.

Now I do it all the time! When folks ask me questions in meetings, in Slack conversations, in presentations, in docs comments, and more.

Recently someone I work with adopted this practice as well. They even use it when I ask questions. And after being on the receiving end of it myself - folks over the years were right! Hearing "good question" is validating and does just make discussions more pleasant.

Conclusion

If you're not an expert in all these communication areas yet - don't worry! Similar to how you didn't start your career knowing how to optimize a database query or center a div on a page, with learning and practice you can learn these behaviors as well. And none of us are perfect, I'm still a work in progress on these items as well.

Hopefully these tips can help you level-up your communication skills and become even more effective in your staff-plus role!