How to succeed as a first-time remote engineering leader - part 2

Last week I wrote about what I believe is the most important aspect of being a new engineering manager for a team: building trust by nurturing connections. Getting intentional about this is more important for a remote leader, because there are less accidental opportunities to create the social foundation of efficient collaboration. If you’ve missed that article, you can read it here.

This week I want to give a few advice on other aspects of being a first-time remote engineering leader, focusing on execution management, communication and team health. But before getting into that, it’s important to be a bit more specific about what being remote means exactly. “Being remote” can mean a lot of different things, and your approach should be different based on these details. I find it useful to not just talk about remoteness, but actually two aspects of where work happens, in time and space:

• Work distribution in space, the colocated / remote axis: How much work is happening at the same physical place? Usually it’s not black or white, a lot of companies are doing some flavour of hybrid: either having a part of the staff working fully remote, or requiring a few days per week in the office.
• Work distribution in time, the sync / async axis: How much work is happening at the same time? Similarly to space distribution, it’s a scale: some teams have processes optimized for asynchronous collaboration, others have a lot of aligned ceremonies — not just meetings necessarily, but presentations, slack “open hours”, etc.

In my experience, companies are much more prescriptive about the “space” aspect, and less intentional or explicit in the “time” one. Still, it’s important to be able to mentally plot your new organizational culture in the above chart, because this will help you decide where and how to focus your efforts.

So this is my advice: understand where the company culture you’re stepping into is on the collaboration space/time chart. As most companies are somewhere in-between, it can be tricky to find this out for a newcomer. Spend some time discovering not just the policies, but the behaviours of people too. For example: if teams hold regular live sprint review meetings, but participation is low, and most of the back-and-forth is happening in their Google Docs or Confluence reports in comment threads, then this points to a more async culture.

Considering that this article is about remote leadership, I’m won’t go into colocated teams, but rather focus on how to optimize remote work in sync and async cultures.

Remote leadership in a synchronous company culture

Because a lot of things happen in meetings, optimizing how they are run can bring a lot of benefits. Make sure all calls are remote-friendly even if part of the team is joining from an office, to ensure remote folks can fully participate, and you can avoid the risk of missing their voice. It will require active moderation of the discussion, call-outs, intentional grouping in break-out sessions, etc.

If the team is scattered across different timezones, ensure you’re using the overlap of work hours the best: schedule most team meetings, even standups for this time of the day. Avoid the temptation of multiplying meeting, for example, having an EU and US standup separately. You need to keep the team together to ensure alignment and collaboration with no communication overhead.

I believe that all meetings should have a purpose, but I don’t think only meetings with strongly enforced agendas can serve that. To decrease the feeling of isolation in remote work, consider setting up less structured calls too. During the beginning of Covid, I’ve experimented with optional “coffee chat calls” in the morning to help bonding and team health, and while not everyone joined these all the time, it improved morale and overall effectiveness.

Pair- and mob-programming sessions can improve knowledge sharing, code quality, team bonding, skill development (both technical and mentorship ones), even accountability and the feeling of ownership. The positive effect is there on virtual sessions too. You can set up a dedicated time-slot for these during the week, so the option is there to encourage people scheduling a session of pair-work even last minute.

Since so many things are happening in pre-determined times, put efforts into increasing the amount of unfragmented focus time for the team. The goal is to minimize context switching and allow deep mental work. Avoid 30/60-minute “holes” between calls, and experiment with no-meeting days. Once set up, you should also respect these, to ensure that you display the behaviour you want to see in the team. Don’t be tempted to make a call on no-meeting days saying “I know we shouldn’t but I haven’t found another timeslot”. Show up on time for calls and don’t let them run over. This discipline helps bringing predictability and control to the team’s days, which is a small step to help preventing burnout.

Turn on your camera on calls, and encourage others to do so too. This way you can ensure the non-verbal part of your communication is also going through, which will help comprehension. You also show transparency and encourage engagement if you have your camera on. Please don’t make this obligatory though: Not everyone feels comfortable all the time sharing their surroundings. If you see it as a tendency with someone, once you have their trust, during a safe one-on-one discussion, ask why they feel they need to be video-muted. Either way, I found that engagement, motivation and therefore the level of participation on a call is correlated with the amount of visible participants. So if you see a lot of invisible people, dig into understanding their reasons, and figure out what you can change in the environment to make participation more encouraging.

Meetings are an important part of synchronous culture, so embrace them. If you receive unclear feedback from a stakeholder, want to challenge a peer, or need clarification from someone on the team, ask to jump on a quick ad-hoc call instead of getting into long written back-and-forth. Your message will be faster, more efficient and harder to misinterpret.

Ensure that status reports and sprint reviews are not a one-way read-out of team execution progress, but a platform for real discussions. Invite key stakeholders, send out a short pre-read highlighting potentially controversial topics, and encourage discussing the hard questions during the call, or offer a follow-up call if needed. You need to have these out and argued about, to ensure a shared understanding of progress and alignment in goals. Red flags to look out for: low participation in review presentation calls, people routinely missing it saying “I’ll watch the recording”, or lengthy written back and forth in comments and emails. If you spot these, work on improving the environment to encourage people to join on the call instead.

Finally, some tooling tips to make sync / remote work more efficient:

• Google Calendar: Set up speedy meetings to ensure there are small breaks between consecutive calls. Open your calendar to increase transparency and trust — you can keep sensitive meetings private. Use Out of Office and Focus Time event types properly, so people know your availability. If your team spans across continents, set up your calendar to display their time zone too.
• Note-taking is important in a synchronous culture to help alignment and accountability. On group calls, have a dedicated note-taker (separate from the animator of the meeting), on one-on-ones, capture the topics discussed yourself. Share these after the call with participants, and make them open to the company if it makes sense. This implies alignment and gives a chance to discuss in case there were misunderstandings. The Google Docs integration in Calendar, or the 1:1 features of Small Improvements are two great tools that facilitate efficient note-taking.
• Make focus time count: mute notifications or simply quit Slack / Teams / email when you need to concentrate. Set a status message if the platform allows it, to communicate clearly that you’re in focus mode, when will you be back, and how you can be reached in case of emergencies. By displaying this behaviour, you encourage others in the team too to feel free taking similar actions when needed.

Remote leadership in an async company culture

Some of the tips from above can be applied to async too, and considering that most companies are towards the synchronous end of the scale (and that I also have more experience there), I’ll just list a few differences and additional ideas.

Ensure your team has efficient async-friendly processes. Consider embracing an RFC-based decision-making culture, where focused feedback can be gathered without the need to have everyone on a call. Record decisions in a pre-agreed template, circulate and store them together with code and documentation, so they can be found and updates can be tracked and versioned. Simplify these processes to the size of the organization to ensure they are efficiently helping alignment and feedback, and not just increasing bureaucracy.

Counterintuitively, async means more communication, not less. Get your team into the habit of working in the open: sharing what they plan to do / are doing / have just been done on an internal chat room. Summarize and share these regularly on your team’s outward-facing channel, or consider running an internal blog, so stakeholders and interested peers can stay up-to-date and give feedback.

Learn how to communicate efficiently in writing, and coach your team members too. Review what you write before publishing, edit, cut, structure. Messages should be short, to the point and hard to misinterpret. Have your audience in mind, optimize for their reading experience, even if it means more time spent writing.

Not everything needs to be written though. Experiment with video updates and recorded presentations that people can watch in their own time. Encourage everyone on the team to create demos of their work: this helps making updates easier to follow, and by showing the impact of delivery, you can help increasing the feeling of purpose within the team, which is a great motivator.

Even extremely async companies have events that require coordination and live presence. Production incidents, urgent requests from another team, external events and similar unplanned happenings that need your team’s immediate attention can be disruptive. Consider setting up a rotating “firefighter” role that handles these requests, and therefore protect the rest of your team from interrupts so they can better focus. Make sure that knowledge transfer happens at the rotation: incorporate firefighter’s report into standups, and consider a written log too, especially in the case of incidents.

Because you can rely less on pair-working and in-person feedback, spend time perfecting your code review processes. Ensure people are blocked for the shortest amount of time, both by prioritizing reviews over writing code, and by encouraging frequent, small changes. Build a healthy, supportive feedback culture in code reviews: praise good behaviour publicly, address bad examples on one-on-ones.

I think daily standups are not just for reporting on progress and asking for help, but also for surfacing potential misalignments and helping team bonding, so I’m a bit sceptical about the efficiency of async stadups. If you implement them, ensure that everyone is following closely what others write, and encourage discussions sparkling from the updates. You should participate in these too to the same extent as your team, and share what you’re working on and how the team can support you even, if you feel that they don’t have all the context. (Especially if they don’t have all the context!) This participation helps accountability and alignment — and builds trust and camaraderie.

I hope these advices will help in your first remote leadership job. I didn’t cover a lot of important areas from hiring, through planning, development, feedback and performance management, to team- and personal health, etc. Partially because I wanted to keep this article focusing on the initial challenges, but also because I believe these topics justify separate articles, as a lot of the lessons there can be applied to both remote and colocated setups. I’ll get to most of them eventually — if you want to get notified about new articles, sign up for my newsletter.