Going beyond productivity tools to empower your remote engineering team

Many engineering leaders today place a heavy focus on lining up the right suite of tools to maximize their team’s productivity.

After all, the installation of business and productivity apps increased by 35% in 2020. At Lantern, a tech startup that aims to guide people and their family members through end-of-life planning, I run an all-remote engineering team as the Technical Lead. While we leverage our fair share of productivity tools, I also make it a point to bolster our teamwork with a few key practices I’ve learned over my years of leading hybrid and distributed teams.

Don’t be afraid of asynchronous communication

The first I want to highlight is something that I had been doing intuitively for years, without knowing it was a “thing”—asynchronous communication. Basically, not everything has to be a meeting.

Asynchronous communication encompasses all kinds of practices and techniques that help us communicate with our colleagues on different schedules or time zones, especially when there’s a time lag between you sending the information and it being received (or vice versa).

In a startup environment, we all wear so many hats and everything moves so fast that it’s really tricky to remember all the solutions you covered the month prior. In a remote environment, you can’t just go up to their desk and ask them about it.

The practice of asynchronous communication helps to smooth over the time lag. This means writing super-clear documentation, using project management software properly, and agreeing on common conventions and channels for communication. That way everyone can reference the key information on a given topic. I’ve found this kind of careful use of written communication to be very important. There’s also, Loom, a handy screen-recording tool that lets you present to your teammates without necessitating an entire meeting.

Acknowledge the human side of work and lead with compassion

A team isn’t the same as a family, but at the end of the day, people aren’t robots. We’re humans with problems and challenges as well as joys, loves, and laughs. You have to include it all when you’re leading a remote team that’s moving fast.

Particularly during a challenging time—as it has been during Covid-19—there’s a tendency to downplay difficulties or stay positive: “Everything will be okay!”

I always try to just admit it when we’re experiencing something difficult on the team or in the world. There’s a lot more breathing room once you give validation to that struggle. I feel we’ve done a good job of doing that at Lantern. We make it a point to give people the space if they need it and encourage them to take a break.

Leading with compassion is especially applicable when it comes to my one-on-ones with my team. I’ve noticed that, when working fully remotely, those little “water cooler” chats you may have with people to really get to know them—their hobbies and favorite TV shows—no longer happen.

So I started weaving them into my one-on-ones, asking people softer questions to get to know them. Just asking what they have planned for the weekend or what they’re reading at the minute.

People noticed.

Many engineers previously had very procedural one-on-ones where they ticked things off a list. They could feel that I was genuinely trying to get to know them and the feedback I received on this practice was really positive. I love the human part of my job. Those relationships I have with my colleagues are one of my most powerful motivations. It’s helped me so much in my career and I don’t want to lose that. So always prioritize the team’s sense of humanity.

It’s time to revolutionize the idea of deadlines

I’d like to start with an #UnpopularOpinion: I am fundamentally against deadlines.

It feels absurd to apply a time expectation, whether it’s six hours or a day, to an engineering task. That’s just not how engineers work. So many factors come into play, such as the codebase, the engineer’s familiarity with the nature of the task, and so much more. There needs to be flexibility baked into a goal “due date.”

That being said, when I do need to hit a tight deadline my golden rule is to utilize heavy prioritization and rigorous de-scoping.

By prioritization I mean focusing first and foremost on aspects of the project that are critical to the problem we’re trying to address. By de-scoping I’m referring to eliminating those many deliverables that have snuck into the brief but that are not critical to the core functionality of the application.

Both essentially entail asking the question: Why do we need this?

If you don’t do this something your team will get is “scope creep.” The remit of your project grows and grows, one tiny little addition at a time. People just want to add this little feature here or there until all of a sudden you’re trying to build tons of new features within the originally allotted time frame.

That’s why I’m constantly poking holes in the requests we get to figure out the smallest version of a feature or project that we can do. This way we’re always working in small, iterative chunks instead of trying to release massive bits of code as fast as possible, which leads to sloppy and messy code.

It’s okay to say “no” a lot

Another facet of working with deadlines is to always ensure that, before we do anything else, we clearly define the problem. By doing so, we can come up with a solution for the actual root issue, not what appears to be the issue.

If someone notices that people aren’t sharing photos on our app very often they may immediately jump to some solution. “Let’s quickly add a new sharing feature,” they might suggest.

But I always step in to say: “Hold up! What’s the actual problem here that we’re dealing with?”

Is the problem with sharing the photo? Or uploading it? The quality of the photos? Can the user navigate the sharing process easily?

Defining the problem really helps with addressing scope creep. Then we can figure out how to get as close to the required functionality as possible without investing too much time or money. At the end of the day, we just don’t have Google’s budget.

The learning never stops

I’ve learned so much about leading a remote team through my work here at Lantern. With our core team scattered across the US and our embedded Andela engineer working from Africa, there’s new progress made every day with our teamwork.

Despite the disruption of the pandemic, a lot of really good practices have come out of it from a technological perspective. There are all sorts of great tools, techniques, and processes emerging today that help us navigate these new, partly- or fully-remote ways of working. It’s a great time to lead a remote engineering team.

Ready to scale your team?

Discover Talent