One of the most important and meaningful cornerstones that has defined and powered my career so far has been how I try to use my skills and talents to make the people around me stronger and achieve positive outcomes. My roles in tech have predominantly been in the ops engineering domain. I consider myself an ops engineer; a title I wear with pride. The most appealing ops roles have been ones where solving ops-shaped problems collaboratively, with compassion, curiosity, intuition, and earnest engagement reliably lead to the positive engineering outcomes I ardently strive for.

Those were the kinds of roles I had at my previous employer, Amperity, and that is where I first learned about Honeycomb.

The teams I was on at Amperity owned ops-centric areas like critical infrastructural systems, the CI/CD build system, distributed service orchestration, Infrastructure as Code patterns, as well as our metrics and logs monitoring stack. In early 2019, I was ramping up and wrapping my head around our areas of ownership, and that was also around the time when Liz Fong-Jones left Google and joined Honeycomb. Her arrival introduced me to the world of observability, which forever shifted my perspective on how my engineering colleagues and I could be empowered to deeply and collaboratively understand and manage the services and systems in our care.

The perspective shift

What I found within the literature, presentations, and thought leadership coming from Honeycomb, such as the Framework for an Observability Maturity Model, articulated a clear vision for why observability really does matter in order to run sustainable software systems, not only for the business, but for the people responsible for maintaining those systems. I connected deeply with that vision because I recalled roles prior to Amperity where I had been the debugger of last resort and subject matter expert on critical systems in my care. I could not effectively scale that empowerment to others, because in those roles, I was accustomed to relying on an eternally-long list of hacks, workarounds, tricks, bespoke walls of metric dashboards, alerts, and custom tooling to keep systems afloat.

Believing I had to sustain that practice and that this was just the cost of doing business, I ended up burning myself out. Understanding core observability principles as Honeycomb described them gave me insight into some of the reasons why I burned out, and it lit a fire under my ass. I was determined to never let that kind of burnout happen again, not just for me, but also for my teammates and colleagues.

Becoming the observability champion

Since my team owned the metrics and logs monitoring stack at Amperity, and because I recognized we had a "three pillars" stack (minus tracing), I saw an opportunity to drive and advocate for improving observability practices and a review of our tooling. Notice that I did not say, “advocate to bring Honeycomb on board.” This was an intentional part of my strategy.

The principles I used to ground my observability advocacy were the exact same principles that underpin my career cornerstone: compassionately meet people where they are, lead with curiosity, listen to what already works and what doesn’t work. I did that rather than leading with my own agenda, even though I deeply appreciated and connected to what I was reading from Honeycomb. I held open the possibility that engineers might be satisfied with and want the status quo. I genuinely would have accepted that answer if that had been the case.

The specific way that I drove the observability discussion internally was to make sure we were all on the same page in terms of definitions, and to define a clear vision and set of outcome-oriented goals to achieve observability maturity, grounded in the Honeycomb literature I was consuming. I wanted service and system owners to:

• feel confident about the systems they own
• feel like they could ship code with confidence
• feel like they could ask any question about the systems they owned and get an answer
• be able to easily add rich context through instrumentation to get that answer
• not dread being on call
• not get burned out under a deluge of constant pages

These are tool-agnostic outcomes, and it was important to frame them that way. The specific tool used to get there didn’t matter as much to me as achieving the outcomes.

What I found was that there were good things about the monitoring stack that we had, but there were also some pains. When it came to being able to have the rich context required to ask any question of the services and systems we owned, the unknown-unknown questions, there were gaps.

Today, there are standardized tools to help teams generate and emit that rich context, like OpenTelemetry. At the time, OpenTelemetry was still very early on in its development, so we weren’t ready to use it in house. We needed another way.

An instrumentation gap fulfilled

At Amperity, we had log-tailers and metric-scrapers and tools to explore that telemetry, but we didn’t have an instrumentation pattern for our application code to be able to collect rich, structured, arbitrarily wide, high-cardinality trace signals. The discussions and conversations I led helped drive innovation and experimentation, to the degree that a robust instrumentation library was built internally. We didn’t have a target to send this trace instrumentation, but we had the means to do so. This was the right moment to advocate for solutions aligned with our goals and design a data-driven tooling evaluation.

Amassing support with key stakeholders

My observability advocacy was a sustained effort over several months that I drove alongside my other core responsibilities. My focus never deviated from the outcomes I sought to achieve, and that sustained effort was necessary because I knew I would need widespread support if it came time to make a recommendation to executive decision makers.

In order to maximize its chances of success, I recruited as wide a coalition of engineering teams as I could to contribute to the tooling evaluation. I selected engineers who were on board with the goals I advocated for.

Honeycomb was one of the vendors I formally reached out to. Going through this evaluation process was exhilarating, and a major reason why was because of the care and attention to detail all of the vendors showed me to support me on my mission, and this was definitely true of the team I worked with at Honeycomb.

As I prepared for the evaluation, Honeycomb helped me sharpen the focus of my evaluation criteria and use cases, and they shared great resources, professional support, and documentation which helped me guide the engineers with their evaluation. Honeycomb was instrumental in helping me set up the evaluation for success. We were also able to do a fair apples-to-apples comparison across the proposed solutions, because we were able to send the exact same tracing telemetry to all solutions through the instrumentation library we built.

By the end of the evaluation, the results were clear: we wanted to add Honeycomb to our stack. The qualitative and quantitative data reflected this. Organizational decisions are never made in a vacuum, and I believed our recommendation would hold up to scrutiny and due diligence. The combination of sustained observability advocacy, wide engineering support across multiple teams, an accurate cost-based analysis, and good qualitative evidence all contributed to their final decision. Leadership approved the decision to add Honeycomb.

No surprises

In the summer of 2020, we started onboarding engineers onto Honeycomb, and once again, the sales and customer success teams at Honeycomb provided me with a robust, guided onboarding rollout plan that helped engineers orient themselves and get quick wins exploring their data within Honeycomb. I also held weekly observability office hours sessions to answer questions or to just talk about observability practices. All of this was designed to ensure that engineers’ exploratory and investigative needs were being met, and that their usage of Honeycomb would be a natural extension of the tooling evaluation we had run. There were no surprises because we had set the right expectations about what Honeycomb was capable of.

Consolidation opportunities and a case study

For any businesses that are cost-conscious, tool consolidation is appealing, and this was also the case at Amperity. There was an opportunity to partially consolidate the logging component of our observability stack. I shared this experience with Honeycomb in more detail in a case study in 2024. By that point, usage and adoption of Honeycomb had steadily grown and it remained a valuable tool within engineering.

Honeycomb was one of several key factors that helped drive sustained improvement of production excellence at Amperity. These included healthy engineering practices, a culture of continuous learning and improvement, and a habit of collecting and regularly reviewing key engineering team metrics that identified the right areas to invest in. All of these efforts tangibly reduced engineering on-call burden and improved outcomes; the very things I wanted to see realized when I first set out on that observability journey.

Joining Honeycomb builds on what came before

In January 2025, I joined Honeycomb’s Core Services team, a platform engineering team that owns key systems and services along Honeycomb’s critical ingestion path. The work I’ve been doing here aligns strongly with the same principles that have driven me throughout my career: solving ops-shaped problems collaboratively, empowering people on my team and across Honeycomb, with compassion, curiosity, intuition, and earnest engagement in order to improve engineering outcomes. I get to build on the legacy of wisdom and thought leadership that was essential in shifting my perspective about the kinds of healthy engineering outcomes that are possible through improving observability practices.

Curious to learn more about this and what we’re working on? That wisdom and thought leadership will be present at O11yCon 2026 on May 20-21. Come see for yourself what made me believe in what Honeycomb does.