Give the team what they need to thrive
Now that you’ve laid the foundation, you need to give your team what they need: A leader who listens to the engineers and to the data.
Leaders who have an ability to listen to, interpret and anticipate the team’s needs into their process are empowered to build better team culture and products. The foundations built by listening will allow you to understand what your team needs psychologically and logistically to become a high-performing engineering organization, regardless of where their office is.
SECTION TWO
It’s key to strike a balance between speaking up and staying quiet. The latter is necessary to being a good listener and offering team members the space to make suggestions and take greater ownership of their work.
“As a leader, you need to have a strong voice and you need to know when it’s time to listen,” says Amy Jen Su, co-owner of Paravis Partners. “A real conversation is a two-way dialogue; it requires both parts.”
SECTION 2.1
Lead by listening
If you’re leading remote teams now, you may have missed out on informal, and subtle, interpersonal communication that co-located leaders rely on to know when their developers’ needs aren’t being met, when they feel trepidation in their work or when things are generally not running in top form. Likewise, you may miss out on opportunities for empowered teams to thrive even more.
Listening to these issues and needs becomes doubly critical for remote work, because those teams lack coffee breaks and other informal deskside chats to raise these topics. And it’s not just listening: you need to create the space and the freedom to invite opportunities for input. It’s a true bottom-up leadership mentality, letting the team lead the leader.
Let the team lead you
John Jung, Director of Engineering at API workflow infrastructure company Nylas, adapts 1:1s to suit the needs of each developer. “Some people want more meetings and want to talk since they need support on certain things,” he says. “Some people just want to get to work again. Every person is different.”
Personalize 1:1s
Making a regular practice of asking what the team needs to succeed in their work-from-home setting creates a team environment where requesting change is accepted by all. Even when requests can’t be implemented, open communication from leaders about their attempts to integrate requests leads to a culture of greater transparency
Ask what the team needs
Teams, rather than individuals, own successes and mistakes alike. This sense of community incentivizes problem-solving over fault-finding, leading to a culture of greater curiosity and sharing. And it can extend beyond the individual development team. Adam Boswell, Director of Engineering at Kount, has his teams collaborate with the entire company. “We make sure that there are no boundaries that are off limits for communication and collaboration inside an organization,” he says. And his teams end up taking greater ownership and strengthening their resiliency, too.
Approach initiatives with a collaborative perspective
Let’s break down some basic metrics and tangible ways to get started:.
Need some examples of how metrics can empower remote teams and improve your remote team productivity?
Developers in general are a passionate group of individuals. They care about creating effective code to solve complex problems. But cumbersome structures and ineffectual practices stifle that passion. In organizations that prioritize structure over process, engineers have to dedicate more of their energy toward satisfying the framework. That leaves little bandwidth left for excellence—especially in environments freshly converted to remote work where everyone is already going through myriad changes.
Structure takes on many forms, from prescribed methodologies to rigid roles and hierarchies. Rather than emphasizing the pathway for developers to follow, you can help establish a suite of sound practices and patterns for engineers to lean on. Producing code that works relies on different methodologies, each one of which, when used appropriately, clears the way for engineers to do great work.
“All of that rolls up to an engineer who is proud of their work and who is able to produce what they feel is excellent,” says Adam Boswell, Director of Engineering at Kount. “A happy engineer always writes better code.”
SECTION 2.2
Emphasize team practices over team structure
About 29% of developers working remotely feel excluded from offline team conversations or don’t feel integrated into the company’s culture. Work-from-home, especially in distributed teams, means that team members are seldom bonding beyond work-related conversations, and their only face time is digital.
“It would be unkind to ourselves to say we can 100% replace the connectivity and connection that we had at the office,” Edwige says. “But we can do our very best to continue to stay connected.”
SECTION 2.3
Keeping team members connected also keeps them united
Here are some ways remote leaders can take extra effort to create space where team members are able to share comfortably, helping shape the direction and MO of the team:
When a team member shares frustrations or an experiment results in failure, the greatest response a leader can offer is rooted in curiosity. On the one hand, curiosity depersonalizes the situation. Questions become “I wonder what caused that frustration or failure?” rather than “Why are you frustrated, and how did you fail?” Working from home means reluctant developers can hide their unease behind digital communication, so this extra willingness to hear tough thoughts can make team members more willing to share.
Respond with curiosity
These things take time. You probably won’t see results the first time a personalized 1:1 is implemented or ask what the team needs—and that’s okay. “You need to build trust with the team by mentoring the team, having those one-on-ones with them and working with them very closely—especially when the going gets tough and when they make mistakes, so that they know that it’s okay for them to make mistakes,” Edwige Robinson, SVP of network engineering for T-Mobile’s Central region says. “In order to build that culture, you have to invest so much before.”
Practice patience
Even the most self-aware team in the most open of environments won’t always recognize every issue they have or every way they can improve. Effective data—such as team performance metrics—offers another layer of insight for leaders aiming to better understand their teams’ needs.
This information can be used in multiple ways. Leaders can layer data over what their teams are observing and feeling to see what the numbers have to contribute. Also, the data can stand alone to reveal the teams’—and the leader’s—blind spots.
According to Brenda Jin, founder and CEO of Guanyin Labs, the right data allows leaders to see the issues at hand and act much faster. “Data can help you discover the number one thing that we can influence and change today,” she says. “Companies can course correct much faster if they can isolate issues at that level."
Metrics should never be used punitively toward the team. Rather, data should work toward enriching the team’s understanding of themselves. It should serve as a tool to understand what the team is experiencing. As Brenda points out, data should be used to help leaders articulate that information in easy-to-digest terms to other stakeholders to better advocate and protect the team.
Offer data-driven insights
Looking at current release or sprint data versus data from before transitioning to remote work can clarify how that shift has impacted your teams (for better and for worse) and what help you, as a leader, can offer. Big changes in churn or in engineers helping others could mean they’re either struggling with requirements, or that engineers are supporting each other and completing each other’s work in a way that’s different than before. The right metrics can show which engineers on which teams are the largest contributors to each type of code, revealing a team’s work patterns and highlighting who needs coaching in what areas.
Comparing current releases to pre-WFH releases
Productive throughput and impact on the codebase are two metrics to evaluate the health of a team’s workflow as it moves to working remotely. Productive throughput is the amount of code after removing recent rework and churn. Measuring impact on the codebase is best described as measuring the weight or “bigness” of code changes that are happening in a way that goes beyond simplistic measurements like lines of code. It should take into consideration the complexity and usage of the code throughout the codebase. Leaders overseeing a transition to remote work should expect some change in these metrics, but nothing major or sustained. Impact can be tricky to measure without the right tools in place, but if your throughput is dropping by less than 5% per release, the team generally should be on track.
Identify changes in total product throughput
Spikes in rework can mean a few things. A team might be hitting a technical roadblock or experiencing a skills gap causing them to spend extra time on a problem they’re not sure how to solve. It can also mean there are changing requirements from business or product teams or poorly written user stories. Teams should aim to have 70-80% efficiency. A little rework is a good thing—it means they are improving code as they go. When it drops below 70%, or drops considerably below pre-WFH levels, that’s a sign that something is keeping the team from moving through work as effectively as they could.
Spotting spikes in rework or churn
Some engineers move naturally to remote work. They have more time. They’re not bogged down with in-person meetings, and they can optimize their time to code more. Others are not as good at time management and will show drop-offs in their work patterns. More than anything, analyzing these challenges can give you an opportunity to effectively coach team members on how to manage and structure their day.
Analyzing changes in employee work patterns
Anyone undergoing that transition to WFH, though, needs a clear understanding of how remote work impacts workflow efficiency, and what teams can do to improve it. Metrics make this easier. Rather than guessing what’s going wrong, passing judgement or feeling frustrated, you can identify issues and coach engineers to improve processes and work more efficiently.You can find out more on how to evaluate and smooth the transition WFH here.
“A happy engineer always writes better code.”
—Adam Boswell, Director of Engineering at Kount.
Here are some specific ways to rethink team processes and emphasize practices over structures.
People generally like the power to choose their own approaches. Think about someone gifting you a car, but they pick the model, the color and the trim. The gesture may have been generous and well-intended, but still, it took away your ability to decide. What if, instead of picking everything for you, the person giving you the car simply set a budget for you and let you pick any car on the lot? The resulting warm feeling could be appreciation or from the fancy seat warmers.
A development team feels this way when it gets to choose the tools best suited to its working styles. You as a leader may love Drive—but if your team really prefers Dropbox, and it’s actually all the same to the organization, there’s no harm in letting them make that decision. After all, they are the ones using that communication. Why not let them try out different means of communication that may improve their engagement and efficiency?
Leaders, after all, are less participants in and more facilitators of the team’s communications. And the same principles for collaborative communication apply no matter the medium.
John Ryding at Hacker Noon outlines his methods of facilitating collaborative meetings, applicable to many other more informal conversations as well. Among them are these key points that make remote communication more focused and more productive:
Test new communication paths, based on established principles
We’re all in our wheelhouse at work, if we’re doing what we love. But knowing your subject inside and out doesn’t mean you’re prepared to talk about it. Even a few minutes before each 1:1 or team Zoom call to articulate a few key points will save everyone unnecessary wheel-spinning: What is the goal of the meeting—making a decision, sharing context, collecting feedback? What steps need to happen to accomplish that goal, and how can the time be allotted to keep everyone engaged and focused on that goal? And, what are the defined action items for this discussion?
Prepare and connect your thoughts
This should happen for every conversation that doesn’t take place in person—phone calls, video conferences, you name it. Note-taking provides context and conclusion for everyone to reference later, whether or not they participated in the conversation. And rotating who takes notes in meetings spreads around the responsibility and the engagement, since notetakers are less able to contribute to the conversation itself. For more information about transparency, check out Section 3.1.
Rotate who takes notes
Cutting people off and keeping them on track feels rude. It just does. And being rude feels like the opposite of being collaborative. John points out two ways to overcome this feeling: remember the goal of the meeting, and remember the job of the facilitator. Everyone wants to get back to coding and reviewing. Everyone has made some plan for what they’ll do when the meeting ends. Everyone also wants to be heard. Keeping contributions appropriately concise and keeping the meeting on track enables team members to keep their days moving. If you are conscientiously engaging with everyone present, according to their individual needs and communication styles, the meetings create an inclusive space for a diversity of insight and contribution.
Manage the time
Adam focuses on allowing engineers to develop their way while giving them guidelines, tools and structure to be able to perform to the best of their ability within well-defined criteria for success.
“Solution architecting is not an edict,” he says. “It’s more like, ‘Here’s a bunch of Lego pieces. At the end of this, we want a dinosaur. If you want to use blue pieces or two and two instead of a four piece, go for it. Do what you want to do to create it. Go and build it how you see fit.’ That has produced some exciting results. It gives latitude to the engineers. But the idea of success is really well-defined.”
The team requires clear objectives and the correct tools to meet them. Then the engineers can engage their passion and creativity in solving how to arrive at those goals, without the impediments of rigid structure and inflexible processes. Leaders are there to help them figure out the formats that best suit their working styles and help them work more autonomously.
Hold space for creativity and focus
This idea is pretty concise. Leaders wouldn’t expect their developers to keep using an outdated version of the codebase. So why keep using an outdated structure for organizing the team?
Continuous improvement principles for software development apply equally well to an iterative approach to team process. Listening to the team’s desires and assessing performance metrics for areas of need will help identify the things that just don’t work anymore.
Experimentation is key. We could give a thousand hypotheticals of things that may not work for a team, but every team is different. Play with new ideas, toy with bending the rules that seem to constrict rather than support the team, and as a leader, be always willing to prioritize what benefits the team over structure for structure’s sake.
Bend, break and replace rules that no longer work
Asynchronous communication relies not only on team members putting everything in writing, but also on practices that keep the entire remote team on equal footing—not excluding the team members whose days begin later than others, for instance, or those who put their focused time at the beginning of the day. The stressors that asynchronous communication places on an ineffective system can be exacerbated when a distributed team spans time zones or continents.
Threads CEO Rousseau Kazi, who conceived of a tool for facilitating asynchronous communication after experiencing fragmented emails and ineffective meeting times, stresses developing best practices for asynchronous communication rather than simply trusting that putting things in writing will do the trick. These include creating clear processes and clear intentions, investing time and effort into writing that will stand up over time, and recognizing that most issues, while important, are not actually urgent—and therefore are perfectly suited to asynchronous strategies.
“Urgent communication will always be a fixture within the workplace, and products like Slack are great for it,” Rousseau says in an interview with Buffer. “However, the more remote you become, the more you need to lean into thoughtful communication. Most things aren’t urgent, but making them seem so will add a higher tax of anxiety that people who were originally co-located probably didn’t feel before.”
Buffer uses Rousseau’s principles in its own best practices for prioritizing asynchronous communication, but of course they still have meetings and other real-time communication too. Hailley Griffis, Head of Public Relations, reports that Buffer tends to use live communication for casual conversations and get-togethers (like hangouts and celebrations), truly urgent situations (not just really important ones) and relationship building (such as 1:1s).
Enable asynchronous communication (for most conversations)
These relationship-building interactions are easy to let slip when transitioning a team to remote work. Overall, connection happens on multiple levels. Remember that developers and tech leaders alike are more than walking code creators, they have needs and those needs matter. Even the most introverted among us require some amount of person-to-person interaction.Here are some suggestions for building that human side of a team:
Make space for human interactions
Having a voice conversation away from a screen offers a change of pace, as well as the connectivity of hearing each other’s voices; whether it’s a work conversation or a personal one. Bonus points for taking the call outdoors or on a walk, if possible.
Pick up the phone
Set friendly challenges
Patrick’s team members take part in activities, such as push-up challenges and baking challenges, while sharing updates with each other. “I think sharing common experiences, and facilitating that, and creating space is important,” he says.
Create social opportunities that are actually interesting.
Emmersion CTO David Adsit established a tradition of playing board games at lunch with his engineering organization. When the team went remote, they moved the board gaming to a once-a-week virtual event. It’s casual, it’s voluntary, and it’s engaging—unlike a happy hour that can feel like just an extension of the work day. Any activity that stimulates conversation and camaraderie from willing participants is naturally more effective than a prescribed water-cooler chat sesh.
Acknowledge what you lost when you went remote and aim to replace it.
This builds off of David’s board game idea. “I think that what you need to do is look at what has disappeared from your culture as you transition to online,” he says. “What were the key things that people were doing but are not doing now? Find a way to replace that.”
Section Three »
Learn to improve, and improve by learning—constantly
Introduction
section One
section two
section Three
Introduction
section One
section two
section Three