Weak Soft Skills: Why you are stuck at the Senior engineer level
Part one of my three-part series on growing your soft skills
Welcome to the very first post on Path to Staff Engineering! Subscribe, and I will teach you the skills to level up to Staff faster 🙂
I am also looking for writers to collaborate with. Please feel free to reach out here or on LinkedIn if you are interested.
Read time: 7 minutes.
After observing hundreds of staff+ engineers, I realized that mastery of Soft Skills is the most significant difference between a Senior and a Staff engineer.
What are soft skills?
Soft skills enable engineers to interact better with others. They are not technical or job-specific and can even be transferred to other parts of life.
I have observed that a Staff engineer has mastered these three skills:
Communication: This includes writing, speaking, and nonverbal communication. Think of super communicators who bridge the gap between technical and business contexts.
Adaptability: Engineers who are willing to change positions or are flexible in what / how they do are valued across teams.
Challenging Situation Management: This is the ability to deal with sticky situations. Cases when a teammate doesn't pull their weight. Or when you're dealing with passive aggressiveness. Or where there's unequal recognition and credit.
In this piece, I'll be covering Communication. Two follow-up posts will cover adaptability (2) and Challenging Situation Management (3).
Communication
There are three main modes of communication: Writing, Speaking, and Nonverbal. I provide personal tips, examples, and what I would and wouldn't do in each mode.
Writing
Why write?
You probably think, "I already code all day – I don't need to learn how to write." Wrong. Staff engineers are always writing technical documents, slides, and project updates.
My top writing tips:
Consider your audience. Who am I writing for? What am I writing about? What do previous pieces look like, and how did those work out?
Read and re-read: Spend three times as much time reading as writing it. Delete what's not useful. Every word counts.
Be succinct: Make what you're trying to communicate clear. Place a TLDR to help others understand quickly at a glance.
Write regularly. Even if you don't share what you write, you must write over time to figure out your style. Writing regularly is the only way to do that.
Read, learn, copy: Learn how others write by reading various genres and authors. These can be technical documents, nonfiction books, or other project updates. Save the ones you like for future reference.
Let's walk through an example.
Example: I need to write a technical spec for engineers in & outside of my team.
What I'd do:
Do my research: Find great and bad examples that communicate clearly. Learn and understand what worked and what didn't. Know what style I'm going for before diving in.
Put it together: Define all technical terms and set common ground. Share the context of what I'm trying to achieve. Structure content clearly. Re-read five times. Use AI to ask for suggestions.
Finalize and share: Reach out to key stakeholders with drafts for early feedback. Place an RFC (request for comment) tag and share it. Specify how long it will take to read. If necessary, gather stakeholders for a discussion.
What I would NOT do:
Share a half-assed draft. These are easy to spot. Unfinished sentences and lack of organization give it away. Don't ever do this!
Use AI to generate all of your posts. These are also very easy to spot. I do use AI, but primarily for editing. I would only use AI to draft or complete part of the post.
Blindly copying others entirely. People know if you copy, and you'll lose trust instantly. You want to find your tone and style and develop it over time.
Now that you know how to write, let's move on to the next: Speaking.
If you’ve found this helpful, subscribe to stay updated for the next part of the Soft Skills series.
Speaking
Why learn how to speak?
Speaking is an often overlooked skill. When you speak better, people can follow your thoughts. You have to learn how to present your ideas concisely.
When I refer to speaking, I mean speaking to a group audience, not in 1:1s. For example, you'll be speaking when you lead meetings, participate in stand-ups, or present to a large audience.
My top tips for speaking:
General tips:
Be concise: Write down what you want to say before you say it. Nobody likes someone who blabbers on and on. Say your TLDR first, and back up your statement.
Speak clearly and confidently. People will ignore you if nobody can hear you or you're unclear. Enunciate your words. Speak at a steady pace.
Watch how your audience reacts. You have the benefit of being able to see how people in the audience react. See if they're engaged or falling asleep, and tailor your delivery.
Presenting a slide deck:
Set up your slides: Use illustrations and images when you can. Do not fill up your slide with text. Use speaker notes to guide yourself when you speak.
Copy great examples. Like writing, you'll need to learn how to present. Go on YouTube and watch a couple of TED talks. See how Steve Jobs presents. Practice in front of a mirror.
End with impact. Your last slide needs to be memorable. Summarize your key points and a call to action. This is what the audience will remember most.
Leading or participating in a meeting:
Take copious notes. If you can't, designate someone else to be the notetaker.
Set and share an agenda ahead of the meeting. No one likes to meet for the sake of meeting. As an attendee, I'll decline if I'm not benefitting from or contributing to the meeting. If there's no agenda, cancel the meeting.
Practice active listening: Affirm the other party's points by repeating them. Be the last to speak if you can — this will help you shape your argument better. If you don't have to speak, you don't need to.
Now, with all that said, let's walk through a simple example. You're about to present a brown bag series on a new React component you recently built.
What I'd do:
Fill my demo with images and videos: Since I'm building a React component, I have a ton of slides to showcase how it can be used, with different props being passed in.
Designate a teammate to collect feedback: I'll have a Q&A at the end to ask for feedback. I've designated Judy to help take notes since I want to focus entirely on replying.
Send out a link to slides and wiki after: Given that the team is interested in using it, I'll prepare a wiki on how to use the component. I'll send the wiki and slides to the team after the presentation.
What I would NOT do:
Fill slides with text: People will never remember my slides or what I was presenting about.
Try to take notes while presenting. Multitasking prevents you from focusing on conveying your message.
Last, let's tackle the trickiest form: Nonverbal communication.
If you’ve found this helpful, subscribe to stay updated for the next part of the Soft Skills series.
Nonverbal
What is nonverbal communication?
The American Psychological Association defines nonverbal communication as "communication occurring through facial expressions, gestures, body language, tone of voice, and other physical indications of mood, attitude."
Why is it important?
This is the most overlooked form of communication. Speaking and writing are often taught in classes as children, but not nonverbal communication. However, if you work on your body language or choice of tone, you will be able to understand others better.
For each of these tips, it is important to observe the other party and yourself. I'll also weave the examples into the tips to make them more relevant.
My top tips for nonverbal communication:
Observe body language: Watch for the other party's body language. Are they frowning? Are they getting bored? Understanding body language allows you to tweak your content and delivery.
What I'd do: Maintain eye contact with the audience as I present. I can see they are distracted, and my content/tone is not resonating with them. I need to adjust that by speaking slower and asking questions.
What I would NOT do: My audience seems to be frowning – they're probably lost. Ah, who cares? I'll barrel down this road and finish it.
Watch your/their tone: Tone can convey a lot of information. Our voices naturally vary their pitch, pace, and volume. Common tones include stress, relaxation, quiet, unconfident, monotonous, or aggressive. You need to adapt your stance based on these tones.
What I'd do: A junior teammate, Tom, sounds monotonous when providing standup updates. I note this down in my next 1:1 to check in on him. Perhaps he's not too pleased with his assigned task or just having a bad day. Nevertheless, I use this opportunity to try to connect with him.
What I would NOT do: Tom shares his updates in the same monotonous voice the next day. I get upset and shout at him, "Why are you talking like this??" This embarrasses him and causes him to leave the Zoom.
Smile: This is a simple one. I smile at the start and end of a meeting. This reduces tension and creates a positive atmosphere. Of course, don't overdo it; otherwise, you'll look silly for smiling all meeting.
TL;DR
Communication is essential. All Staff+ engineers I've interacted with have already mastered this skill, and so should you.
Writing, Speaking, and Nonverbal Communication: To level up, you need to master these three forms of communication.
Write succinctly: Consider your audience while writing. Organize your thoughts. Copy your favorite examples.
Speak clearly, and they will listen. Be concise and confident. Take notes if you can. Practice active listening.
Improve nonverbal communication to understand others better: Observe body language and tone. Smile more often.
Thanks for reading. I hope this helps you in your journey to grow as a software engineer. Have thoughts or feedback? Comment or reach out to me here or on LinkedIn.
Great first article, Sidwyn! Looking forward to learning more from you.
This part made me 😂:
> What I would NOT do: My audience seems to be frowning – they're probably lost. Ah, who cares? I'll barrel down this road and finish it.
Great article. Useful for all levels not just those planning to become Staff Engineers. Will you be linking the 2nd to articles here? If not what is the best way to find them?