Charity Majors

b. ~1980 · American

American software engineer and Honeycomb co-founder, known for observability-as-discipline and the engineer/manager pendulum.

Best for on-call load, deploy health, and the sociotechnical roots of reliability problems

Engineering leadershipObservability and ops culture
Stylized fine-line illustrated avatar of Charity Majors (AI-generated interpretation)
AI-generated illustration — an interpretation of Charity Majors, not a photograph. Informed by a photo by CityTV.nl (CC BY 3.0) via Wikimedia Commons. · CC BY 3.0

About this perspective

What follows is Invisico's interpretation of Charity Majors's published thinking — a distinct way of reasoning drawn from Majors's own work, offered as a perspective rather than a recreation of the person.

Bio

Charity Majors is an American software engineer and co-founder of Honeycomb, an observability company she started in 2016 with Christine Yen. Before Honeycomb, she worked at Linden Lab (the company behind Second Life), then at Parse, which Facebook acquired in 2012, and later at Facebook itself. She served as Honeycomb's CTO from its founding through approximately July 2024, then transitioned to CEO. Her technical background spans database operations and large-scale distributed systems. She has written publicly on engineering culture and production systems since the mid-2010s. She co-authored Observability Engineering (O'Reilly, 2022) with Liz Fong-Jones and George Miranda.

Philosophical lens

Majors argues that the feedback loop between production systems and the engineers who built them is the primary driver of engineering quality. When that loop is slow or mediated by a separate operations team, the whole system degrades: deploys slow down, confidence drops, and problems accumulate. Her answer is structural. The people who write code should also operate it in production, and they need to ask any new question of a live system without shipping new instrumentation first. That capability — querying a running system for questions you did not predict — is what she means by observability, which she distinguishes from conventional monitoring. Monitoring handles conditions you anticipated; observability handles what you could not.

Great engineers are made, not sorted. Teams that perform well do so because of the systems around them, not because of individual talent. Overhiring is the lazy answer to an engineering slowdown; fixing the feedback loop is the actual one.

Recurring themes

  • Production feedback loops as the structural driver of engineering quality
  • The distinction between monitoring (known conditions) and observability (unknown-unknowns)
  • High-cardinality, structured events as the technical requirement for querying production systems
  • Team ownership over individual heroics; systems investment over headcount
  • Management as a distinct profession, not a career ladder step, and the case for deliberately alternating between engineering and management roles
  • Failure as inevitable: design for resilience and fast detection, not prevention

Key concepts

The production feedback loop

The speed and quality of the feedback loop from production back to the engineers who wrote the code is, for Majors, the primary determinant of engineering quality and velocity. A short, tight deployment cycle creates confidence; a long, batched one erodes it. She calls the failure mode the "software engineering death spiral": slow deploys lead to larger diffs, larger diffs make diagnosis harder, harder diagnosis erodes confidence, and eroded confidence slows deploys further.

Observability as a capability

Majors distinguishes observability from monitoring by the type of question each can answer. Monitoring covers conditions you anticipated: defined thresholds, known alert types. Observability covers questions you could not predict. It is the capability to ask any new question of a production system without shipping new code or gathering new data first. Pre-aggregating telemetry permanently destroys that capability; observability requires raw, high-cardinality, structured events. Both have their place; they are not substitutes for each other.

The engineer/manager pendulum

Majors argues that management is a change of profession, not a promotion, and that the strongest engineering managers stay close to hands-on technical work, never more than four or five years removed from it. Her "engineer/manager pendulum" describes deliberately alternating between engineering and management as an intentional career strategy: take a management tour of duty of at least two years, return to engineering when it no longer serves you or the team, and repeat. Returning to hands-on work keeps technical judgment current; it is not a step backward.

10x teams, not 10x engineers

The smallest unit of software ownership, in Majors' view, is the engineering team, not the individual. Engineering excellence comes from building systems where ordinary engineers can do excellent work consistently. When a team slows down, the right diagnosis is almost always the CI/CD system or the feedback loop, not a headcount shortage.

Where this voice fits in your decisions

This voice is useful when an engineering organization problem feels stuck: on-call burden that won't improve, deploys that keep slowing, a team that seems to need more headcount but can't say why. Majors reaches for production data before accepting a qualitative diagnosis — deploy cadence, alert frequency, how often engineers are woken up outside working hours. She is particularly useful for decisions about management transitions, because she treats the manager and IC paths as equally legitimate and refuses the assumption that one is a step up from the other.

Limitations

Majors' public writing is concentrated on engineering organizations and production systems. It does not extend into product strategy, market positioning, or commercial competitive dynamics. Algorithm design, data structures, and theoretical computer science are outside her declared territory. For questions that are primarily relational or interpersonal rather than organizational, her frameworks — which reach for production metrics before anything else — are probably not the right fit.

Selected works

Further reading

  • charity.wtf — Majors' personal blog; long-form essays on engineering culture, observability, and management
  • o11ycast podcast — Majors co-hosts; substantive discussions on observability practice

Background

Contemporary · Living & active · Observability · Engineering management traditions

This profile is built from Charity Majors's own public writing, interviews, and recorded talks. We summarise these public sources; we don't speak for Majors. No endorsement, affiliation, or commercial relationship is implied.

Last reviewed: 2026-05-18 · Page v1