At Arkency we’re working remotely. Being able to work remotely is just a side-effect of working asynchronously.
Let’s talk about what it means in practice.
Async means working at the time you choose and not the time, the rest of the team insists on.
Async means not being blocked on work of other people. It also means not blocking other people on your work.
Remote work doesn’t need to be async. You can still have rules about certain time of working. In that case, blocking on each other is less of a big deal. You can always interrupt others to remove blockades. As in the office.
Async is where the fun begins. Async is where productivity begins.
I sometimes hear people saying - “working remotely is not for me”. I prefer to use other words.
Async work, like remote work is a skill. You can choose to learn but you may be fine without learning it. You don’t need to have a special talent to work async/remotely. It’s about skills you can practice, it’s up to you. You control it.
Async work is actually a set of skills. One of the most important skills is overcommunication.
It’s hard to work async without overcommunication.
Actually, overcommunication is also a big term and not very precise.
At the very minimum, I want to overcommunicate to the rest of the team what I’m working on. It should be super-easy for others in the team to say - Andrzej is working on feature X.
I can do it in several ways:
- assign myself to the ticket on the (single) backlog
- keep pushing commits, so others can see which code I’m changing and what are the commits description. it’s good when the commit notifications land in the project slack channel
- mentioning on slack: “just to overcommunicate - I’m working on this tenant filtering bug”
That was the minimum.
What’s close to the maximum? When you let others to help you if your solution is wrong.
You can do it only if you present not only what you work on, but also how you’re planning to work on it. Additionally, communicating along the way, how it goes.
How can I do it?
- when I assign myself to the ticket, I can explain how I understand the scope of the task (on slack)
- I can present a possible todo list for the task. It can be on the backlog itself (like trello) or just a snippet on slack
- I can provide an estimate
- I can paste some of my code changes along the way in the slack channel
- I can communicate all I found in the existing code which is interesting in any way - existing technical debt
- create new tickets for all functional bugs I find
- documenting technical components which I’m touching now
- the scout rule is also overcommunication - fix something here, if it was easy and fast to do it. keep improving the existing area
- blog about your solution (without leaking client sensitive info, of course)
Working async doesn’t mean we force ourselves to work at different times. It’s almost always the case, that someone else is working at the same time. My team members can see my messages. They can read it but don’t have to. They can choose not to reply. They can choose to reply now or later. It’s up to them.
Some chances are that if I’m doing something stupid (and I often do), then can quickly tell me. If I’m going over the scope of the ticket they can correct me.
In our case, it’s not only project members who can help me. Also people from other teams stay interested in what is going on. They become familiar with the project (good for possible future rotations!). They can help me too. They can also learn from me, if I did something nice.
Overcommunication is like the best parts of live pairing, without the uncomfortable ones. It’s like being surrounded by friends who want to help me, if only I give them the chance to help me.
I choose to give them the chance.
We wrote a book called “Async/Remote” where you can find more about the required skills for async work, not only over-communication. Those are things like “1-size stories”, “single backlog”, “async standups”.
The book is now part of the “Smart Income for Developers” bundle. It’s a good deal. Go check it out, it’s only valid this week.