How has the nature of our work changed over time?

Related to the recent discussions about burnout, metawork, self management, etc:

Many of us who’ve been at OpenCraft long-term feel that we aren’t doing as much coding these days, and there is much more metawork. I also personally noticed that it seems like we’re doing a lot more ops work than coding. So I decided to do some Jira analysis to see if that is actually true.

This is not a scientific approach, but I just picked three random sprints from different eras of the company - 2015, 2017, and 2021. I picked the sprint numbers at random (except one of my first choices fell during a holiday so I picked a different one so that none of them were holiday/December sprints). Then, I quickly categorized each ticket in the sprint as either coding (or code review), other technical task (discovery, ops/hosting work, etc.), or non-technical task.

You can see what I found in https://docs.google.com/document/d/1gXmEgwscamVzsxzR11L8n1sqAAoFOL6u5v2die5yY9Q/edit# (only members of OpenCraft can see this; it contains screenshots of our internal Jira)

The summary is:

  • between 2015-2021, the average # of Jira tickets per developer per week increased from 4 to 8 (and may actually be higher as there are way more newcomers in the 20221 sprint who have few tickets each). This doesn’t necessarily mean the workload is higher but it does mean more context switching.
  • The 2015 sprint was almost 50-50 coding and other technical tasks, with no non-technical tasks (because @antoviaque did most of them and we didn’t include them in the sprint)
  • The 2017 sprint was similar to 2015, but had more tickets in the sprint.
  • The 2021 sprint had much fewer coding tasks and it looks more like 10% coding, 45% other technical, and 45% non-technical tasks.
    • Note that this is just the # of tickets, it doesn’t necessarily reflect how people are spending their time, which I don’t have time to research.
    • Although a lot of the tickets are things like “Sprint planning” and “Epic management” which we still did in the past, but didn’t have tickets for.
    • There is one clear exception: The Falcon cell had a ton of coding tasks due to the LX project

The reason I mention this is: a lot of the recent discussions have been centred around how our process and policies have changed, and how that affects the team. But perhaps we have to also look more at how the nature of our work is changing. For example, maybe as the Open edX platform has become more mature, there simply aren’t as many clients who want to heavily customize it, and instead more people want support with hosting and ops?

That said, we certainly have a lot of pure dev projects in the backlog, including a ton of work on the platform itself (major new features), on the OpenCraft theme, on SprintCraft, on the workflow manager, on the containerization of Ocim, and so on. So I don’t think there’s any shortage of coding work, but there are clearly systemic factors that bring us to have a lot more non-coding tasks than coding ones these days. It could be possible that there is less client-driven coding work.

Ticket: MNG-2774

5 Likes

I’m not sure about this. I feel like there are plenty of clients that want to heavily customize (I keep finding them) but that we’ve been ready to onboard clients that are focused on hosting and using the standard featureset. I go over this a bit in my scaling proposal-- the mandates that drive our sales process, how this affects our client pool, and how we should refocus on which clients we’re seeking.

It also implies potential massive wins if we invest more in automation for our current clients. If we have 45% non-coding technical tasks and we have coding tasks in the backlog, it suggests to me that we have a lot of technical, non-coding tasks in the ‘urgent, important’ prioritization quadrant. If they weren’t more pressing, we’d likely be picking more of the coding tasks-- they’re a lot more fun.

3 Likes