During my office hours, I frequently get asked for practical tips on getting started with observability. Often it’s from folks on teams who are already practicing continuous delivery (or trying to get there) and are interested in more advanced practices like progressive delivery. They know observability can help—but as individual contributors—they don’t sign the checks, so they feel powerless to help get their team started with observability.
What can you do to get the ball rolling?
Here’s a step-by-step guide on how to get buy-in from both your peers and decision-makers.
Step 1: Do your homework
▢ Read up on observability
Make sure you have a handle on observability terminology and concepts because you’ll likely have to explain in detail why you want more observability. To help prepare, we recommend that you be able to answer these questions:
- What is structured data?
- Why is it better for debugging than metrics and logs?
- What is tracing and why is it important?
- What does it mean to ask new questions of existing data?
Our Observability 101 blog post is a great place to start.
▢ Use examples of recent incidents
Think of a recent incident (or several) when observability could have helped your team solve things faster or more easily. For instance, do your current tools support asking questions iteratively? Do they allow you to zoom in to find specific issues and zoom out again to look for patterns? It helps people warm up to the idea of trying a new approach when you identify real pains that your team is feeling and offer tangible solutions.
Step 2: Try it out!
▢ Learn about instrumentation
This is also the time to figure out a bunch of other things, such as:
- What integrations make sense for your team’s tech stack?
- Is there auto-instrumentation for the application language you’re using? If not, is there a manual way to set up application instrumentation?
- What’s the level of effort needed to set up tracing on each of your services? (hint: it’s probably less than you think)
If you’re not sure where to get started, check out our docs for a quick crash course on tracing.
▢ Create your own proof-of-concept
Did you know you can run your own proof-of-concept by sending information from your development environment to see what your telemetry data looks like in Honeycomb? You can do this on a separate branch on your team’s codebase or use an example app like RealWorld to play with fake data.
git switch -c shelby.observability-test npm install honeycomb-beeline npm run dev curl localhost:3000/api/articles
If you get stuck, try joining Honeycomb’s Pollinators Slack group. It’s a great place to go for help and learn from what others are doing. You might also consider dropping into my office hours.
(By the way, if anyone asks what you’re doing, you can say this is R&D work for ways to improve service reliability and engineer efficiency. You should be spending at least 5-10% of your time on continuous learning, right?)
Step 3: Spread the word
▢ Find your allies
Ask around to see if anyone else has looked into Honeycomb or observability tooling in general. Ask to see if anyone else would like to solve those pains you identified in step 1 and show them what you’ve learned about how observability can help. Then ask them to join you in sharing this information with everyone else!
▢ Start planting observability seeds
Share articles, whitepapers, and tweets in Slack to plant and continuously water the observability seeds.
If you’re on Twitter, you can follow and share tweets from Honeycomb’s CTO Charity Majors and Principal Developer Advocate Liz Fong-Jones, and also start following other leaders in the observability community like Cindy Sridaran, Abby Bangser, and Jaana Dogan.
Our resources page also has a ton of guides you can share with your team on topics like how to achieve o11y at your organization and distributed tracing.
▢ Share your queries
Share some screenshots from your free Honeycomb team, explain what trends it is you’re seeing by telling people what they’re looking at in that screenshot, or invite your teammates so you can share direct links to query results and traces. You’re acting as a primary investigator and you should be out to help inspire curiosity and get folks interested in seeing the same data you’re seeing. Fun fact: The query permalinks never get deleted and we’ve made it easier than ever to share them with our Slack integration.
▢ Bring your team to a demo
If just showing your team what’s happening isn’t enough, try inviting your teammates to one of our weekly live demos! It’s a great opportunity to get a glimpse of how tracing and queries work in Honeycomb, and ask about your use case.
Step 4: Talk to us!
▢ Create allies that influence decisions
While some teams can install a Beeline to instrument their code and deploy to prod in a few hours, others require more time to set up a new integration. It’s a good idea to bring in a decision-maker who can see where this work fits into the bigger picture at your company and can advocate for this work.
▢ Talk to our Developer Advocacy team
Now, you have an influential stakeholder in your camp, whether it’s your manager, the team lead, or a veteran engineer. Bring them to Honeycomb’s DevRel office hours to discuss what the integration process will look like with your architecture and tech stack. That’ll help you determine where your observability investments can fit on your team’s roadmap.
Note: Don’t feel like you have to wait until this point to talk to us! DevRel is happy to meet at any point to help you get data in, improve your instrumentation, or gain more insight from your queries and traces.
Step 5: Coordinate with the sales team
▢ Talk to Sales
Now you and your influencer can figure out who at your company should be talking to our sales team. They don’t bite—I promise!
The goal is to discuss the best strategy for helping your engineering organization get value out of Honeycomb quickly and at scale. Our sales team is going to invest time in making sure that Honeycomb truly is a good fit for your engineering organization.
▢ Sign up for free!
Yup. Free, no strings attached. Sign up for a Honeycomb account and get your data in, and start using Honeycomb!
▢ Plan for procurement
How does your organization work with vendors? You don’t need to have all the answers right away, but it’s a good idea to learn who should be involved in the conversation so that when you’re ready to sign a contract, all the right people are ready to jump in.
Step 6: Bring Honeycomb to your org
▢ Share in Slack!
Once you’re set up in Honeycomb, share it with your team in Slack!
▢ Promote observability as a practice
While your team is getting the hang of Honeycomb itself, this is a good time to think about how to promote observability across your organization. At Honeycomb, we feel strongly that data and tooling can make a big difference, but they alone aren’t sufficient to achieve production excellence. In order for your engineering teams to do their best work, it requires new practices and cultural changes as well—this article by our CTO Charity Majors is a great read on what some of those are.
▢ Ask our developer advocates for help
Schedule a talk or lunch and learn with one of our Developer Advocates, who can share well-researched insights and give recommendations about what practices to adopt in order to get the most value out of your investments in observability.
Don’t want to go through all these steps and just want to try Honeycomb for yourself? You can sign up for free anytime.
