Jellyfish on Jellyfish: How Our Team Reduced Thrashing and the Impact of Unplanned Work

Every engineering leader finds themselves asking, “How can we go faster and get more of the roadmap delivered?” As teams grow, the processes that seemed to work before are now causing inefficiencies. “Thrashing” often becomes the norm, and teams can find themselves spread too thin or unable to focus on roadmap feature work. 

Jellyfish faced this same question: as we grow, how do we change our processes to spend more time on feature work? How do we reduce current levels of “thrashing?” We took an approach where we used data to look at this challenge from a new perspective. Luckily, we could use data to identify a possible source of the issue and experiment with a potentially viable solution. In this blog, I’ll discuss an experiment we ran to answer those questions.

The Experiment: Could we deliver software faster by managing unplanned work differently?

Pre-Experiment Investment Allocations

Digging deeper into work allocation data, most engineers across our team spent a lot of time on bug fixes, production monitoring, and customer support. This work was important, but it was also unplanned and disruptive to engineering flow and focus. Our approach to assigning unplanned work meant that every team was impacted at some point during a development iteration.

We hypothesized that changing our approach to unplanned work would improve focus which would show in the speed at which we worked. To try this out, we ran an experiment where teams took turns being on point for unplanned work on a weekly basis.

We hoped for the following measurable benefits:

• First, issue cycle time for planned work would be reduced across the teams
• Teams dedicated to planned work would see their roadmap allocations dramatically improve.

What We Learned

The allocation of unplanned work to one team significantly benefited other teams’ ability to focus on roadmap work. As seen below, when teams focused on roadmap work, their allocations were consistently better than 70%.

Jellyfish Work Allocations Investment Comparison

We also discovered that the effect wasn’t consistent across teams. After talking with teams that didn’t see a consistent outcome from the experiment, we found that unplanned work tended to roll over into the weeks that were intended for roadmap focus. That insight prompted more conversations and optimizations that we tested through further experiments.

At the start, I mentioned that we were looking to move faster as a result of these experiments. So did we? At the end of several experiment cycles, we could see an approximately 21% decrease in issue cycle time, which suggests we were moving faster on our planned work. While other factors could be involved, the data does show a marked change soon after the experiment started.

Jellyfish Issue Cycle Time Over Time

The Impact of Improved Engineering Ops on Team Satisfaction

The data isn’t (and shouldn’t be) our sole measure of the success of an experiment. Feedback from our engineering teams is an important signal that things are headed in the right direction. Our engineering teams reported greater job satisfaction and higher productivity as a result of the focus they gained through a more intentional approach to managing unplanned work.

Closing Thoughts

The beauty of having Jellyfish is that it makes it easy to visualize how organizations work, setting everyone up to start asking questions that lead to greater insight and improvement. 

The goal of any experiments you take up to improve your organization shouldn’t be to move the needle on your favorite metric. Often your actual strategic objectives become undermined when a benchmark goal is prioritized over all else. Instead, the goal should be to use data to tell the greater story about your engineering organization and prompt conversations that lead to experiments that result in happy and productive engineers.

To learn more about Jellyfish and the data-driven insights that it can provide to your team, check out the product tour.

About the Author

Jim Krygowski is an engineering leader at Jellyfish with a keen interest in the design of engineering organizations and their processes. Jim has been helping the Jellyfish engineering teams solve challenges related to the process and procedures as they scale rapidly. 

Back to Blog