The Performance Pyramid (part 1) – Communication

Index

• The Performance Pyramid (part 1) – Communication
• The Performance Pyramid (part 2) – Ownership [TBD] I'll talk about the "Ownership" boulder
• The Performance Pyramid (part 3) – Tech Skills [TBD] I'll talk about the "Tech Skill" boulder
• The Performance Pyramid (part 4) – Team Management
• The Performance Pyramid (part 5) – Remote Culture [TBD] I'll talk about remote working; how to manage time-zone differences, working with people from different cultures, and how to efficiently work with people from all around the world

---

About

Despite what movies and TV shows may suggest, the stereotype of the lonely engineer coding in a dark room wearing a hoodie is far from the reality of software engineering. This profession is highly collaborative and requires teamwork and communication skills similar to those of soccer players or medical professionals. A successful engineering team must be on the same page at all times, conducting with clear and effective communication. Every team member must be aware of their role and responsibilities to ensure the project's success.

This article aims to share a few things I have learned throughout my career as an engineer.

Cut the ego

The software industry doesn't need egos, any solution that gets the job done is a fine solution. Everyone should focus on pushing towards the same goal, not on who gets the credit, who gets to shine, or whose PR gets approved. The only thing that matters is getting a quality product out there.

In this article I'll share practical and actionable tips to lead engineering teams effectively. I'll share my own experiences and also reference books that have been very inspirational. This article is not just a rant about the problems in the industry, but it also provides specific solutions to fix these issues.

Again, my goal with this article is to provide the tools and strategies you need to lead your engineering team effectively and foster a culture of collaboration and teamwork that drives results.

Why should I care?

This article talks a lot about ownership, communication, and how to improve things within your team and organization so you can all achieve the best results and provide quality products to your users, but first, you should ask yourself if you really care or not. Some people don't like ownership; they see a software engineering job as a temporary gig until the next thing comes around. Maybe they are too good for their current company. Maybe they should have been working with John Carmack, but you know, life didn't give them the chance. If you are like that, please don't even bother reading this article. If you are too good for your current team, please re-think your career choices. Because software engineering is a highly collaborative profession and there's no place for misunderstood geniuses.

Remote work

I have been working remotely since before the COVID pandemic hit. After the pandemic, remote work became more common, and companies that were reliant on adopting it have come to see its benefits. But I do see that many companies do not know how to manage remote employees. This article will tackle that topic, providing step-by-step instructions on how to educate your resources into a remote work culture. I will share my experience helping companies understand the benefits, pitfalls, and challenges of remote work.

---

The performance pyramid

This is without a doubt the most important and valuable concept that I'll be sharing in this article, the "performance pyramid". This is a visual representation that helps you understand how to improve your team's performance over time by focusing on a few key areas at a time.

Communication is the most important boulder in your team's pyramid. Communication is the key to team success. I don't mean that everyone on the team has to speak fluent English. You might have an engineer from South America, Eastern Europe, or Asia who has a thick accent, but he might communicate better than a native English speaker. What I mean by communication is that your team is able to effectively and efficiently communicate ideas, problems, and solutions to each other through public channels in a transparent and honest way.

If you see a team where most of the conversations are done through DM, where engineers sweep things under the rug and don't speak up because they are afraid of opening a can of worms, that's a team that has failed to communicate effectively.

I'll share a few tips to improve communication – turning your engineers into Slack power-users, teaching your engineers how to take notes during meetings, using agenda docs to keep track of action items, how to multitask effectively, learning to mediate between egos and unblock conversations.

Ownership is the second-most important boulder in your team's pyramid. It means that engineers actually care about what they do and they care about the quality of the product they are building. This means that engineers feel accountable for the PRs they submit and that they actually perform some basic testing on the code.

A team with no ownership of their product is a team where PRs are submitted with no descriptions, no tidiness, single big-bang commits, commented code, and constant back-and-forth with QA because no engineer feels the need to do some basic testing on the code they implement, and even the most basic use case doesn't work as expected.

Tech skills, surprisingly enough, are the least important boulder in the pyramid. I've seen junior, inexperienced engineers turn into very sharp programmers. I have also seen senior engineers struggle with communication and ownership due to professional baggage.

I think it's easier to find talented engineers than to make them. I'll share some tips about how to improve your tech interviews.

Communication

I have seen many talented engineers fail because of communication issues. Sometimes they cannot communicate their ideas well, but more often than not it is because they are too insecure or anxious. Overthinking is common trait among software engineers.

I have seen engineers get stressed out over having to ping a manager, schedule a meeting, or do an @here on a Slack channel. I'd like to think that I am very loud and clear on Slack, and no one has ever slapped my wrist for hitting that @here to get people in sync. No one has ever yelled at me for trying to express my ideas or made me feel stupid for trying.

Your team will have reached effective communication when they can talk things through without a second thought. There are many steps you need to go through to achieve such a thing. That's why for this communication boulder and for every other boulder in the "Performance Pyramid", we will run a self-diagnosis test to see how well (or not) your team is doing. Based on the results of the self-diagnosis test, you will be able to make the necessary adjustments to improve your team's communication.

Self-diagnosis

I want you to underline each bullet item if it applies to your team or if you've seen this happen:

• More often than not, when you are in a meeting and someone asks a question directed at your team, no one answers until specifically pulled into the spotlight.

• People rarely communicate through public channels in Slack. You suspect that most of the conversations are done through DMs (Direct Messages).

• Sometimes people don't reply when they are directly @ pinged on Slack. Sometimes they don't even answer that same day.

• There is lack of communication between the Customer Support team and the engineering team. If someone is unhappy with the product, you rarely hear about it.

• You don't know what the rest of your engineering team is doing.

If you have underlined some of these items, you could use some help improving communication within your team.

Actionable items

Public channels over private conversations

It's important to encourage your team to communicate through public channels. If you see that many conversations are happening through Direct Messages rather than through public channels, you should ask the team to stop using Direct Messages for work-related conversations. People should be using Direct Messages only for private issues like health or time off. If people use DM as their default communication channel, that usually leads to other people missing context on things, or not being aware of how things are going. If you hold long technical discussions over DMs, and then you need to include someone else in that conversation, then you have to waste time looping that person in. Instead, if that same conversation was being held on a public channel, you could just point that person to the thread where that conversation was being discussed and that's it. Abusing DMs leads people to sweep things under the rug, or be overly cautious when speaking on a public channel.

Use the @here to communicate high-pri messages

Here are two examples of incorrect communication: (1) Do not ping the entire channel just to say hi or things like that. (2) If there's a fire, do not doubt about pinging everyone in the channel. Most often than not, engineers get anxious over-thinking if they should communicate something or not, don't overthink, just do it. No one is going to slap your wrist.

Always ping people directly

Slack (or any other communication tool) can become quite a hectic place for people who aren't used to it. People don't actively browse the Slack channels and see what is going on; they act only if pinged directly. So, if you need to communicate with someone, ping them directly on public channels.

Use threads to keep the conversation flow tidy

Let’s say that someone pings you on Slack, and you jump to the channel to see that you are 30+ messages behind in an ongoing conversation. It is going to be tricky to figure out what’s going on, and on top of that, the conversation might trail off if someone starts talking about something else in that same channel.

But! If you keep threaded conversations things might be a bit more manageable 👇

This is how that same thread looks when expanded 👇

If you don't keep the conversation flow tidy on Slack, things can get messy really quickly. Try to encourage your team to create threads for every topic they need to discuss.

• The team needs some design adjustments on a new feature? Start a thread about that in the #design channel.

• The team detected an issue and needs to re-prioritize the current work with the Product Manager? Start a thread.

• You have quite a few different ideas about how to fix an issue or implement a feature and cannot decide which to use? Start a thread in the #engineering channel.

It's also helpful to keep contextualized threaded conversations, so you can link the Slack threads to PRs, JIRA tickets, Azure tasks, Trello cards, or Monday tickets to give the people some context about what's going on or what conversation led to the fix.

Using reminders

I use Slack reminders for most of my day. If someone pings me about an issue, but I don't have time to check it right now, I'll put a reminder to check it in about an hour. If someone reaches out to me after office hours, I'll put a reminder for tomorrow morning. If I ask someone to review something, I'll set a reminder for tomorrow to check on the progress. Not just Slack, but every chat platform has some sort of "snooze" functionality, even Gmail does.

Taking notes

How often have you gotten into a Retro meeting and had no feedback to share because you couldn’t remember anything worth sharing? Keeping notes is essential. You can use whatever platform is comfortable for you. I use Notion because I feel it is quite flexible, and it does allow me to keep TODO items and notes everywhere. You can use whatever is comfortable for you, even a Google Doc.

Anything that isn't work-related; things that you would like to improve in the code base. Feedback that you would like to share with your teammates. Ideas for new features. All that should go into your TODOs, so when you have a 1:1 with someone or have a retro meeting, you'll have plenty to talk about.

Cross-team communication

I have often seen engineering teams fail to communicate with non-engineering teams. It is important to educate engineers on how to communicate with other non-engineering teams, such as designers or product managers, so they don't use technical terms and mambo-jumbo that no one understands. Instead of talking about UI widgets, talk about "screens" or "pages". Instead of talking about endpoints and API calls, just call it "fetching data" or "sending a message to the server".

More often than not, people agree or nod their heads to things they know nothing about, out of shame thinking they would look dumb or because they think everyone else already knows what is going on and don’t want to slow down the conversation. So, educate your team to bridge the gap between engineering and non-engineering team communication.