Excelling In A Post-Pandemic World — An Architect View

The COVID-19 pandemic has changed almost every industry,

• Restaurant (Cloud kitchens on the menu for most restaurants)
• Healthcare (Remote consultation is the new norm)
• Education (Online and remote learning here to stay)
• Software (Remote working is here to stay)

There are winners and losers in each of these industries. Some are struggling, some are surviving, some are thriving, and some are even excelling. In this blog, I will focus on the software industry.

Like Moore’s law for the chip industry, Conway’s law stayed relevant even today for the software industry since 1967.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. — Melvin E. Conway

If your software consists of a tightly coupled module, maybe now is the right time to review the org setup and communication pattern. 😉

In the above picture, I took an initial stab at capturing few indicators from various companies within software industry, that separate the ones who are surviving during this pandemic from those who are excelling in the new environment.

Pandemic has changed the way we work, how we collaborate with our team. Our communication pattern has completely changed from synchronous to fully asynchronous.

Here are some of the tips and embrace the change; some might become separate OKRs or SMART goals for your respective organization or your respective group.

Start with automation (Infrastructure, On-boarding, Testing)

• Given the supply chain issue we are facing due to silicon demand, the better option would be to use cloud VMs as an alternative for developer workstation.
• Move to full-automation testing with release pipelines (Azure Devops, Jenkins, Travis, Github Actions, so on).
• Start with a decent build manual (if you don’t have decent one already). It shouldn’t take more than a couple of hours for new developers to set up the local development environment.

Encourage asynchronous communication

• Use MS-Teams and Slack for communication.
• Encourage offline code and document reviews.

Break large codebase in to small manageable services (More on this in my future blog)

• It makes on-boarding new engineers much easier.
• New engineers doesn’t have to know 10 different things to fix a small NRE (Null reference exception).
• Avoid code base spanning across multiple repos.

Promote autonomous teams

• Nothing kills productivity more than never ending status updates meeting and coordination meetings.
• Break the large team in to smaller teams of 5 developers are less. Two pizza team.
• Track the key results not the daily or weekly targets.
• Start with OKRs or SMART , set objectives and leave the results to the team.

These are some of the tips; this blog post is by no means complete. In my future blog posts, I will explain strategies for breaking monoliths. I hope you find this post useful. Please like and follow.!