Helping Ramp Up Teamwork

Problem

One of the things that day in, day out motivates me in my role as an EM is an opportunity to unlock hidden potential that enables the team to work well together. With a bit of my support, people who would have difficulties understanding each other or collaborating would soon be able to join their forces while working on something that goes far beyond their individual interests or goals.

For most teams, the biggest stumbling block is poor internal communication. People would mistakenly believe that they have communicated something that they haven’t. Or would fail to hear something that they should have heard. If communication is not at its best, cross-functional collaboration would inevitably suffer. Knowing how critical communication is in helping ramp up teamwork, I am dedicated to coaching my reports and budding leaders to better articulate their thoughts, listen to their peers, and level up their collaboration.

Actions taken

Articulating Better Your Thoughts in Standups

The following situation would not be uncommon in my job: I would have a new engineer joining a team with no understanding of what to say in a standup. For example, they would say, “Today, I will work on a story to add a button.” That piece of information is simply insufficient, and I would be missing critical context, which would prevent me from helping them. Therefore, I would approach them either immediately after that standup or during our next one-on-one and ask them about their past experience with standups. Based on that, I would invest a certain amount of time to help them better craft their standup updates.

For example, one of the engineers I was coaching told me that in spite of significant experience with standups, they still didn’t understand their purpose and that, in general, standups seemed like a waste of time. Indeed, I understand the need to go back and code and that standups could be interruptive n that regard. But nevertheless, I would try to explain that if they care about their work and personal growth, standup updates would be an opportunity to have other people help them out or be better matched for pair programming. I would try to sync their motivation to what I care about -- to have the team move efficiently in the right direction.

At the next standup, they would be more detailed: “I was writing some tests for the button yesterday, and today I am going to write the UI tests and will ship that off.” That would allow another person to step in, “I was writing myself UI tests the other day. If you get stuck, pair up with me”. When I would see two of them working together a few days later, I would see some tangible results of the improved collaboration.

Listening and Absorbing It All

I recently managed an engineer who was new to being a tech lead. They were great at tech, but I wanted them to focus on mentorship in their new role. As a part of their transition and expanded responsibilities, I was expecting them to catch some red flags. For example, they should be able to decipher when a junior would keep repeating day after day that they were writing tests.

Juniors tend to paddle their legs underwater furiously, which barely anyone would notice. That is why I want tech leads to be able to interpret those unuttered messages and act timely. I want to coach them to listen attentively and be able to identify problems and patterns before someone asks for help. Sometimes, juniors are hesitant to ask for help or don’t know how to go to a tech lead if they feel timid. I want tech leads to hone their listening skills, which frequently includes the ability to communicate non-verbally. For example, they should be able to tap someone on the shoulder, encourage communication or read non-verbal cues. The least they could do will be to send the junior a Slack right after the meeting: “I heard you work on tests again; I’ve just finished what I was working on. Would you like to pair up?”. How to offer help is one of the most critical skills an aspiring manager should develop. Over time I would see tech leads picking up on the signals, which would allow me to focus on other things.

Communicating Across Functions: An Lesson in Empathy

I appreciate tremendously when people with different backgrounds and expertise can come together and make the most amazing things a reality. It takes much trust to let other people with different competencies carry their part of the weight for the team. Trust blooms when people get to know each other better and are learning what other people like to do and care about. Sharing how product managers, designers, or engineers are thinking is crucial for sustainable cross-functional collaboration. Sometimes, people could end up being frustrated if they didn’t understand how each of those functions approaches the work. I would always let people vent, but I would try to encourage empathy. I would ask people on my team, “What do you think happens before a designer enters a room? What are they thinking about?” Also, I would share some additional context because I would be catching up with my product or design counterparts. For example, some designers left last week, and they were hiring extensively, so some things were falling behind because of that.

I always try to encourage people to see where changes are coming from and how they can approach things from a curious mind perspective. I would also share some tips on how to ask those questions without putting another person on the defensive. As an EM, I am aware that some of the friction is inevitable, but I want to keep conflicts at a reasonable scale.

Lessons learned

• People grow in different ways and, as a result, will be comfortable sharing updates differently. As an EM, you want to help them accelerate at the pace that works best for them, and that will push the team in the right direction. I don’t want a new engineer to share in great detail how their work is going in front of several senior engineers. Instead, I will help them craft their updates while also instilling confidence.
• People come into tech leadership from a different array of backgrounds and mindsets. “I became an engineer so that I don’t have to work with people” is not a rare attitude, which often translates into poor listening skills. I will work with those engineers to help them understand why those skills are essential and how they can utilize them. I would also help them develop empathy to be prepared to meet people where they are.
• Context is everything. At first, I didn’t have enough context and didn’t catch up with my product and design counterparts regularly; thus, I was unable to provide contextualized advice to my reports. I had to understand organizational dynamics in order to enable the team to collaborate with other functions.