Don't Lose Productivity when Transitioning to Remote Development
3 minute read
Are you prepared to lose 120 hours a week for each development team?
As a manager, I would assume that sending development teams home for remote work, as we must right now, would still achieve productivity. After all, so many developers work remotely very easily and they seem to do well in quiet alone spaces. Of all the quarantine disruptions, this one seems minor, right?
Mmmmmm…not so minor.
Developers Need to Share Tacit Knowledge
Technical development frequently requires tacit knowledge that is shared in close verbal quarters. Coding requires unique decisions every hour - finds unique problems every hour - collaborates to solve problems every hour.
In fact, one of the reasons that mobbing gives such a productivity improvement is because innovation and collaboration are faster with everyone thinking about the same thing at the same time.
Cost of Remote Knowledge Sharing
Don’t developers live on Slack? Can’t they simply set up working meetings on Zoom and zip off difficult questions to handle on Slack? Theoretically. But that’s not how it plays out in the real world.
Consider the psychological difference between asking for written help versus leaning back to ask “hey Sue, what do you think about this code?” While informal discussion creates a shared comradery and collaboration, requesting written help feels slow, intrusive, and suggests incompetence. Thus developers will first take “a few minutes” to try to figure it out first before burdening their peers.
Let’s break down those numbers. Developers often need to discuss a quick problem a couple times per hour. Trying to solve each of those by themselves costs about 15 minutes each. That’s 16 problem explorations per person each day. We just added four hours of work per developer to their day in order to produce the same output.
While 4 hours per developer doesn’t seem like an overwhelming loss, remember that’s per day making it 20 hours per week. With 6 developers on the team, that’s 120 hours per team-week. Of course, developers don’t add those extra 4 hours a day. They just get less stuff done.
Reducing the Cost
There are two possible solutions for reducing this productivity loss. You can reduce the cost of getting each answer, or reduce the number of answers we need.
Reduce cost of getting each answer
Remote mobbing (podcast by Mob Mentality Show) can reduce the cost of getting answers that they used to easily get in the office. While this is an effective strategy to get back your productivity, you can also do more by simply reducing the number of answers they need, whether developers are remote or not.
Reduce the number of answers we need
Most team discussions exist to puzzle out difficult-to-read code. The more difficult the code is to read, the more answers they will need.
Teams that don’t need those discussions already use a powerful communication channel: the code itself. Those teams use names in the code to communicate insights and intent to the other developers.
Great names make communication work; bad names necessitate team discussions.
Getting Good Names Remotely
Traditional naming processes fail as communication deteriorates. Good names arise from team-shared metaphors and concepts. Poor names slow down remote development and remote development creates poor names.
You can improve your names without a productivity disruption. Deep Root’s Naming as a Process allows teams to use their code to incrementally develop shared concepts and names, whether remote or not. This approach allows good naming with less verbal communication.
In the wake of this difficult global disruption, you can create opportunities to actually improve productivity, decrease bugs, and clean code … all while working on the day to day code! Check out how Deep Roots provides this through a remotely facilitated mobbing workshop and series of follow-up habit shifts that are also remotely coached.