A Guide to Escaping a High-Operations Cycle
High-operations is a painful cost to a company, employees, and customers. This walks through the causes and resolution of high-operations cycles.
Your team members regularly get pulled off their projects to deal with customer issues. The on-call can't stay on top of things by themselves anymore.
As this slowly happens more often, the team begins to fall behind on projects.
Perhaps that leads to pushed dates. Sometimes it might lead to lower quality work, which leads to more operational issues later.
Your partner teams want to know when you'll be able to allocate more of your team to project work, instead of always allocating your team to these operational tasks.
As your team dislikes their jobs more (perhaps leading to attrition), the situation only grows worse. You get less project work done. You apply more patches rather than actual fixes to customer issues. Your team is more rushed in any work they perform.
Does this sound familiar? Many people encounter a high-operations cycle like this sometime in their career.
What do I mean by operational tasks?
In general, incoming tickets, customer issues, or broken systems. This can impact anyone from customer service teams to UX teams to engineering teams.
This is often aptly named "Keeping the lights on", as it is the required effort to "operate" your business.
However, this is called an operational cost for a reason. Operations are not profitable. Every bit of effort you spend dealing with operations is time taken away from business improvement activities.
When a high percentage of your team is regularly dealing with problems, a high percentage of your team is not investing their time in opportunities.
This often originates from a poor balance of operational investments on a team.
At the root, a team needs to be reactive to the existing operational issues, and then continually remove sources of operational cost to maintain a healthy level of business improvement activities.
What does removing the source of an operational cost mean?
If you fix a single customer's problem, then a single customer is happy. This is often costly, but appreciated by that single customer.
If you fix a problem forever, no future customers run into the same problem. This is even more costly in the short run, but appreciated (in essence) by all future customers. This is also efficient in the long run, as you've removed that operational cost forever.
As an example, pretend that you regularly have customers contact you to manually cancel their subscriptions. You do have a self-service cancellation process which works, but customers often contact you to cancel.
If you are overloaded, you will likely cancel their accounts manually, and close the ticket. Most often with your employees saying something like, "Stupid customers!"
This temporary fix punts the problem down the road. You are indeed doing a good thing for that single customer, but you're addressing a symptom, not the problem itself.
Solving an issue means that you're fixing a problem for good. In this case, you might implement a few methods to help reduce or eliminate this customer and operational pain point.
Change your UI to make it easier to find the self-service cancellation button.
Add cancellation instructions into your recept messages to customers.
Catch any remaining customers by adding a "cancellation" option on the contact-us form to redirect them to the self-service tool before contacting you.
As a side note, it's rarely as simple in reality as I explain in my articles. There are always caveats. For example, making it easier for customers to cancel is often costly to the business. You might run into a few arguments when you attempt to make it clear and simple for customers to cancel.
What you might find yourself trying, and is unlikely to work
Many teams institute some type of operational hack day/week. They'll ask the whole team to go heads down, and fix a bunch of problems.
This isn't necessarily a bad thing if your team has a serious issue, but it's not likely to fix the problem for good. If your team has an incorrect operational investment process, then you'll inevitably end up back in the same situation.
Other teams will wait until the situation is catastrophic, and then they'll convince their leadership that it's time to re-write their software. That's because the situation is viewed as unmaintainable.
This rarely works because big bang launches rarely make the situation better. I'd also expect if your operational investment process isn't addressed, you'll end up back where you started soon enough.
Gaining support for investing in operational improvements
Convincing your corporate overlords that you need to allocate people to fix your operational situation can be challenging. That would require a whole article itself to navigate how to politically get support for the task.
However, at a high level, what you want to communicate is:
Are operations currently getting better, or worse? Clearly they're getting worse if you're in a bad operational situation.
Assuming they're getting worse, does anything lead us to believe that they'll improve on their own? In some way does the future look bright? This is rarely the case.
Assuming our operational costs are not improving on their own, and they're getting worse, this mathematically means that the entire team will eventually be consumed by operational problems all day. As a side note, this happens all the time to teams. It is not an unlikely scenario.
If your team is dealing with operational problems all day, this means they are not A) building new things for customers, or B) solving problems for the long term.
The only solution is to remove the sources of operational cost. This can only be done by a concerted investment in operational cost reductions. All investments in this area will be paid back in the long run (although the timeline will vary based on the size of the operational cost).
Before you (or your corporate overlords ask), no, I don't think #6 can be quantified. Everyone always asks. I am convinced it's impossible. If someone requires it, you can lick your finger, stick it in the air, and say "Feels like this investment will pay us back in 9 months!", but you and I know that you'd be just making crap up.
I believe that the alternative of investing in reducing operational costs is unrelenting and forever increasing operational costs until your team grinds to an absolute halt. And that's unacceptable. So we will argue in various ways until we gain agreement to invest.
As a side note, perhaps you're at an agile place where you don't have corporate overlords controlling your investment. Great. You probably should have skipped that part.