Last June, we released new features specifically aimed at remote work. One was created to measure overtime and, in a sense, work-life balance. We call it “Always On.” This creates an indexed score based on high-volume activity outside of standard work hours, focusing on Jira, git, calendar, and messaging apps. Always On quickly became a key focus for us and our customers throughout the pandemic.
Like many development organizations, we plan our work in two-week sprints. Once a sprint is underway, we drill into our set priorities and avoid deviations. Yet, as every dev team has experienced, things happen and plans change.
Our last sprint was a great example of this.
The mid-sprint pivot
Just days into a sprint, we discovered an issue that was affecting a singular customer by causing key data to be displayed inaccurately. This became our top priority and we huddled immediately to plan a remedy. As engineers so often do, we realized there was a better, simpler way to design that feature—so we chose to improve the feature at a core level that would serve all our customers. The benefits were clear.
Carrying out this work was complex, however, and engaged many cross-team dependencies involving data science, service, presentation layer, and the customer success team. As a team, we made the bold choice to fully “blow up” our current sprint and redirect everyone to focus on the fix.
The team rallied hard through design, development, testing, deployment, and communications. The results were outstanding, with immediate strong user adoption and appreciation. We experienced one of the most energizing aspects of working at a startup—the ability to react quickly and immediately see the results of your work.
Our post-sprint state
But this effort came at a cost. Soon into our scramble, our Uplevel alerts showed that our Always On levels had spiked. As a leadership team, we already knew (and, in fact, expected) this. What we didn’t know was just how hard the team had been working. We were facing our highest collective Always On scores ever, both in value and duration.
There was a direct cause-and-effect at hand. Knowing the exact source and magnitude of this problem, we decided to respond with two specific actions.
First, we enabled a full company closure the following Friday to give everyone some time back. Our team was able to relax and recharge. Second, we adjusted the upcoming roadmap schedule to ensure that the following weeks would ask for a comfortable level of output. That came with the decision to not force a swift catch-up of the planned items that had been delayed. Had we done that, we could’ve easily predicted a return of sky-high Always On scores.
As we implemented these two responses, the team’s Always On numbers settled back to manageable levels, and more importantly, have remained there since.
In one dynamic sprint, we addressed a customer issue and released a quality feature for our entire audience. Most critically, our own product was able to guide us to a smooth landing. Just as we designed Always On to achieve, we were able to give our team a break to avoid dreaded burnout.
This post is written by Uplevel CEO Joe Levy