Now and again, I wonder what I’d say if I came across someone unaware of the COVID-19 pandemic. The truth is, most of us couldn’t get away from the reality of the pandemic, and the shifts it caused in how we approach work life balance. I needed a three month break away from screens.
Despite only being gone for three months, returning to work after sabbatical was daunting. But when I returned, I was lucky enough to be put on a team headed up by leaders at 8th Light who know how to ease teammates into ramping up on a project after time away from work.
Forced or not, the pandemic saw a lot of workers take a step back from work to reexamine life. Jumping back into the fold quickly isn’t easy after time away, so I’m sharing some helpful approaches and examples from my team's efforts that made a difference in helping me ramp up. They put psychological safety first and made joining a new project easy. These examples are good practice in general, and can help build more inclusive teams.
Asynchronous Communication and Documentation
Returning from sabbatical with a global remote team meant I often started working a good half day before my colleagues. Due to the attention to detail and effort put into documenting the work that was done, I was able to get the project running locally in half a day, allowing our team to start pairing and writing code as soon as my colleagues started their day.
Documentation is worth its weight in gold. Like so much of software, when you get the right level of abstraction, it isn’t a major chore — it becomes a vital part of the codebase. If done well, it is an efficient way to share context quickly. There were two things in particular that my team did that were especially helpful.
Documenting Architectural Decisions
This project introduced me to the concept of Architectural Documentation Records (ADRs), which promotes the idea that we should strive to not only add documentation as to how to install and run code, but also why the architectural decisions were made in the first place.
When you join a new team or project, it’s common to question why decisions were made a long time ago by members of the team who are not available or aren’t around anymore. This type of documentation allows developers to share the context of their decisions, the pros and cons, and build more understanding within the team.
There are some great tools that generate the documentation for you, but it’s also easy enough to create manually, especially if you’re working on a greenfield project. Architectural Documentation Records also place an emphasis on a clear and modular format of the documentation, and who doesn’t like something that is clear and concise when it comes to documentation.
Co-location
Another concept that I have noticed on prior projects has been not just adding a README.md file at the root of the project and being done with it, but also adding a docs folder to the areas of the codebase that the documents reference (also mentioned in the ADR article). I first came across it being formalized in this Kent Dodd post.
The value of co-location documentation of course depends on the size of the codebase, but in a system that is relatively large and complex, adding the docs this way makes it much easier to navigate the codebase and develop an understanding of the architecture and intentions of the team.
Co-location documentation relates nicely with good coding practices. Extracting and abstracting code is good if it makes sense to hide complex logic, or when there is a lot of repetition; but sometimes too much indirection can be difficult for someone reading the code who needs to understand it quickly, and this applies to documentation too.
Synchronous Communication
Whenever a new person joins a team, it’s inevitable that the team slows down as sharing domain and technical knowledge takes time. They need to learn the project’s domain context, and the decisions you’ve already made as a team that led to the current environment.
Some of this knowledge transfer is only possible through pairing and direct communication. It takes practice both explaining and listening to enmesh yourself with your team.
Practice Explaining
When I was first starting my coding journey, I found communicating with clients and colleagues to be a hurdle. I would write a lot of code, but not communicate the underlying concepts to others in ways they could understand or act on, or in a way that would cement the logic in mine or my team’s minds. I needed to force myself to explain my thought process more, and like any other skill, it gets better through practice. So after a break, putting yourself forward — whether it’s to colleagues, through a blog, or a presentation — to do more explaining is always a good idea.
I’ve noticed the people who do this best also do more technical reading and writing; and after a break, a great way to get back into the world of software is to re-read your favorite technical book, blog, or YouTube videos. Even writing down the concepts for yourself is a great way to cement that knowledge and get confident in sharing those concepts again.
Practice Listening
Giving someone else the space to practice explaining is also important. Delivering demos, or at least demoing what you have done, is a skill that should also be practiced. A team discussion of how to do the demo is always welcome, and allows the naturally quieter members to have an initial pass at questions and contribute if they want to.
Another great way to get to know people on a new team is to talk through code reviews. If you don't know someone or their style of communication, talking through code on a Zoom or Slack call can remove a barrier of how written words are interpreted.
Inclusivity and Psychological Safety
When I did my apprenticeship in 2016, I came across one article in particular that had an impact on me. Google’s Aristotle project covered what makes an effective team, and the biggest determinant of team success they found was psychological safety. It’s important to note that the research was specific to Google teams, but lots of other research shows this is an important attribute of successful teams too.
Google’s team found that detaching blame for any errors meant that the team all took responsibility for their failures, not just one individual. But this also meant that they all took responsibility for successes too. I’ve definitely felt the teams that were the most fun and effective to work on have all shared this psychologically safe environment. Having this level of understanding is important when building a new team or incorporating a new team member into an existing team.
I noticed two particular areas where I appreciated my team’s understanding.
Flexible Time Zones
Time zones and family setup are just a few of the reasons why team members’ availability won’t always overlap. There are challenges to remote work, and acknowledging these and being considerate of people’s non-work lives allows for more psychological safety.
Upon returning the team at 8th Light that I joined were proactive in making sure I wasn’t working overtime and recognized the boundaries of set working hours without me having to explicitly remind them. This trust and understanding in the team made everyone feel comfortable in stepping away when they needed to.
Generous Communication
Understanding that a new or returning team member might need a little more time and explanation, and being willing to spend that time, also contributes to that feeling of psychological safety.
I once joined a project that asked whether we were going to deliver on a deadline they had promised within two weeks of being there, and the negative effect on the team was clear. Another team allowed its new joiners to ease into the codebase with some buffer time to get up to speed, and they were able to contribute much faster on the project than the former, as they could spend more time getting up to speed rather than defending their abilities.
Conclusion
Software moves fast, and even though some of the frameworks evolve quickly, the fundamentals remain the same. Remembering that makes catching up on changes after a break much less daunting.
Coming back to work after three months with people who implicitly practiced the things I outlined above made the switch back relatively easy, and gave me the space to remember that I love what I do. It also cemented the idea that I want to do the same. If we spend so much time at work, why not make it a fun and safe experience for everyone — especially if they’re coming back to it after a bit of a break.
