Aaron is one of our Engineering Team Leads at Wrk. He has spent over 4 years working in different remote-first companies and also completed a master's degree online during the COVID-19 pandemic. In this post, he shares some of the tricks he's learned from his time managing, building, and learning in the remote world.
Default to asynchronous communication
We all love meetings, right? Meetings, voice calls, and video chats are all examples of "synchronous" communication, meaning that you're actively engaged in a conversation. Conversely, emails, Slack messages, and anything that doesn't require an immediate reply are examples of "asynchronous" communication.
When you want to talk to a co-worker, which should you use? Should you write them an email, send them a Slack, schedule a meeting, or give them a quick call? One huge advantage of asynchronous communication is it gives the receiver control over how and when they receive it. Everyone needs focus time to do the work that actually provides value to the organization and the tools we use give us control over our attention. Software developers use this well—we do our best work deep in focus and it often takes more than half an hour to recover from a single interruption.
At Wrk, we default to asynchronous communication and move to synchronous conversations as needed. This gives every team member control over their day and allows them to do their best work on their own terms.
Overcommunicate
In an office environment, knowledge has a habit of spreading naturally. Serendipitous encounters between employees and a general habit of chatting informally means that everyone has at least a little bit of an idea what other teams are up to. In a remote-first team, we need to do this actively.
At Wrk, we have a philosophy of "overcommunication." This means that we actively share more than we think we need to. Our favourite way to overcommunicate is to constantly push out the context behind why work is being done so everyone understands the value of their contributions. We have weekly all-hands meetings where each department explains what they're up to and why it's valuable. In my team meetings, when I explain what we have to do, I also explain why it should be done. This often means I get into business strategy in engineering meetings. Unnecessary? Maybe. Valuable? Yes. That's overcommunication.
Move around
We have four teams within our Engineering department. Each team builds and runs their services independently. One of the most important things to us in engineering leadership is the happiness and career development of our developers. We have a direct interest in keeping them happy and making them better! One of the more uncommon strategies we use to achieve this is to encourage people to switch teams. If developers want to get familiar with other systems, work with different technologies, or get to know other developers, we actively encourage them to hop onto another team.
Recently, I did this myself. Originally, I led the "Engine" team, an Engineering team that provides the pipeline through which jobs flow. Now, I lead the "Automation" team, another Engineering team that enables bots to do jobs on our platform. This benefits me because I keep myself fresh by working on new types of problems. It benefits the organization because I join the Automation team with a fresh perspective and deep technical knowledge of the Engine team's systems.
Retrospectives
The strategy I use that has made the most positive impact on my teams is the humble retrospective. This takes the form of a quick meeting every 2 weeks where we answer these three questions:
- What's working?
- What isn't working?
- How can we improve?
This meeting is so valuable because it causes an iterative approach to improvement. First, identify things to improve. Second, improve them. Third, repeat forever. You don't have to predict the future, you keep your team lean, and your team members know you're committed to improving their working environment.
This is even more valuable in a remote, distributed environment. Employees work in different locations, often in different time zones, and the experience of working at your company is more variable than it would be if everyone was in the same office at the same time every day.
Committing to an iterative improvement process like this is an admission that I don't know everything and that I can't possibly predict the future. The best thing for me to do is commit that I will always listen and constantly improve.
Thriving in a remote-first work environment
Remote work has posed many challenges for teams, but not all of them are unique. All of these strategies can be applied to in-person teams just as well as remote teams. The difference in a remote team is that we have to be proactive. Teams can easily become siloed, leaders can lose visibility, and our productivity can slip through our fingers. The reasons we adopted a remote-first model are many and we try to take advantage of all the flexibility it offers us. These four strategies are just a few of the ways we bring out the best in our teams in a fully remote work environment.
Would you like to learn more about our Wrk culture or join our team? Visit our Careers page.
Featured Image: Chris Montgomery
