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

Some management books encourage people to build relationships with your teammates so you can provide better, more honest feedback. They say that if you don't connect with your teammates, you won't be able to provide feedback that they actually listen to. I disagree with this. I have tried to do that many times before, and it has never worked. No one is going to get along in a team where they have repeatedly missed deadlines, where they have repeatedly misinterpreted requirements, where communication is next to none – if you want your team to get along, first, they need to start winning.

Shrinking egos

A team's issues and dysfunction stem from egos. A successful team needs everyone, from individual contributors to the CTO, to completely humble themselves. This is no easy task; first, we need to understand why there are such big egos in the software engineering industry. I have seen that many engineers out there make programming their primary personality trait. They are the cool nerds, the savvy engineers, so even the smallest amount of criticism would make them feel personally attacked

How can we fix this problem without making it worse? Here are some ideas:

• Be humble in front of everyone. Humility is the best antidote against big egos. Ask for help. Tell everyone that you don't know what a certain topic is about. If there's a technical challenge that you need to face, make it clear that you don't know what to do. Engineers aren't a limitless knowledge repository with all the algorithms and solutions hardcoded into their brains, make this clear to everyone. People with big egos might notice this behavior and lower their defenses a little.

• Publicly thank people for their help and their work. You might think that doing things like this might inflate people's egos even more, but, on the contrary, more often than not, people's egos get inflated because they feel they don't get the recognition and praise they deserve. So they push even harder.

• Pay attention to the tone of every conversation. Even if an engineer is right about a technical decision, if they communicate their arguments in a way that is hurtful or spiteful, that needs to be addressed. Usually, having that person read out loud what they wrote during a private 1:1 meeting, is enough to make them realize their mistake. Make sure you point out that you do appreciate their passion for their jobs and the attention to detail, but that they need to be careful about how they communicate things.

Balancing opinions

Software engineering is a creative profession, and oftentimes team members will have different opinions about how to solve a problem. It is important to be mindful of how these situations are handled in order to create a positive work environment.

For example, let's say you have two engineers who have different opinions about how to solve an issue; how do you unblock this situation? First, ask if they have any technical proof to back up their arguments; many times, engineers push an idea just because they "feel" it is the right thing to do. Second, try to bring everyone back down to earth, remind everyone that we are working as a team and that sometimes we have to compromise and accept other people's ideas just as they accept ours. Third, everyone should get a vote; the best solution is whatever the engineering team accepts as a whole. Fourth, never shoot down someone else's ideas. You may have to deal with situations in which no argument is enough to convince someone about a technical decision, even when everyone else has agreed to it. In these situations, suggesting to "put a pin in it" or "revisit it later" can keep the conversation going.

Meeting etiquette

Every day, more and more companies are moving to a remote-first model. It is essential to have a policy during online meetings so they don't turn into an annoyance for everyone involved.

• Make yourself presentable. This might be a common requirement for experienced remote workers, but for most people who haven't worked remotely until the COVID pandemic, this isn't so obvious. Don't join a meeting wearing a robe. Don't join a meeting from your bed. Always keep your webcam on so other people know you're paying attention. I understand that some people are shy about turning their cameras on and having eyes on them when they speak, but if that's the case, you can just switch tabs. Switch to another tab where you don't have to look at the people in the meeting, and that's it. And please don't attend a meeting shirtless – yeah, I've seen that before.

• Filter out the noise. If you are in a noisy environment, try to invest in some noise-canceling software or a headset with built-in noise-canceling hardware.

• Use the chat section. If you feel uncomfortable about interrupting people, you can always write something in the chat section or use the "raise your hand" action.

How to encourage good traits

There is no simple answer to this. People normally do not like being told what to do, especially engineers. Ideally, you would want all members of the team to spontaneously embrace these best practices, without needing to enforce any rules, without having to guide or repeat the same thing time and again. That's not the case most of the time. Let me share some ideas that might help you see things in a different light:

The "Broken Windows" theory states that places with visible signs of crime – like loitering, vandalism, jaywalking, etc. – are more prone to crimes than places without those signs. Makes sense, right? I mean, if you go to a landfill, you are not going to look for a dumpster to throw the trash in; you are just going to toss it anywhere. The same thing goes for software, it would be unlikely that an engineer stays motivated if they see an untidy code base where no one cares where the trash goes.

The term "Bilbao Effect" was coined in response to the construction of the Guggenheim Museum in Bilbao. Subsequently, the entire region began to experience a period of growth and increased prestige. The Bilbao effect is quite different from the Broken Window theory. The Bilbao effect proposes that a tidy, pristine building can have a positive impact on the environment around it. If you're leading an engineering team, it's important to remember that showing the way is key to motivating your team. Set the example, push for clean PRs, and be clear in your communication, and your team members will follow. It won't happen overnight, so don't give up if it takes some time.

Leadership roles

Many engineers do want to pursue a leadership role at some point in their careers. It might be for good reasons. They might feel comfortable with that kind of role and want to improve their soft skills, or they might feel they are more valuable in coordinating things across different teams rather than being an individual contributor. It might also be for the wrong reasons. They think they are getting too old and it is the next step (even though a good individual contributor is as valuable as a lead) or because they like the big badge that says "lead". I'm going to share a few tips for anyone who is interested in pursuing a leadership role.

Things that a leader should never do

• Saying that something is "above your pay grade". If you are a leader, your main responsibility is to make sure you unblock your team, and that you provide everything they need to move things forward. They need to implement a feature and we are missing the design? Go and talk with the design team and figure things out. Is there a bug out there in production and we need backend engineers to help? Drag everyone into a meeting and coordinate things. Going through all the usual ceremonies; Backlog grooming, sprint planning, retros, etc. all these things can be very exhausting at times, and on top of that you might have to deal with people's egos, people dropping the ball and not doing things. If at any point doing all this you say: "This is above my paygrade" you have failed as a lead. I understand that there is a limit to everything; it is unreasonable to expect that you do everything. If that ever happens, get into a meeting with whoever you report to and try to figure out how to delegate more.

• Finger pointing. Never blame someone for something publicly. When you talk publicly, it is always "we", never "I" or "They". "We" fixed an issue. "We" dropped the ball and introduced a bug. "We" improved the app quality. For better or for worse, we are all in the same boat when we win, and when we lose.

• Badge flashing. If you ever have to say, "Do it because I'm the lead and I say so," then that's it — find another role. You're not fit to be leading people. I understand that people might be dense, and even if you convey a solid argument with proof that backs up your decision, people might still push back out of spite or sheer stupidity. But there are other ways to solve those kinds of situations. For example, getting another person involved can help you see things from a fresh perspective — maybe you are making a mistake, and you just haven't realized it yet. But never use your authority to close an argument; people will immediately lose any respect they have for you if you do that.

Things that a leader should always do

• Leading by example. If you are in a leadership role or aspire to pursue a leadership role, there are things you cannot do. You cannot submit sloppy, untidy, and barely tested Pull Requests. You cannot skip meetings. You cannot go radio silence. If someone asks you something, you need to answer. You should be an example of how all your engineers should perform. It might be exhausting at times, but that's how it is.

• Taking notes and sharing your screen. Taking notes is an important part of any meeting, but it's also essential that you fully share your screen so everyone can see what you're talking about. If you talk about goals, tasks, or milestones without sharing your screen and showing people what you are talking about, they will very likely forget about what you said or have a hard time trying to follow what you are saying. Put an agenda doc on every Google Calendar event you schedule. This will let everyone put their thoughts out and you will have a document full of actionable items when you're done with the meeting. Meetings can get quite hectic if you don't take notes. For example, let's say you schedule a meeting with your team to talk about the deadlines for a new feature that's going out. Then someone chimes in and says that there's something else they need to do before that, and someone else jumps in, and so on. If you don't keep track of what is needed to be done in a document, by the time you finish the meeting you will have more questions than answers.

• Enforce good practices. We have talked about how to diagnose problems in your team, and how to fix them, but it is the job of the leader to make sure everyone keeps up with those best practices. If someone Direct Messages you, tell them to continue that conversation on a public channel. If someone submits a sloppy Pull Request, ask them to fix it.

Letting people go

There's a limit to everything. Many leadership books suggest that you should try to be empathetic with people, connect with them, make them part of your family, etc. However, there is a limit. Sometimes people just don't care. Maybe they're going through personal issues. Maybe they don't feel fulfilled. Who knows? If you have repeatedly expressed your concerns and feedback to one of your engineers about how to improve and they continue to provide lackluster results, if they are showing no signs of improvement, then that person needs to go. It makes other engineers' jobs harder and sets a bad example when under-performers get a free pass.