During COVID-19, Engineers Work Longer, Less Regular Hours & Peak Four Hours Earlier in Day

Posted on September 14th, 2020
Written by Mobolaji Williams | Data Insights

COVID-19 has changed the nature of all kinds of work. It has abruptly stopped the service industry leading to job losses and clogs in the unemployment benefit system. For the tech industry, it has made remote work universal with many major tech companies recently deciding that their employees will be working from home for the foreseeable future.

Jellyfish is the engineering management platform that helps teams understand how they are working towards roadmaps, interacting with one another, and spending time on objectives. We use data from GitHub and other sources to quantify and understand this activity, but this data can also be used to understand engineering trends across the country. At Jellyfish, we wanted to use GitHub [GitLab or Bitbucket] data to ask a simple question about these news trends:

How has coding activity changed from before the pandemic to now? In particular, how has the distribution in time for when people make commits to Git changed?

Peak Work Shifts Earlier in the Day

To answer this, we looked in particular at the distribution in time for when people make commits to GitHub [as well as GitLab and Bitbucket]. We compared the distributions for the month of January (well before any states began suggesting and then requiring remote work to curb the spread of COVID), and July (three and a half months after many such suggestions were implemented). Our dataset* contained dozens of software companies in the U.S.

Figure 1

Figure 1

In Figure 1, we plot the number of commits for this set of engineers versus the exact times when commits were made. We see that relative to the distribution of commits in January (well prior to the country’s move to largely mandatory work-from-home) which peaks at 3pm, the distribution of commits in July peaks at 11 am, four hours earlier in the day.

One could imagine many reasons for this, but a likely contributor is that without the need to commute to work, workers can start their work days earlier and end their work days later. More research is needed to understand the exact reason for this phenomenon.

Engineering Days Less Likely to be “9-5”

The above plots give us a sense of how the times people are committing code has changed, but could we also get a sense of how the length of time people are committing code has changed? We attempted to answer this question as well.

Figure 2

Figure 2 plots the number of person-days vs the time from first to last commit. A person-day is a singular day of work for a given engineer. Therefore, for a given company, the count of person-days is the number employees multiplied by the date range we are examining.

For the January distribution, we see a noticeable peak at around 5-7 hours. Such a peak is what we would expect if we imagined engineers committing code on a standard 9-5pm office schedule. We henceforth call this the “9-5pm peak”, and its existence is a signal for the pre-covid working habits of engineers. This peak does not exist for the July distribution. Rather, it is flatter and has a longer tail of commit times, which suggests that engineers who had comprised the “9-5pm peak” have now become more varied in the time spans of their work.

One possible reason for the absence of this peak after March is that not being in an office has led to less clear distinctions between work time and home time. Without such distinctions people have more freedom in selecting their working times and can start and stop committing code according to more personal schedules.

Managing this Pattern Change

These results indicate that the patterns of software engineering work have already changed due to the pandemic. As these work patterns continue to evolve, so too will the way software engineering teams should be managed. Now more than ever, engineering managers and executives are looking for greater visibility into the daily work of their teams. It’s important to remember that changing work patterns do not indicate changing quality or quantities of work. That’s why tracking hours logged or creating “timecards” through simple git analytics can have dangerous and negative implications. Instead, Engineering Management Platforms like Jellyfish can provide deeper and contextual visibility into what engineering teams are working on and how projects are tracking to deliver, and to better understand shifting work patterns and their ramifications on specific teams.