Three Approaches to Observability’s Change Management Issues

3 Ways to Face Observability’s Change Management Challenges

I’m acutely aware of the effort required to change from traditional performance monitoring to attaining end-to-end observability as someone who spends a lot of time interacting with our IT prospects and customers. For many reasons, businesses come to the decision that they need to change. Some people wish to go from a proprietary monitoring platform to one that uses open standards, or they want to combine many point solutions into one observability solution. To make matters more complicated, your apps could be in the middle of cloud migration, or you could have just adopted a microservices design. Observability necessitates IT leaders to manage organizational change, regardless of the technical changes that must be made or accommodated. And it’s a tautological fact of life that people will resist change until the pain or cost of not changing outweighs the agony or expense of the change itself.

We’ve reached a tipping point where making this move is no longer optional. Because applications have become considerably more complicated in recent years (the monolith-to-microservices story), performance management now encompasses a much larger surface area. Although open standards such as OpenTelemetry have made it easier to instrument new services, the number of sources and amounts of data is rising at a rate that IT workers cannot keep up with. Finally, contract management’s pain is likely the least intriguing. Adding a new tool to monitor each piece of telemetry data has resulted in some IT teams spending as much time resolving their monitoring bill as they do fixing their actual applications.

The anguish of not changing is the proverbial “stick,” and the respite from that pain is the proverbial “carrot.” When it comes to managing the organizational change required to promote observability, you’ll need both. It’s pretty unlikely that any of your engineers are ecstatic about the thought of replacing a slew of monitoring instruments each morning. You’ll need to make the transition more appealing to IT staff. I’ll discuss three points to consider to get your team enthused about replacing standard monitoring tools with an observability platform.

1. Accountability and leadership

Business is a fluid dynamic, whether you’re facing new and expanding competitors, experiencing a digital transformation, or client needs on your digital experience have suddenly shifted (a recurring topic recently due to COVID). And the technology it relies on must be as well. Regardless of your specific situation, your employees must comprehend why a change is necessary. What motivates the demand for transparency? Is it to hasten the resolution of a problem? Cost-cutting? Allow developers to be more creative and confident in their chaotic testing? Leadership at its most basic level entails trusting others to do the right thing when they understand its reasoning. As a result, ensure you keep repeating the “why” to your team until they can do so independently.

Simultaneously, link the “why” to specific goals and make people accountable. Customers-oriented results, rather than internally centered ones, are aligned by the most successful firms. Instead of evaluating your engineers and product managers on the number of features they ship in a given period, hold them accountable for the number of monthly active users of your freshly launched app. Keep track of net promoter scores (NPS) and hold employees responsible for meeting customer satisfaction goals.

With the rise of DevOps and the full-stack engineer role, it’s becoming commonplace for the people who build code to deploy, monitor and manage it, ensuring that it provides value to the end-user experience. When they’re in charge of the end-to-end experience and run into a problem, they’re immediately tracking it down from the front end, through the service tier, and into the infrastructure, which is increasingly using Kubernetes. When the silos between the objectives to which software teams are held accountable are broken down, they will naturally desire to remove time-consuming silos preventing them from reaching those objectives. Customers and your business will win when those objectives are centered on your customers rather than internal measurements.

So that’s one piece of advice: start with the user experience and move backward to determine the metrics for which your engineers are held accountable. Engineers inherently want customers to use their software, so they’ll become more engaged when their success is tied to customer outcomes.

2. The curve of learning

Managers spearheading this type of transition also have the task of making it as simple as possible for employees to become and remain productive. Ensure the observability platform you’re providing them with is familiar and straightforward. When something goes wrong, having all the data on how a system is operating in one place won’t help if your team can’t figure out how to acquire answers to the questions they want to ask of this data.

Pay special attention to how well your selected observability platform integrates your system’s specifics into a unified view of end-to-end health as you assess the learning curve. It’s critical to see your entire system’s health at a glance. Data visualization makes it simple to see trends, correlations, and patterns. According to Gartner, the brain receives 90% of the information in images, which it processes 60,000 times faster than text.

Make sure you’re not substituting figuring out what one platform is trying to expose for the effort of working across other tools. When asking your engineers to switch technology tools or platforms, ease of use is a more significant concern than you might realize. It will reduce the time between when a problem occurs (or is likely to happen), the mean time to detect (MTTD), and the mean time to resolve (MTTR) (MTTR).

3. Recognize the trade-off

Another crucial step is to admit with your team that change often entails sacrificing something good to gain something even better. Consolidation of tools, for example, is a common theme we notice. Companies are migrating from many “best of breed” point solutions to a single observability platform that keeps all information about a system’s activity in one place to manage an increasingly complex and diversified software architecture.

It is typically because being able to navigate the connections between components swiftly allows IT, professionals, to provide end-users with the most excellent possible experience with the fewest and shortest possible interruptions in that experience. It’s not uncommon for a point solution to have one or more “pet features” that teams adore. To embrace change, they need leaders who recognize the worth of the things they’re giving up while also persuading them that the solution they’re adopting will improve their lives in the long term.

Individuals are individuals.

Finally, as a change manager, focusing on the people you’ve entrusted with executing the task will make the transition from monitoring to observability go much more smoothly. Make it as simple as possible for them to affect the change, and ensure that what you’re asking them to give up is smaller than what they acquire in exchange. Don’t make the mistake of assuming that a collection of monitoring tools will provide full-stack visibility. 

Enteros

Enteros offers a patented database performance management SaaS platform. It proactively identifies root causes of complex business-impacting database scalability and performance issues across a growing number of clouds, RDBMS, NoSQL, and machine learning database platforms.