How Work Has Changed in the Age of Quarantine

Quarantine has changed the way people work and the way companies operate.

But how exactly have things changed?

Allstacks helps organizations track and improve software development for more predictable software delivery outcomes. They decided to look at their data to determine how quarantine has affected people, processes, and outcomes. We talked to Hersh Tapadia to discuss what his team learned about working in “the new normal.”

What made you conduct this study in the first place?

Understanding the systemic health of organizations and how that contributes to their ability to deliver outcomes to their key stakeholders (whether that’s customers or people inside their organization) is a big part of what we do.

We saw companies that were struggling with the sudden transition. Some companies didn’t even know if they had enough computers for everyone.

We had a unique set of data, and so we set out to see what had changed.

How did you get the information and what was the demographic breakdown?

This information came from our software. What Allstacks does is leverage all the data in all the developer tools to understand how organizations are doing their art of developing software.

We have everything as granular as the lines of code that changed in a single commit to if a release is trending later or earlier.

We took the dataset we already have from our customers and data from open-source communities, and looked within those organizations to see how things were changing.

What did you find in the data?

We created a three part series: People, process, and outcomes.

In each aspect we looked at how people’s lives were changing.

Working from home in quarantine isn’t work-from-home in the traditional sense. Right now, it’s everything at home.

It’s school at home. Childcare at home. It’s living and taking care of grandparents while still being productive and doing your work.

And then you have changes like when you’re going to get groceries, when you’re going to workout, when you’re going to start work, etc.

We looked at how people were working and when they were working. We saw some interesting patterns.

For example, the hours that historically were dedicated to commuting saw a lot of uptick.

If you were already used to waking up at 6AM, leaving the house at 7AM and traveling an hour and a half to get in the office, now you’re using that commute time to work.

People are waking up at the same time, but they are able to turn on and get right to work. If they started at 7AM, they could skip lunch and be done by 1PM.

Other people, who had kids or loved ones to take care of at home, didn’t have a concentrated start and end time.

They would do some work, then cook lunch for their kids, then help them with homework, and then do some more work, then get meds for grandma, then do more work. It’s more spread out.

Then there was a population like a single person in an apartment who is an introvert and they haven’t left in a while and the lines between work and home are totally blurred. It’s Saturday at 2AM and they’re committing code.

They need help getting some non-work life back, creating some boundaries, and maintaining mental health. Otherwise there will be burnout.

That’s bad for the person, bad for the company, and bad for the community.

Highlighting those aspects were important in phase 1. How people were able to integrate and adapt to the new normal and how that affected their organization.

What suggestions do you have for companies that have distributed teams in different time zones? How can they best work together?

A key tenant is whether your company is focused on the outcomes or not.

A lot of times people go awry because they say they need two people to be available at any time, all the time. They’re focused on schedules and inputs rather than outcomes.

It comes down to what everyone working on, where they need to collaborate, and where they can work independently. Where can they lean into their tooling to improve the asynchronous communication?

The software industry has spent 10 years building dev tools for every micro-interaction within the development lifecycle. But then companies turn around and make decisions in the hallway of the company despite the fact they’re using all these tools to maintain the system of record.

There was a stat in February that 63% of organizations had a preference for face-to-face interactions and face-to-face decision making.

In March that had to change.

In talking to some of our customers, we heard people had to revisit their processes to make sure they were no longer reliant on face-to-face interaction. As a result, things were documented more and people had to follow processes of communication and documentation to account for the gray areas where others didn’t have transparency into how those decisions got made. They could go into the history of the development tool and see how they reached the conclusion.

It made for better processes.

Looking at the data, we ultimately only saw a 2-3 week stutter on outcomes for companies.

But what changed was how they achieved outcomes.

All the processes we hoped our developers would follow started happening because it was the easiest way for them to get what they were missing from a lack of face-to-face interaction.

We’re leaning into processes.

There’s more adherence to project management processes, more granular commits, more frequent commits, smaller PRs, decreased cycle time, more frequent deployments, more frequent documentation, better code commenting, more interaction within context (on the JIRA story itself instead of outside the platform).

We asked how we could maintain the quality of communication that we used to have sitting across the table from each other.

We were missing context. Missing time synchronization.

How do we take care of that?

We had to make sure the discussion happens in context when it has to happen asynchronously. Like commenting on the PR or the ticket itself, rather than trying to send someone a Slack.

You get better value out of the tools. Better value out of the processes. Better maintainability, code quality, and outcomes.

Fully remote organizations knew this, but we saw gains even there.

We run reports for our customers to let them know how they’re doing and track their performance over time. Even though some organizations had a bit of a dip or a period of time where they weren’t performing as they hoped, others saw decent improvements during the transition because of a couple of things:

• They already had the processes in place
• The technology was in place

Some areas were blurred so employees were nervous their employers were not seeing the work they were doing. So people worked a little harder and longer and did a better job tracking the work they did within the tool, regardless of what they’d been doing in the past, to make sure they had job security.

What trends have you seen in the tools that companies are using?

We have startups on our platform but we also have a lot of enterprise companies. A general trend we’re seeing is enterprise companies moving to the cloud.

We’re seeing a lot of split systems like JIRA and GitHub instead of JIRA and BitBucket. But it depends on what way they’re making that migration.

If they’re moving from an SVN to a Git-faced system, they’ll often move everything at once. If they move in pieces, they’ll have to adapt to GitHub first and then use JIRA to create a split system.

A lot of Microsoft teams will show up. I’ve been impressed at how rapidly the Teams team is iterating. You don’t typically expect that from an enterprise product.

Clubhouse is an interesting one. We see startups in Clubhouse. We’re integrated with them and like them a lot.

As companies mature, they only want to change their tooling so many times. The iterations to a company’s stack are pretty discretized.

I don’t think development is going to see as much of an upending in the developer tools ecosystem because we’ve spent 10 years building a tool for everything. Every detail of software development. It’s already part of the ethos.

You’ll see more monitoring tools overall. APM is a big market and you’ll see that across these organizations.

Startups and enterprise think about their tooling pretty differently.

The GitLab strategy is we’ll give you 80% of everything inside of our tool. We’ve seen enterprises evaluate whether 80% of GitLab’s security infrastructure monitoring is good enough. If so, it’s part of the platform, so they’ll just shift that over there and throw something else away.

It’ll be interesting to see if that consolidation trend continues over time.

What is your tech stack?

We primarily use Python and Django on the backend. PostGres is the database layer and we’re integrated into the AWS ecosystem.

We use Vue.JS on the frontend. It’s been really great and we like that framework and we see it growing quickly.

It was a long-term investment. We felt it would get popular in the next five years and would be at its peak when we really needed to scale up.