Prior to COVID-19, my organization, The City of Calgary’s Parking Authority, had no significant culture of remote work. Everyone was onsite and there had never been any discussion of remote desktop or VPN credentials. The entire software development team had to go from 100% onsite to 100% remote in a few days. Over the past few months, we have encountered a variety of challenges during that transition, particularly in how to effectively communicate with each other.
Our onsite workspace consists of desks for every member of our team arranged in an approximately four by three layout. Most smaller discussions are held at the whiteboard near our desks. Our lengthier discussions are in a typical conference room. When we moved to remote work, we lost all that infrastructure, as well as the structure those imposed. Here is how we solved the challenges that arose from that.
Problem: You don’t adapt as quickly to new teammates
When the pandemic started, our team had all shared a physical office. It was the same people we had lunch with. It was the same people we joked around with all day. However, the average person stays at a job two to three years and, over the past few months, the team has begun to change. We added a new devops engineer, and our communications manager moved on to a new job. Most significantly, the quality analyst I work with most just departed. I had been working closely with her for the past year and we had developed a natural and effective workflow and rapport.
Over time, that allowed me to make certain assumptions. She would always send me a message as soon as she found a problem with one of my tickets. If I heard nothing, the ticket was fine. If I heard nothing within the first few hours of sending a ticket to QA, it had passed.
With my new QA analyst, I sent a ticket off to her a few days ago. I did not hear anything, so I assumed that the code was meandering its way through the various test processes all the way to being approved for merge to the master branch. Instead, she had added comments to the ticket and assumed I knew because the project management tool we use sends email notifications.
This QA would sit beside me in the office normally, so there is no way that we would not have spoken for days and not casually discussed the ticket and how we organize and approach work.
Solution: You still need to have casual conversations with your co-workers. On my team, most developers have had days where besides standup, they have spoken to nobody. When you already know your co-workers and how they approach work, that is fine as they probably haven’t changed all that much since the start of the pandemic. You cannot safely transfer those assumptions to new team members, however, as people remain people, rather than the microservices that they may seem over the internet. My error was in starting to treat my interactions as though they were with a Lambda Quality Assurance function rather than the human who was a member of the QA team.
Problem: Little mistakes multiply, as nobody can jump into conversations
Many times when my quality assurance analyst and I are discussing a feature in the office, our business analyst will overhear us and interject if he hears something which is not correct. Because the team usually shares the same physical space, all conversations are essentially team ones.
When working remotely, those conversations are usually siloed away in person to person chats.
Having one large chat doesn’t work as reading through all of that is onerous, especially since it can take some time for everyone to arrive for the conversation and few people are going to read through 100 old messages. We actually tried this approach, but a lot of time was spent catching people up on prior conversations and every catch-up chat was like a game of telephone, with the message degrading every time it was repeated by someone different.
Solution: We use Microsoft Teams, which orders chats by last message (rather than Slack, which orders chats alphabetically), which means that we can create lots of specific chats with only the needed group members and when a chat is unused and thus not required for a long period, it gets out of the way and drifts towards the bottom. Because it ranks chats by when they were last used, we do not have to worry as much about organizing them. Ones which are no longer relevant just drop off the screen. If there is ever a need to resurrect a conversation or topic, all the prior information was already there.
Problem: The costs of not writing things down are higher
Until we left our workplace, we did not realize how much just sharing a physical space contributed to our group’s body of knowledge. Because of that, we originally didn’t do a lot of writing specifications or detailed documentation, as in-person clarifications were easy. Tickets representing a week of work for a developer might just have been one to two sentences.
Once we moved to remote work, the lack of detail contributed to the multiplication of little mistakes because many little clarifications did not get to everyone who needed them and our business analyst couldn’t walk by to see if a UI was coming together as he envisioned.
Solution: We started assuming that no critical decision or detail is going to make it to production without it being written down again after the meeting or chat ended. The informal chats no longer made it to everyone. For critical issues, we are keeping email threads where the latest email maintains the status of that issue. Meetings conclude with a message about what we decided and what must be achieved.
We also started writing more comprehensive tickets. A single sentence works when casual interactions are easy and available as it is possible to iteratively approach the desired result. We very much had the approach that if things were unclear, they could be sorted out later. After a few challenges, we went too far in the other direction; an overwhelming amount of detail. How we solved this is part of the next section.
Problem: But so is the cost of having a lot of written material
We had a difficult sprint when we were learning about these two problems, so we began to aggressively generate documentation, especially since the tasks for the following sprint were large and complex. We overreacted to our first few errors and created pages and pages of requirements in some cases. It is surprisingly easy to get to the point where documentation is five to ten pages long for a single ticket.
The problem is that such essays are exhausting to read and difficult to quickly discuss. Lengthy meetings ended without resolution. The quality assurance analysts were having to repeatedly go through lengthy documents line by line to make sure all the requirements were met. An hour could easily be spent scrolling through documents and moving everyone from page to page and then discovering that we needed another person to make a critical decision.
Solution: We are getting better at writing bullet point checklists rather than long paragraphs of information as well as consistently drawing sketches for what various UI components should look like. Paragraphs read nicely, but do not serve as a particularly good way to keep track of which feature elements have been finished.
Problem: Clarifying questions/solutions to problems get lost deep in chats and emails
I have heard Stack Overflow referred to as the practical documentation of the software engineering profession because it focuses on the problems that need to be solved. Starting with the problem is really the natural way people think about things, rather than skimming an index for keywords. The great thing about SO is that it takes one person to solve the problem and everyone can leverage that solution going forward.
This is a challenge for many organizations, including my own. We spend a lot of time solving the same problems and resolving the same issues because while we answered the question before, the answer is buried deep in the emails of a colleague who moved on or is lost in a chat room. We had to figure out how to solve the problem from scratch again or clarify the correct solution again.
This was another reason that the requirements documentation increased so dramatically in word count. In any organization, there are lots of little learnings that are useful to retain over time and ideally would be available in a searchable format. Those all had to be covered again.
Solution: We are creating a central document of key questions which have been answered in clarifying meetings so we do not have to keep on asking those questions. You could use Stack Overflow for Teams, which does exactly this for you.
Problem: Introverts need to be actively brought in to oral conversations
Including introverts in meetings has always been a problem, but voice calls exacerbate the challenge—even video chat has substantial deficiencies. In-person meetings allow the participants to see when someone wants to speak. Others might sit up, raise their hands, or just move their mouths slightly to indicate that they have something to say and then they are given room to speak their mind.
Voice meetings lack those subtle signals completely, so anyone who wants to speak has to find a break to speak rather than being given it. Our sprint reviews are usually voice conversations and they can easily become discussions between just two to four people rather than the five to eight who are on the call. Video chats can still have those cues to a certain extent, but that requires that the speaker be actively monitoring all the various windows, which is difficult when they are using the screen to present or have their agenda they are going through.
Solution: Our software development coordinator specifically asks key people to comment on certain features at certain times during meetings. That allows those who are not inclined to interject a speaking slot that they can either use or decline. Managing the conversation in that way lets those who are not as skilled at jumping in contribute to the conversation.
Problem: The extra communication can hurt productivity
It has long been developer etiquette to use some form of asynchronous communication to message other developers so that you avoid breaking their concentration. There is a popular comic about this that many of us would recognize. Among developers, this is not unusual. However, this behavior is less familiar to employees from other fields. Even if they know about it, it is seen as stereotypical developer introversion rather than a practical system for work.
There is also the problem of communicating priority information. A system being down requires immediate action. A missing colon? That can be added at any time to the next release. But if developers had to read the entire message to determine how important the message was and whether it needed to be attended to immediately, that would be highly disruptive.
Solution: Having some rules about what methods of communication would be used and when. We use a general team chat that is for problems only. Otherwise, we agreed that chat messages can generally be ignored until convenient. To avoid crowding the chat with large amounts of information, long essays are sent by email. Emails are never priority tasks. Unscheduled phone communication is to be avoided unless it is a serious matter.
Conclusion
While all of these new processes may seem to add a ton of structure to a previously organic process, a lot of that structure is already there, it’s just out of sight, just embedded into normal social behavior.
For example, it may seem rigid and inflexible to have people raise their hands to speak, but we already use subtle cues in body language to determine if someone has something to say anyway. The expectation of responding to those cues already exists, but instead of a raised hand, it is someone leaning forward or mouthing words in anticipation of soon speaking. This is one of just many ways in which lots of hidden communication happens in the physical office and alternatives need to be sought in the digital one.
In many ways the transition to remote communication is not a case of creating more rules, but just realizing that a set of rules always existed based in part on physical clues and contexts. Without those, the rules needed to be rebuilt.