There's managing, then there's managing remotely, then there's managing asynchronously. A goal of "managing" is to serve as a liaison between your company and your direct reports, ensuring that the goals of all parties are fulfilled. It is a constant balancing act.
Managing remotely is management without physical presence. The difficulty is increased; lack of physical presence makes it more difficult to build rapport with directs. Lack of in-person communication cues can make conversations more difficult.
Managing asynchronously is managing remotely, with fewer (or no) timezone constraints. One can imagine managing a team with everyone in the same timezone. Once multiple timezones across multiple continents enter the picture, workflows which are straightforward when managing remotely no longer scale.
Many open source projects embody asynchronous work. If you have worked with such projects in the past, you will find that many of the techniques are applicable.
I have been contributing to various open source projects since 2002. I began working remotely as a software engineer in 2007, and have been managing a team of asynchronous software engineers since 2011. My current team spans 7 timezones (US Central Time through Central European Time).
When I started working out of my home office in 2007, I had one 2yo child. My second child was born shortly afterward. Working out of my home office, I have been able to be present for their childhoods, in ways that I couldn't imagine prior to 2007.
Presence should not be taken to mean that child care was my primary responsibility. Child care is still necessary and important; I was fortunate that my spouse stayed home until our youngest entered full-day kindergarten. Rather, it means that when "important" things happen, I was able to take breaks from work to help, whether that be for doctor appointments, dropping children off at childcare, or enjoying meals together.
This is where the joy of asynchronous work comes in: I always felt that I was able to re-structure "work" time. Instead of a set "9-5" work regimen, I could instead have e.g. 6-7am, 8-11am, and 12-4pm blocks. If something unexpected came up and I felt that I didn't get enough done, I could always use additional evening time.
There are never concerns about needing to be home for home contractors. I'm always home!
Many (valid!) recommendations around remote work suggest having separation between "work-life" and "home-life". These are good recommendations! It is also a recommendation I largely ignored for most of my career; the "flip side" to allowing "home life" to intervene during work time is that it then feels "normal" for work time to intervene in home life.
There is no "one size fits all". I found the flexibility to be incredibly important.
Lack of regular in-person interaction with your team takes a psychological toll on you. For your own mental health, you need to find a non-work replacement for in-person interactions. This could be a D&D group, a martial arts school, a church, a book reading group. Humans are social animals; "all online all the time" may not be healthy for you.
As a manager, you have responsibilities both to your direct reports and to the company.
You need to ensure that your direct reports have all the resources and support that they need to be their most productive selves. This includes:
Two tweets regarding burnout caught my attention:
Generally, burnout is caused by some or all of 6 things:
- Overwork
- Lack of control
- Lack of reward
- Harmful community
- Unfair treatment
- Compromised values
The vocabulary we have around burn out is insufficient.
It's often framed as too much work (which is definitely one factor), but I see it also stem from misalignment in terms of strategy or values, lack of recognition, and/or sense of belonging.
There should be some managerial control over most of these factors. Don't assign more work to your reports than can reasonably be accomplished. Sprint planning should include your direct reports; they should have input into what they do in a given time period. This also gives them a degree of control over their own work environment. You must also ensure that the work of your directs is in alignment with your companies strategy; why is this given task important? What is the “big picture“? How does everything fit together?
Have empathy for your reports (and everyone else, for that matter).
This is nigh meaningless without a counterexample; what does it mean to be empathic? Or the alternative, what does it mean to be an asshole? What should be considered "normal", and what behaviors should be avoided?
This is where sites such as Ask A Manager and r/antiwork can be illustrative, and can expose you to bizarre scenarios such as employees which get only their birthday off, meaning those born on February 29 only get a day off once every four years.
Asynchronous management requires asynchronous communication. This easily frequently includes email, GitHub PR messages and review, messages on Discord or Microsoft Teams -- so long as all involved parties agree that the communication is asynchronous! -- and more.
However, not everything can be asynchronous. Every week there should be a few periods of synchronous communication. For my team, this involves two blocks of time:
We've also culturally been having audio-only "phone calls" for over a century. Audio-only is fine and normal. It is less stressful than video. Unless there is a compelling reason for video, it should be avoided.
(Possible counterargument: you can better see non-verbal facial expressions and reactions!
Counter-counterargument: if Video in and of itself is a stress factor, how can you know for sure that the facial expressions and reactions aren't caused by video? Furthermore, if there is a strong emotional reaction, it will likely show up in their voice anyway.)
The weekly team meeting is an 1 hour audio call plus screen sharing, once every week, during which everyone on the team is present. The purpose is to get everyone on the same page: what is important, what deadlines do we have, what have we learned, what will we do as a group in broad strokes, etc. It is not a scrum meeting, where everyone says what they have done/will do.
Once per sprint, sprint planning also occurs during the weekly meeting.
Every week, have a 1:1 meeting with each direct, individually. In theory, the 1:1 is a 30 minute meeting with three parts:
- 10 minutes for them to talk about whatever they want
- 10 minutes for the manager to talk about whatever is important
- 10 minutes for Professional Development and related topics.
In practice, the 1st "talk about whatever they want" section takes most of the 30 minutes, and the 3rd Professional Development section happens quarterly-to-yearly. Don't stress too much the actual time breakdown. Additionally, the "whatever they want to talk about" is important; it need not be work-related, though it can be.
“Venting“ can be a frequent occurrence in 1:1 meetings. It is important to listen; it may also be a time to discuss fixes, but first and foremost is to listen and understand what the venting is about. There may be no fix; there may be a fix, easily offered. Don't interupt, and let the direct lead the conversation.
Calendar-wise, the meeting should only be scheduled for 30 minutes, but leave the 30 minutes after the meeting free. This is so that if the meeting goes long, you don't need to worry about going long. This also allows for you to decompress between meetings.
See also:
- http://www.manager-tools.com/manager-tools-basics
- https://www.manager-tools.com/docs/Sample-1-on-1-email.txt
- https://www.manager-tools.com/docs/Manager-Tools_One_on_One_Basics.pdf
As laid out in the previous Synchronous Techniques section, synchronous communication is ~1.5 hours every week for directs. Of an expected 32-40 (depends on country). What about the other 38.5 hours for direct reports? 😀
The remaining time may also contain other synchronous meetings, of course 😅 -- often with other teams, or for specific topics -- but the point is baseline expectations: everything that isn't synchronous may be asynchronous. Asynchronous work can be done at any time, in any timezone. Asynchronous work offers flexibility. Asynchronous work offers time and mental distance. Asynchronous work can offer less stress, depending on the personality.
Asynchronous techniques build upon asynchronous communication in order to accomplish corporate and management goals, such as:
What has your team done? What is your team doing? What will it do? What is the order? This is covered during the weekly team meeting, but…
What is the work artifact created by this meeting? Where is it stored? What does it contain?
We use an internal wiki to hold our meeting minutes. We chose a wiki because it doesn't need to be concurrently edited, doesn't need to be reviewed before it is saved, but does need to be accessible to everyone on the team.
Each week gets a separate wiki page, and each page contains the following sections:
- Links: Useful links for reference purposes; release schedules, sprint planning docs, etc.
- Vacations & National Holidays: Who on the team is taking what days off?
- Key Upcoming Dates: What dates are important? Insertion deadlines, date of the next sprint plan, etc.
- Anything else relevant to your project that suggests weekly review
For software development, there are (broadly) two sets of work product:
-
What is committed to source repositories and becomes part of a shipping product. (This assumes that “everything“ part of a shipping product is in a source repository, which may not be fully accurate, such as signing keys.) This includes “final“ feature implementations (possibly with intermediate forms), bug fixes, refactorings, cleanup, unit tests, etc.
-
Everything else. This could include artifacts which help you reach a decision or explain the decision: prototypes, design documents, user surveys, UML diagrams, sketches, etc.
Frequently, the single most important questions when digging into source code repositories are answering the interrogatives: Who was this change made for? What was the design? What was the history of the decision? Why was this change made? Why was it done in the way that it was? Were there any alternatives? How do the pieces fit together?
You may want to answer some of these questions years after the change was made. The people wanting these answers may not be the people who originally worked on the project. Original design documents may have been lost, misplaced, forgotten.
The only constant is the source repo. The only thing you can rely on is the source repo.
Consequently, if it's important, it should go in the source repo.
Where? In the commit which adds the feature/fixes the bug/makes the change. In the commit message, if nowhere else.
Preserve your history. Preserve your work. (Preserve your sanity!)
Fixing a bug which has a stack trace? The error message and stack trace should be in the commit message. Along with repro instructions (if not an actual unit test in the commit diff!). Summarize the relevant details! You may lose access to the original bug report in the future, or the original bug report may be several intermingled issues that have been split apart. Summarize!
Did a previous commit attempt to fix a similar issue but didn't actually fix it? Mention the previous commit, and why it was insufficient. (Did it overlook a corner case? Did something change “somewhere else“ in the code? Be explicit!)
Do not rely on external sources of knowledge. Referenced bugs may be memory-holed due to changing bug tracking systems. Pull requests could similarly disappear over time, e.g. a repo was created, mentions pull requests, the repo is forked, and the original repo is deleted.
A significant part of my week consists pull request review, and then editing and rewriting commit messages (via GitHub Squash and Merge) to preserve historical context. Ensure that the commit message covers all the bases. Ensure that bug fixes perform a “(minimal) root cause analysis“ so that we consider similar bugs. Ensure that the described fix actually matches what the pull request does.
Asynchronous work is oriented around asynchronous communication, which is:
- Persistent
- Searchable
- Easily Sharable
- Editable
Persistence over time is useful in reconstructing previous thought processes; "Why did we do X" is a not uncommon question, and if you can't remember you need to find and read through your various sources of asynchronous communication. Ephemeral communications such as non-recorded voice chats can't help you after the fact.
Searchable forms of communication allow you to find what you're looking for when you need it. If you can't find it, does it even exist?
Sharing the work products of communication with new team members or with peer teams may be required. Sharing will ideally include the entire context and history.
Editable is taken to mean “can be changed after originally written“.
Let's see how various forms of communication compare:
| Format | Persistent | Searchable | Sharable | Editable |
|---|---|---|---|---|
| ✅* | ✅* | ✅* | ❌ | |
| Discord Chat | ✅ | ✅* | ✅ | ❌ |
| Microsoft Teams | ✅ | ✅* | ✅* | ✅ |
| Wikis | ✅ | ✅ | ✅ | ✅ |
| Office365 Documents | ✅ | ✅* | ✅ | ✅ |
| GitHub Pull Requests | ✅ | ✅* | ✅ | ✅* |
| Git Documents | ✅ | ✅ | ✅ | ✅* |
| Commit Messages | ✅ | ✅ | ✅ | ❌ |
(Key: ✅ Yes; ❌ No; ✅* It's complicated; see below)
Email is “weird“: it's persistent, until it is archived and deleted, possibly by corporate policy. It's searchable, but email client search functionality is often terrible. Emails can be shared, but only by forwarding, and requires that you have the content in the first place. Emails, once sent, can't be edited or updated.
Email is frequently “not great“ for asynchronous communication with groups. (Thought experiement: someone new joins the team. They need information previously sent via email. How do they get it? Someone has to find and forward it, assuming it still exists to be found.) Email messages only go to specific inboxes. There is no globally consistent way to share an email with a group of people; you can only forward an email to a group of people, and what is forwarded may be incomplete. This in turn means that if you want to share relevant information to new people who don't have the email, you need to have the email in your possession first so that you can email it.
If you archive your email, or otherwise lose access to your email, you lose history. You lose memory.
Discord chat history is persistent -- unlike Slack, which can lose chat history unless you pay for it -- but the search isn't great. You can share links to specific messages, which is useful, and while a given message can be edited shortly after sending, eventually an individual message becomes readonly and can't be edited. Lack of editability is less of a concern in a chat context; you can always add more chat! (But then you may want to link together the various pieces of chat, which would require search, which isn't great.)
A problem with Discord is that there can be a cultural expectation that it is synchronous/real time, and not asynchronous. nohello is a useful construct to keep Discord and similar chat systems asynchronous, if desired.
Microsoft Teams is persistent (until the Team is deleted). Microsoft Teams search is borderline abysmal in my experience, frequently not finding things I thought was in Teams. (Maybe my memory is faulty!) Links to Posts can be easily shared, but links into chat isn't possible. Posts can be edited.
Teams chat and direct messages often operates under a cultural expectation that it is synchronous/real time, and not asynchronous. nohello is a useful construct to keep Teams chat and direct messages asynchronous, if desired.
GitHub provides wikis, and there are many other “wiki-like“ platforms. They are persistent, search is typically decent, they can be shared, and they can be edited. They typically cannot be concurrently edited. Editing is simple, which is both helpful and non-helpful; there is no "workflow" to review the changes as part of the editing process.
Microsoft Office 365 documents are persistent, and can be easily shared and edited by others. However, searching across Microsoft OneDrive often feels slow and terrible. The online editors often feel slow in comparison to desktop apps. Concurrent editing is supported.
GitHub issues and pull requests are persistent (unless and until the repo is moved or deleted). Comenting on an issue or pull request is easy, and it is often possible for repo maintainers to edit the contents of the pull request. Accessing GitHub issues and pull requests may require permission to access the repo, which can help protect secrets and slow down cross-team collaboration.
“Git Documents“ are files within a git repo. They are persistent, have version history, have associated commits and commit messages. git grep is extremely handy for searching their contents. The editing process is more involved, requiring a pull request in order to make changes to the document.
Commits can have associated commit messages. Commit messages are persistent; if you have a git checkout, you have all the commit messages! Commit messages can be searched via git log. git commit messages are implicitly shared when the underlying git repo is shared (unless using a shallow clone).
Commit messages are not editable.
Commit messages should follow some guidelines.
Many organizations opt not to put anything meaningful into the commit messages, and I consider this to be a mistake.