Working from home as a software developer/engineer, what will it be in a few years time? Which things became fundamentally different already, and which will change history? What if we never come back to norm? Let’s embrace the new situation rather than planning a come back. For this to happen certain habits need to be dropped, and other habits need be developed instead.

• Asynchronous communication
• Workflows built around code
• Output vs hours worked
• Hiring A players
• Buy Equipment
• Complex Tasks First
• Encourage Opinion
• Meaning of Leadership

Asynchronous communication

Asynchronous communication is a secret to productivity when working from home. No chats, no on-demand help for those help vampires. For any technical help, prefer written communication, often people do not understand, so you can refer to your earlier message. It helps a lot if you don’t have to remember what you said or someone else said or did not say. But don’t use emails either. Book meetings for in-person communication, with a minimum of 1 hour notice. Advance notice helps avoid developer burnout due to context switch.

Workflows built around code

Use systems built around code, for code reviews, code quality analysis etc. Let developers drive development. It is crucial to be able to comment on code which is not necessarily in PR, just any random code, able to create tickets/bugs from those discussions etc. Business needs to understand that developer does knowledge work, and efficiency is a factor of quality. With enough good code, they can make a business wish come true in a snap.

Output vs hours worked

10 hour days is a road to failure when it comes to knowledge work. It is time to drop that old habit of treating developers as food chain or factory operators.

I am proposing strict work hours ethics, never working longer hours, evenings or weekends. 8 hours is more than enough to be productive. Get your work done early - turn off your laptop and enjoy the rest of your day. Paid for 8 hours - yes, get used to this new reality. If you get your output, hours should not matter.

Number of bugs resolved per day does not equate productivity. Neither is the number of features / stories implemented. Instead, we need to use software that measures output, this makes the process objective and repeatable. It should provide as many fact-based metrics as possible.

Output is about writing code and not coming back to it, ever (cause it works). If some code is being fixed 15 times and still has bugs, it means a lot of inefficiencies in the process. Another part is adding comments when reviewing PRs. Speaking of PRs, the time between publishing a PR and when it’s merged is also important. As is the time it takes for the author to reply to those PR comments. Basically, any interaction delay is inversely correlated with productivity at scale. Waiting for QA approval for a few days? One of the issues that needs fixing.

In some extreme cases, if it takes a month to merge 10 lines of code, there is something wrong with productivity, even if all timesheets are submitted on time. Forget about logging time. Start logging what was done, and let software decide if it was fast / good enough etc. This encourages rest time, and increases quality of decisions per unit of time.

Hiring A players

It is crucial to be in the mindset of hiring experienced A/A+ players, who can self-direct. Is that code crap? Is this worth fixing? If developers don’t care about good code or bad code, or they consistently make the same mistakes - don’t hire them. If they think high of themselves, but every one of their lines needs refactor, think twice before giving them more work.

Very typical for A players is to excel at academic studies, so they might have graduated cum laude with a Bachelor’s or Master’s degree. Of course, there are plenty of A players outside of the typical university track. However, there is one thing for sure - if you see a degree without any other recognition (participation in university contests, dean’s list and so on), there is a 99% chance you are seeing a profile of a C player. Be careful when hiring them for remote. They will only work hard enough not to get fired. And you as an A player will be fixing all their code after them.

Encourage continuous learning, but monitor for productive outcome. It can take shape of a professional certification, proctored on-site or online exam, public recognition such as Stack Overflow profile, Microsoft MVP profile, record of participation in developer conferences.

Another idea on the same note - promote working in open source projects. Trying to understand someone else’s code improves your own cognitive ability. Especially so with code you’ve never seen. Also big companies typically write code in a very particular way, so it helps to see the world outside the box.

Buy Equipment

Having the best equipment at home, including but not limited to network/infrastructure. Fast internet >100Mbps is a must have. Gaming mouse, mechanical keyboard, Steelcase Leap or Aeron chair. For employees, let them buy what they want. Considering modern software developer’s salary, a few thousand dollars do not make a big difference. The will appreciate it more than some ping pong tables and that fancy coffee machine at the office. Or bagel Tuesdays.

Complex Tasks First

Promote for jumping on complex tasks, not for taking simple tasks fast. Make people choose complex tasks because they want to, not because there are no simple tasks. This leads to improved effectiveness. Doing something 2 times better/faster is nothing if we all doing the wrong thing. There could be 100 simple bugs to be fixed, each taking 1 hour, and 1 complex bug spanning a day or two, but fixing it eliminates the need to fix 100 other bugs. This is a real production situation from multiple companies on my resume, big or small.

Encourage Opinion

Promote opinion and write it down. Do not just write down good ideas, or that of a tech lead / architect. Good is subjective and changes over time. Every opinion can end up being useful in a few months/years. So make sure you remember what that one guy said a few month ago, when everyone thought he was wrong.

It might turn out that a handful of people with no position of power would be more suited to serve in architecture council, because their solutions work now and continue to work year after year, while all other code gets a complete rewrite. This goes back to Workflows built around code section.

Meaning of Leadership

Leadership is opposite of micromanagement. Typical examples of micromanagement are logging time (sometimes at 15 minute intervals), taking screenshots from developer’s laptop every 5min, having regular meetings, throwing unimportant chat messages to see who is available / will respond. Pinging people and expecting a reply in 1-2 minutes, and yelling at them if they only reply in 5. Yelling means asking “are you there” and similar, without giving a person sufficient time to come back from the washroom or a tea/coffee break at home. None of this management activity is productive use of time. It only speeds up burnout and increases employee churn.

What should you do? Leadership is direction. This is how you tell who should be the leader. Some are correct now, but wrong later. Others seem to be wrong now, but end up correct with time. Find the direction, stick with it, help people understand it and help them on the way there. Encourage everyone to be a leader on the team. Delegate your power. Make everyone important. At times, leave nothing to yourself. This is called true leadership. And this is how great companies are born. Such philosophy is not exactly new. The world’s situation just gave everyone another chance to understand the true value of things. Except this time, winning isn’t a choice, it’s survival.