Where hybrid software development remote work magic numbers come from
How are these magic number 3 days a week or 50% time being chosen for hybrid software development?
Why not 2 days a week or even 1 day every 2 weeks? Why these numbers and why risk alienating some of your workforce when remote work for all has already proven itself?
We can’t measure dev team productivity
What the pandemic proves is that we don’t really have a reliable way to measure dev team productivity. If we did then the entire remote work debate wouldn’t exist.
If productivity measures showed 2021 was the same or more productive then it would just be a matter of polling employees to find out where they want to work and being able to accomodate both remote and in office work styles.
If productivity measures showed 2021 was less productive then everyone goes back to the office - no questions asked.
But in reality software developer productivity is really about building the right thing, the right way and whether that’s been achieved won’t show up in simple measures like lines of code, task completions or meeting project deadlines.
You might have some idea of whether you are keeping up with your competition’s software but with everyone working remotely in 2021, relative productivity doesn’t prove anything.
What’s this about collaboration?
We learned this year that in person really only excels at three things: brainstorming, teaching and socializing. However, excelling is not necessarily enough to compensate for long commutes and a difficulty to focus. Even before Covid these factors were already changing the way we work, the focus problem alone was enough to kill open office.
Many blogs postulate that the in office requirements are coming from old school managers that want to physically watch their team. Certainly remote worker monitoring software is on the rise but the effectiveness of that software actually proves those old school managers have nothing to fear from remote. Additionally, some proposals for returning software developers to the office don’t even include assigned seating.
What in office requirements are really trying to enforce is availability. They exist to ensure that you can still go to another developer physically a few days a week to get your questions answered.
Without an alternative way to guarantee collaboration is happening, remote work will always be the red-headed stepchild of the working world.
What first class asynchronous collaboration looks like
When you need someone’s approval, feedback or help, you should be able to accomplish it asynchronously in a project management tool and what that person owes you should be tracked as just as important as any assigned coding.
This means completely changing the way we traditionally think about tracking code. The code’s not “done” if I’m still waiting on other people’s opinions. Having to change the code for feedback isn’t the exception, it’s the rule.
Similarly, approval for me to start on a feature isn’t something to be swept under the meeting rug. Approvals can happen at any time, their completion is tracked, and the resulting approvals recorded with full detail of by whom and how certain.
How we get there
Uclusion and others like Loom and Figma are building the first generation of asynchronous first tools. Just like the mobile first wave of innovation, the key is for consumers to stop accepting tools that don’t fit their needs.
Unfortunately, you’ll see a lot of blogs claiming traditional tools are asynchronous. If a tool doesn’t allow full communication inside of it, as opposed to being paired with a group chat offering, it’s not asynchronous. If a tool is meant to be used in conjunction with synchronous meetings then it’s a synchronous tool.
There’s going to be some confusion at first but the future of work doesn’t revolve around the water cooler.