Hi everyone, I'm transitioning from a technical role to an observability advocate in my company, which is trying to shift toward a more DevOps-friendly environment. We're coming from a legacy structure where developers aren't very engaged with observability—often feeling it's not their job or they don't have the time for it. Operations still rely on old processes, and developers only step in when there's an issue through ticket escalations. We've acquired a new observability platform, but it hasn't yet been integrated into our workflows. I'm looking for advice on how to encourage a cultural shift towards embracing observability. How can I motivate our team to take ownership of their applications in line with the idea of 'you build it, you run it'? I'd also appreciate any resources or strategies on fostering this kind of cultural change, as it's new territory for me. Thanks for your help!
5 Answers
Remember, most people dread learning new technologies. It's a common misconception that developers love tinkering with every new tool—many prefer sticking with what they know. Keep that in mind when introducing the observability platform!
We had success by quickly demonstrating value with real issues. One instance, I traced an important API error in just a couple of minutes, which got the buy-in from all developers. Now, they all actively use our observability tools. The main issue was instrumentation since they had never done that before. We're moving to a platform without a straightforward one-click agent installation, so we had to get creative with instrumentation.
Good luck with this challenge! Getting people to adopt tools they don't care about is a tough road. Here's what I've found works: First, for those developers who actually want to improve their apps, show them how observability can make their lives easier with hands-on training or demos of the platform. For the folks who resist, some negative consequences might be necessary. If there are performance issues, make it clear that it's their app's fault, which might motivate them to add the necessary metrics.
You really need to get the engineering managers on board—they are crucial in making sure engineers actually have the time and motivation to focus on observability. They should know that if a feature they manage has issues, it's on them to ensure observability is in place. Allocate specific time for adding observability in impactful areas. You’ve got to make the case for why it matters, and help teams set realistic milestones to achieve this, keeping empathy and practicality as your guiding principles. Good luck!
You might want to consider a few important questions here: What influence do you have in your company? Do people listen to your ideas? Your title can matter, as those with higher status often get listened to first. And check if this is a common pain point among developers—was observability a topic of discussion before investing in the new platform? Understanding these dynamics will shape how you approach the situation.
Make that instrumentation process as easy as possible. Use automatic agents and shortcuts for deployment. For instance, implement OpenTelemetry's auto-instrumentation for Java, .NET, or other languages. Set everything up with an on-prem OTel Collector for trace and log handling. For existing services, introduce Envoy or NGINX to help with tracing. Facilitating quick integration can show immediate value and reduce resistance.