Let’s be real, 100% work from home in the middle of a pandemic is indeed a unique challenge for mobile engineering leaders and builders, but you are up to that challenge. Beginning today and in the weeks to come we’ll be sharing tips and resources for managing remote software development.
5 tips and resources that helped as we became a remote-first org:
- Establish a operating cadence for remote work
- Document relevant 1:1 conversations for wider consumption
- Create a system for devs to interrupt other devs to preserve velocity
- Value outcomes over activity
- Use potential downtime to reduce tech debt by refactoring legacy code
Managing chaotic times
It has been a week unlike any other in recent memory.
From all of us at Touchlab, we sincerely wish that you, your family and colleagues remain safe and healthy. Thank you for doing your part to curb this virus and its devastating impact.
For the health and safety of our team and our clients, we decided to go fully WFH mid-last week. We’ve been remote-first for some time now, so our transition to this new world has been easier. That said, we know some of you are struggling a bit as you move to this new way of working for the first time. Even those of us who have been remote first for some time are dealing with mental health issues, pandemic-related stress, and lack of productivity. Please know you’re not alone and it’s ok.
In an effort to be helpful, beginning today and in the weeks to come we’ll be sharing tips and resources for managing remote software development. We’ll share what’s worked well for us, what techniques we left behind due to poor outcomes, and tips from folks in the community.
One last thing. To all our friends leading and building digital products teams through this time, It’s clear we’re living in a challenging moment but please allow us to share a little hope.
The world needs you today, more than ever. The mobile product you’re working on fills a physical, emotional, or social need for someone out there in this time of uncertainty and isolation. Let’s be real, 100% work from home in the middle of a pandemic, while juggling kids at home, partners hogging the wifi, worrying about loved ones, or any one of a million other things, is indeed a unique challenge for mobile engineering leaders and builders, but you are up to that challenge. In fact, you and your team are absolutely brilliant at solving hard problems, it’s what you thrive on.
“There is no substitute for attentive repetition.” – Daniel Coyle
We personally like Zapier Co-founder & CEO Wade Foster’s approach to ‘building an operating cadence with remote teams’. He has invested a lot of time speaking about the subject and collected plenty of ideas for engineering managers transitioning to remote work in a hurry.
Illustrative example of Zapier’s cadence
- Weekly staff meetings
- Schedule the automated sharing of a template weekly doc. Remind everyone to fill out their section.
- Managers post Green (these issues are smooth sailing), Yellow (these are tough issues) and Red topics (issues that need to be addressed ASAP)
- Teams comment on the doc a day before
- Summarize Reds and Yellows
- Weekly staff meeting begins
- Follow up on previous week action items
- Focus on Reds and Yellows
- Log action items
- Post meeting follow up
- Collect feedback via Slack
- Out of time Slack threads
2. Paper trail
Good documentation is critical in remote software dev. There is too much value and ingenuity in 1:1 remote conversations to NOT put them down on paper for the benefit of the entire team and project.
Justin (Touchlab Dir. Project Strategy) writes, “Discussions in the office can be overheard and it’s welcomed for people to join in or make a mental note. Remote conversations are closed doors so anything that should be shared should be written down in an organized way.
Keep in mind that it’s easy for information to get lost in the noise of real-time chat solutions like Slack. These tools are like water coolers covered in post-it notes — yes, the information is persisted, but not organized and not easily discoverable by people who weren’t part of the discussion.”
Create a system where the default is for project conversations to be documented and communicated. If a conversation is meant to be ‘closed door’, team members have the option to opt out of the default and keep information private.
3. Welcomed interruptions
Tip # 3 again focuses on minimizing the negative impact of less in-person activity. In short, we’re advocating for developers to get interrupted more during the day. Let us explain…
Justin (Touchlab Dir. Project Strategy) writes,
“…Many developers are comfortable turning to their neighbor and asking “have you seen this error before” or “how’d you get that thing to work last time”, but don’t feel comfortable sending the same message over text chat, and even less comfortable opening an ad-hoc video chat.
Managers need to beware of rabbit holes and self-figuring-out that could be avoided by having a chat. Agree on a policy for interrupting and actively work on the culture so people will be OK with the kinds of interruptions agreed on.
When people are wearing headphones in the same office, it’s very close to being remote, especially during times of focus when people walking around is less distracting. But taking off the headphones is different.
Be sure there is a place to go — public chat room, shared video channel, or individual status message indicating interruptions welcomed — to have that social, non-focus time.”
Sam (Touchlab Engineering Manager) adds, “There has to be zero friction to start a conversation. You don’t even have to know what you want to say before you press the call button.”
4. Outcomes > activity
100% WFH shifts the goal posts for productivity. Metrics to measure productivity when everyone is in the office should be revisited and adjusted based on your organization’s near-term WFH goals.
Also consider that trust takes on a new meaning in a 100% WFH environment.
Consider early on how to measure productivity by outcomes rather than activity.
5. Look inward
“There’s water in the flowers, let’s grow.” – Mac Miller
Generally speaking, there are two possibilities for mobile teams during COVID-19. Both scenarios require orgs to wait and see how the pandemic plays out. On top of it all, the loss of in-office collaboration is an additional constraint.
Scenario 1: continue building and releasing new features to better serve users
Scenario 2: with too much uncertainty around your product’s short-term future you turn inward and improve operational efficiency
While we’re hearing a mixture of responses to COVID-19 from our client partners, we anticipate that the short-term for many teams may look like Scenario 2.
Here’s how we’re responding to clients asking about maximizing output during downtime:
- Reduce debt tech & refactor legacy code
- Make it incremental – work on one feature or architectural layer at a time to minimize your commitment and risk.
- Consider a separate work stream by a dedicated team. It’s possible that your team will have extra cycles under Scenario 2, so consider assigning team members to a scope of work with defined measurable outcomes to foster accountability and collaboration. Define the timeframe and stick to it!
- Divergence between Android and iOS platforms places stress on architecture. Consider exploring solutions that reduce divergence. Kotlin Multiplatform can help.
- Lastly, it’s easier to refactor existing code remotely. There’s plenty of scope negotiation and in-person collaboration that takes place when building new features. Those pressures aren’t there when working with existing code. And plus…refactoring prepares you to accelerate once the downturn subsides.
We know you and your team are managing a lot professionally and personally. We wish you, your families and colleagues a healthy and safe next couple of weeks.