Charity Majors

Key Insight: Team happiness is a downstream byproduct of structural success and growth-through-discomfort, not a management goal — leaders who optimize for how their reports feel will sacrifice the accountability and challenge that produce both performance and genuine fulfillment.

Charity Majors argues that 'if your team is happy, you're doing a good job' is a ZIRP-era management fallacy that conflates hedonic comfort with genuine flourishing. She traces how psychological safety — originally a research concept about enabling learning and performance — got detached from accountability and drifted into 'nobody should ever feel bad at work.' The core argument is that effective leadership prioritizes business outcomes and productive discomfort over managing feelings, and that we systematically misattribute structural outcomes to individual managers.

Key Insight: The most effective path to company-wide AI norms is bottom-up listening first — structured open sessions that surface real frustrations and build consensus, so that when formal norms arrive, the cultural groundwork is already laid.

Charity Majors answers a question about how companies can develop shared AI norms, drawing on Honeycomb's process of starting with open listening sessions before formalizing anything. She frames this as the opening salvo of a planned public dialogue with research psychologist Dr. Cat Hicks about norms, ethics, and learning in the AI era. The post touches on the broader industry anxiety around AI productivity expectations — and the uncomfortable truth that no one yet knows what 'enough' output looks like.

Key Insight: AI erodes trust not because of how much it is used, but because it is used in contexts where the value of communication is precisely that a specific human cared enough to think and write something themselves.

Charity Majors documents her evolving—and contradictory—relationship with AI-generated text: publicly insisting outcomes are all that matter while privately developing a visceral rage toward 'slop' in her inbox. She resolves the contradiction by proposing a personal-vs-functional communication framework: AI is fine in functional contexts (code, artifacts, shared docs) but corrodes trust in personal or relational contexts, where the value of communication is that a specific human thought or felt something. The post concludes that companies need explicit norms for AI communication because old defaults no longer apply and the breach is filling with hurt feelings.

Key Insight: The observability industry's dirty secret is that most newer vendors built on superior columnar architecture are voluntarily lobotomizing their products to compete on price, while the real opportunity — and the one Honeycomb has pursued for a decade — is competing on fundamentally better architecture that enables a different class of product.

Charity Majors uses Mat Duggan's viral post about ClickHouse to make a broader point: columnar storage-backed observability ('Observability 2.0') is architecturally superior to the three-pillars model, and Honeycomb has been saying so for a decade. Her real frustration is that newer vendors built on columnar stores are squandering their architectural advantage by marketing themselves as 'Datadog, but cheaper' instead of as a fundamentally different class of tool.

Key Insight: A mandate is not a blunt instrument of control but an honest funding mechanism — and refusing to issue one while expecting organizational change is a form of leadership cowardice that places the cost of transformation invisibly on individual employees.

Charity Majors argues that technology mandates — despite their bad reputation — are a legitimate and often necessary leadership tool because they serve as an explicit funding mechanism for organizational change. When companies require coordinated transformation on a tight timeline, mandates force honest conversations about tradeoffs, deadlines, and what success looks like. The alternative — telling employees to upskill "in their spare time" — is functionally a statement that the change isn't actually a priority.

Key Insight: An AI mandate is only defensible if leadership treats it as a genuine funding commitment — acknowledging real costs, allocating real time, and being honest with employees about what's now required; anything less is cowardice disguised as strategy.

Charity Majors offers a pragmatic defense of AI mandates as legitimate organizational funding mechanisms, arguing that a mandate is a way of acknowledging transformation costs and giving managers cover to let deadlines slip while building new skills. She draws a sharp distinction between mandates done right — with honest tradeoffs, allocated time, and shared accountability — and the cowardly version where leaders call AI existential but refuse to fund the change. The post challenges leaders to be consistent: either commit fully or admit it's a nice-to-have, but don't punish employees later for gaps leadership created.

Key Insight: Refusing to engage with AI on moral grounds is itself a moral failure — the ethical path is disciplined, collective engagement that shapes the technology, not performative abstention that leaves the field to bad actors.

Charity Majors argues that treating AI as uniquely evil and refusing to engage with it is a form of purity politics that is neither effective nor ethical — it just cedes influence to those with fewer scruples. She acknowledges real harms in how AI was built and deployed, but insists the right response is disciplined engagement, governance, and collective action, not boycotts or performative abstention. Her core call is to 'make AI boring' — to normalize accountable, social, disciplined use of AI rather than swinging between utopian hype and fundamentalist rejection.

Key Insight: Refusing to use AI is a performance of individual purity, not an effective ethical stance — the only way to govern powerful technology is to engage with it deeply enough to critique, shape, and hold it accountable.

Charity argues that AI, despite its genuine harms around training data, labor exploitation, and energy use, is fundamentally just technology — and that refusing to engage with it is both strategically ineffective and morally backward. She contends that tech workers have a particular responsibility to learn, use, and critically shape AI rather than pursue an unproductive 'purity politics' of abstention. The goal, she says, should be making AI boring: disciplined, accountable, and governable through collective action.

Key Insight: When AI makes code cheap and disposable, value shifts from the code itself to the durable understanding encoded in tests, specs, and observability—so AI demands more engineering discipline, not less.

Charity Majors responds to critics of her earlier AI piece, arguing that AI hasn't made software less of an engineering problem—it has made it more of one. Drawing parallels to the shift from handcrafted 'server pets' to immutable infrastructure, she contends that when code becomes cheap and disposable, value migrates from the code itself to the durable artifacts of understanding: tests, evals, observability, specs, and production behavior. Far from killing engineering discipline, nondeterministic AI-generated code finally forces engineers to adopt the rigorous practices (short feedback loops, behavioral testing, instrumentation) they should have had all along.

Key Insight: AI making code cheap and disposable doesn't reduce the need for engineering discipline — it exposes that the hard parts of software (shared understanding, production behavior, encoded knowledge) were never about writing code in the first place, and now demand more rigorous investment than ever.

Charity argues that AI making code generation cheap and disposable doesn't signal the end of engineering discipline — it demands more of it. Drawing on Chad Fowler's Phoenix Architecture ideas, she reframes code as a 'materialized view of understanding' that is useful while current but disposable when stale, and argues that the real product of software teams has always been shared understanding and production behavior, not lines of code. 2026, she contends, is shaping up as a return to rigor: investing in observability, behavioral tests, and fast feedback loops so that the knowledge in engineers' heads can be encoded into systems AI can actually use.

Key Insight: The AI enthusiast-skeptic divide is a structural feedback loop failure, not an ideological one—teams must share the full story of both wins and costs, then treat AI adoption as an engineering problem with concrete conditions for progress rather than a culture war.

Charity Majors argues that the growing divide between AI enthusiasts and AI skeptics in engineering teams is dangerous because both sides are responding to real existential threats—enthusiasts fear falling behind competitors, skeptics fear systems degrading into unmaintainable slop. She calls for closing the feedback loop between the two camps by telling the whole story (wins AND costs together), treating AI adoption as an engineering problem rather than a rhetorical debate, and leveraging engineering discipline to navigate the transition safely.

Key Insight: The AI adoption crisis in engineering teams is not a disagreement about facts but a structural feedback gap — wins are visible to enthusiasts and costs are invisible to them, while skeptics bear the costs without the wins — and fixing that asymmetry is the prerequisite for everything else.

Charity Majors diagnoses a dangerous split between AI enthusiasts and AI skeptics on engineering teams, arguing that both sides are responding to real, legitimate threats — enthusiasts fear being left behind by competitors, skeptics fear systems degrading into unmaintainable chaos. She proposes two concrete remedies: telling the whole story (wins AND costs), and reframing the debate as an engineering problem by asking 'what would it take to feel comfortable?' rather than trading rhetorical blows.

Key Insight: The three pillars observability model is not just inefficient but actively destructive — it eliminates context at write time, and no amount of AI-powered joining can restore what was never preserved, which makes it incompatible with the precision demands of agentic software development.

Charity argues that the root cause of observability failures isn't culture or tooling but a fundamental data architecture problem: the 'three pillars' model (metrics, logs, traces) destroys the relational context that makes telemetry data exponentially more powerful. As agentic AI workflows demand increasingly precise production validation, fragmented telemetry siloes become not just suboptimal but a critical bottleneck — AI agents are already abandoning three-pillars data in favor of richer, context-intact signals.

Key Insight: The three pillars model is not just an architectural inconvenience—it actively destroys the combinatorial relational value of observability data at write time, and as AI agents take over production validation, that destruction will become an insurmountable bottleneck.

Charity Majors argues that the three-pillar observability model (metrics, logs, traces) is fundamentally broken for software engineering because it destroys the relational context that makes telemetry data valuable. Data becomes combinatorially more powerful with each additional attribute, so siloing signals by type severs exactly the relational seams that matter most. With AI agents soon needing to validate high-velocity production changes autonomously, preserving that rich contextual fabric isn't optional—it's a prerequisite for precision.

Key Insight: SREs' career-long focus on outcomes over craft makes them uniquely positioned to lead — not resist — the AI transition, but only if they proactively engage rather than wait for change to be forced on them.

Charity Majors reflects on how her views on AI have shifted dramatically in the year since she co-keynoted SRECon25, where she urged skeptical SREs to engage with AI without being reflexively antagonistic. She now believes the center of gravity has fully shifted to AI/agentic workflows and advocates for engineers to proactively embrace this change rather than wait for it to be forced on them. SREs in particular, with their outcome-orientation and experience building guardrails, are well-positioned to lead in this new era.

Key Insight: SREs and operators are better positioned than most to thrive in the AI era because their entire career has been built around outcomes and reliability rather than code craft — the very orientation that matters most when AI makes code generation cheap.

Charity Majors reflects on how her views on AI have shifted dramatically in a year — from cautious pragmatism at SRECon25 to full acknowledgment that AI represents a fundamental paradigm shift in software development. She argues that SREs and operators are uniquely positioned to thrive because they have always been judged by outcomes rather than code craftsmanship. The post is essentially a revised keynote message urging technologists to proactively engage with AI rather than wait for it to be forced on them.

Key Insight: The biggest barrier to effective observability isn't technical implementation but the lack of shared strategic alignment between engineering teams and organizational leadership about what problem they're actually trying to solve.

Charity Majors describes how she had to scrap and rewrite an entire section of the second edition of Observability Engineering after realizing she was writing tactical advice for teams operating in a strategic vacuum. Feedback from readers revealed that the real problems weren't technical implementation challenges but deeply dysfunctional organizational buying processes and a lack of shared understanding between engineering and leadership about what observability even is and why it matters.

Key Insight: The bottleneck for good observability is almost never technical — it's the absence of shared vocabulary and strategic alignment between engineering teams and the executives who control decisions and budgets.

Charity Majors describes how, months past her deadline, she realized mid-completion that she had written the wrong observability book — tactical advice for engineering teams — when the real problem was strategic misalignment between those teams and the executives above them. Overwhelmed by reader emails describing top-down dysfunction, vendor overrides, and executives who hadn't touched code in decades, she scrapped her draft and rewrote the book to speak to CTOs, VPs, and technical decision-makers. The new structure frames observability through systems thinking and organizational learning speed rather than implementation details.

Key Insight: The observability landscape has transformed so dramatically since 2018—with OpenTelemetry winning, AI reshaping workflows, and the market co-opting the term—that a near-complete rewrite of the foundational book was necessary to reflect what observability actually means and requires today.

Charity Majors announces the near-completion of the second edition of 'Observability Engineering,' which is almost twice as long as the first despite Martin Fowler's advice to make it shorter. The new edition features 90% new material, a clearer mission focused on software engineers, and contributions from a diverse group of industry practitioners, reflecting how much the observability landscape has changed since 2018.

Key Insight: The observability field has matured enough that a second edition can finally say definitive things — OpenTelemetry won, most companies still lack real observability — but writing a technical book while the market is still in flux produces an unavoidably messy first draft.

Charity recounts meeting Martin Fowler, who advised that second editions should always be shorter — ironic since 'Observability Engineering, 2nd edition' is nearly twice as long as the first. She reflects candidly on why the first edition was a disorganized mess (the market definition of observability was shifting under them as they wrote), and explains how the second edition has a sharper focus on software engineers instrumenting and analyzing their own code, with OpenTelemetry's dominance now settled. The post ends on a cliffhanger about writer's block derailing the final governance chapters.

Key Insight: The software industry's cultural contempt for 'operations' is both cause and consequence of poor operational outcomes — reclaiming ops as a term of pride is a prerequisite for building operational excellence.

Charity Majors argues that the software industry has wrongly turned 'operations' into a dirty word, when ops is actually a vital separation of concerns — not a synonym for toil or a label for people who can't code. She traces this cultural rot partly to Google's SRE movement conflating 'writes code' with 'good' and 'does things by hand' with 'bad,' and calls for reclaiming operations as a term of pride to improve actual operational outcomes.

Key Insight: The industry's flight from the word 'ops' is not a harmless rebrand but a self-reinforcing cycle of disrespect that drives away talent and degrades operational excellence—and the only fix is to name the discipline proudly and build rigor around it.

Charity Majors argues that the software industry's systematic rebranding of 'ops' into DevOps, SRE, and platform engineering has caused a damaging feedback loop where ambitious engineers flee operational roles, operational excellence deteriorates, and the cycle repeats. She insists that dev and ops represent a legitimate separation of concerns—not a coding-vs-toil distinction—and that operations engineering is actually harder than product engineering because it absorbs the toughest technical problems. The solution is to reclaim 'operations' as a term of pride and build communities of practice around it.

Key Insight: Deploy freezes are a practical hack for teams lacking observability confidence, not a virtue — and if you must freeze, freeze merges instead of deploys to avoid a dangerous January pile-up of untested changes.

Charity Majors clarifies her stance on Friday deploy freezes, arguing they're a pragmatic workaround rather than a virtue to be celebrated. She offers two practical alternatives: freeze merges instead of deploys to prevent dangerous change buildup, and keep running the deploy pipeline without new code to avoid breakage from prolonged inaction.

Key Insight: Deploy freezes are legitimate hacks for teams without mature observability, but the right implementation is to freeze merges rather than deploys — and to keep running the deploy pipeline empty so inaction doesn't become its own source of outages.

Charity Majors walks back the perceived extremism of her infamous 'Friday Deploy Freezes are Exactly Like Murdering Puppies' post, clarifying that deploy freezes are pragmatically acceptable when teams lack proper observability tooling — but should never be treated as virtuous. Her core argument is that teams practicing deploy freezes should own them as the workaround they are, and that the real fix is to freeze merges instead of deploys, while keeping the deploy pipeline running empty.

Key Insight: AI has crossed the same inflection point cloud computing did around 2010 — it's no longer experimental but foundational — and skeptics must engage with it substantively rather than dismiss it as hype.

Charity Majors argues that 2025 marked the tipping point where AI shifted from experimental satellite technology to mainstream foundational tech in developer tools, drawing a direct parallel to how cloud computing made the same transition around 2010. She acknowledges the bubble and hype but insists that froth doesn't disprove underlying value, and urges skeptics to engage rather than dismiss.

Key Insight: AI has crossed the same inflection point cloud crossed in 2010 — the question is no longer whether it's real, but how to engage with it rigorously and honestly.

Charity Majors draws a direct parallel between AI in 2025 and cloud computing in 2010, arguing that AI has crossed the threshold from experimental satellite technology to mainstream, foundational infrastructure — at least for developer tools. Drawing on her firsthand experience watching cloud displace datacenters at Linden Lab, she argues that the existence of hype and a bubble does not negate the existence of genuine, lasting value.

Key Insight: Going dark on social media may feel virtuous but is a professional abdication for anyone whose job depends on shaping technical discourse — engaging through an imperfect platform beats not engaging at all.

Charity Majors explains her decision to move from WordPress to Substack despite criticism that the platform supports extremist content, arguing that she has been neglecting her professional obligation to engage actively with the tech community. She concludes that Substack occupies a morally grey but acceptable position compared to explicitly extremist platforms, and that reducing friction to posting is critical for her to do her job. She offers practical mitigations for readers who remain uncomfortable with the platform.

Key Insight: Sometimes the most responsible professional choice is to prioritize reaching your audience over platform purity, especially when silence means failing to do your job.

Charity Majors explains her decision to move from WordPress to Substack despite criticism about the platform's content moderation policies. She argues that she's been neglecting a core part of her job as Honeycomb's CTO by going dark on social media, and needs a lower-friction platform to re-engage with the mainstream tech community. She acknowledges the ethical concerns but concludes Substack is far from being a platform that solely exists to support extremism.

Key Insight: Publishing friction kills writing output, and platform migration — even after a decade — is worth it to remove barriers between ideas and audience.

Charity Majors announces she's moving her blog from WordPress to Substack after a decade, citing WordPress friction and Substack's vibrant tech writing ecosystem. She notes she's been working on the second edition of 'Observability Engineering' and has accumulated ideas she's eager to publish once the drafts are done.

Key Insight: The term 'observability' has been hollowed out by vendors and executives to mean basic monitoring, and fixing this requires communicating observability's true value — understanding per-customer service quality as a systems problem — directly to engineering executives in business terms, not just to engineers in technical ones.

Charity Majors argues that the term 'observability' has been co-opted by vendors and executives who use it to describe basic monitoring tools, while the actual problem observability was meant to solve — understanding service quality from each individual customer's perspective — remains unaddressed by most 'observability' products. She coins the term 'o11ywashing' (analogous to 'cloudwashing') to describe this phenomenon and argues Honeycomb needs to better communicate observability's true value to executives, not just engineers.

Key Insight: The 'pillars of observability' is a vendor marketing construct that justifies expensive siloed tooling; the technically superior approach is unified storage where all telemetry signals live together, enabling seamless debugging through zoom-in/zoom-out rather than hopping between disconnected data stores.

Charity Majors argues that the 'three pillars of observability' (metrics, logs, traces) is a marketing construct, not a technical one, used by vendors to justify selling siloed products at inflated prices. She advocates for a unified storage model (o11y 2.0) where all telemetry signals are stored together in one database, enabling seamless zoom-in/zoom-out debugging instead of bunny-hopping between disconnected tools. The piece also addresses misconceptions about OpenTelemetry reinforcing the pillars model, arguing it actually unifies signals through shared distributed context.

Key Insight: Vendor engineering — the art of evaluating, buying, and managing software tools — is an underrated, high-leverage skill that lets staff+ engineers develop executive-level strategic thinking while remaining individual contributors.

Charity Majors asks her audience for help answering specific questions about observability tooling for the second edition of her book, covering migrations, cost management, observability teams, and build-vs-buy decisions. She frames this as a follow-up to an earlier call for advice on software buying, which she argues is one of the highest-leverage activities a senior engineer can perform.

Key Insight: The observability field has matured so rapidly that even its leading practitioners need to crowdsource expertise on the governance, purchasing, and organizational challenges that now define how companies adopt observability at scale.

Charity Majors announces she's been working on the second edition of 'Observability Engineering' and is adding a new section on 'Observability Governance.' She's asking for help from experienced software buyers because she lacks personal experience purchasing enterprise software at scale.

Key Insight: The grueling process of migrating Parse's API from Ruby to Go — and the production traffic diffing tools required to do it safely — directly seeded the observability philosophy that became Honeycomb.

Charity Majors resurrects a lost blog post from her Parse days documenting the two-year rewrite of Parse's API from Ruby on Rails to Go. The migration was driven by Rails' one-process-per-request model failing to scale during hockey-stick growth, and the team used production traffic shadowing to catch undocumented Rails behaviors. The experience of diffing individual API responses field-by-field during the migration directly inspired what would become Honeycomb's approach to observability.

Key Insight: People with strong ethics should actively pursue power and build institutions rather than ceding business and technology to those without principles, because creation and institutional stewardship — not critique — is what brings ideals to life.

Charity Majors reflects on her unconventional path from a fundamentalist homeschooled upbringing in rural Idaho to becoming a tech company founder, arguing that work can be a source of liberation, meaning, and personal growth rather than mere exploitation. She makes the case that people with strong ethics should pursue business and institutional power rather than ceding it to those without principles, and that the second half of a career should be oriented around purpose and building things of enduring value.

Key Insight: The mark of a great engineering organization isn't hiring the most brilliant individuals, but building sociotechnical systems where normal engineers can consistently ship, learn, and move the business forward.

Charity Majors argues that the tech industry's obsession with '10x engineers' is misguided because individual engineers don't own software—teams do. She makes the case that truly great engineering organizations are ones where normal, workaday engineers can consistently ship code and have business impact, rather than orgs that depend on a few brilliant individuals. The path to high performance is building better sociotechnical systems (fast deploys, observability, guard rails) that enable normal people to do great work.

Key Insight: Trust your early gut feeling about a new job — especially as a manager, where alignment with the company isn't optional but is the fundamental nature of the work itself.

Charity Majors argues that you typically know within the first week whether a new job is right for you, and that gut feeling rarely changes over time. She emphasizes this is especially true for managers, since alignment with the company is the core of the management job in a way it isn't for ICs. She advises trusting early impressions and learning from bad fits rather than waiting for things to improve.

Key Insight: Well-intentioned pronoun mandates at work can backfire by pressuring vulnerable people, activating gender bias, and destroying the very social signals that help queer people identify genuine allies.

Charity Majors argues against mandating pronoun sharing at work while supporting the normalization and safety of voluntary disclosure. Drawing from her own experience as a queer person with complicated feelings about gender identity, she explains how forced pronoun sharing can backfire by pressuring people who are questioning or transitioning, priming gender bias, and eliminating useful signal about genuine allyship.

Key Insight: The heuristics tech workers use to judge talent are usually self-serving rationalizations that reinforce their own backgrounds, and the honest response to career success in tech is humility about how much luck and timing mattered.

Charity Majors reflects on how she and her college-dropout peers in early Silicon Valley developed an unfounded contempt for CS degree holders, using cherry-picked evidence to justify their own paths. She draws a broader lesson about how people in tech construct self-serving heuristics to validate their belonging, and argues for humility given the enormous role of luck and timing in tech careers.

Key Insight: The writing that endures is the writing you ship in durable form, not the writing that feeds the dopamine cycle of social media — and learning to ship without those crutches requires deliberately embracing imperfection.

Charity Majors reflects on how Twitter was essential to both Honeycomb's growth and her personal creative process, serving as a dopamine source for her undiagnosed ADHD. With social media fragmented and her old writing workflow broken, she commits to a three-month experiment of writing shorter, faster blog posts weekly — learning to ship without the crutch of Twitter threads or deadline-driven panic.

Key Insight: The observability industry is converging on unified storage models with telemetry pipelines and tail-based sampling as cost control levers, but the real value lies in workflows and context, not just reducing spend.

Charity Majors responds to Matt Klein's claim that bitdrift's ring buffer model deserves the 'Observability 3.0' label, while reflecting on the industry's shift from multiple pillars to unified storage models. She argues that while Klein raises valid points about cost control, his mobile-first approach of not sending telemetry by default doesn't translate well to complex, multi-tenant distributed systems that require real-time debugging. The industry is moving toward a data lake model with telemetry pipelines, tiered storage, and tail-based sampling as the next evolution of cost control.

Key Insight: True meritocracy demands active inclusion and bias counteraction — not corporate DEI theater — and the most powerful way to spread these values is to build winning companies that authentically embody them.

Charity Majors argues that corporate DEI programs were always ineffective symbolic gestures, but the ideals underlying them — inclusion, equity, and counteracting bias — are essential to building genuinely meritocratic, high-performing teams. She contends that real cultural change came from hearts and minds being changed through storytelling and persuasion in the 2010s, not from corporate mandates, and that the best way to spread these values is to build successful companies that embody them.

Key Insight: The real observability revolution isn't about non-engineering teams accessing telemetry data — it's about engineering teams finally integrating business context into their own tooling so they can speak the language of the business and earn a seat at the executive table.

Charity Majors pushes back against the 'Observability 3.0' framing proposed by Hazel Weakly, arguing that the critical advances described are already part of the Observability 2.0 generational shift already underway. She contends that the real measure of success isn't non-engineering functions interrogating engineering data, but rather engineers learning to integrate business data into their own telemetry and describe their work in the language of the business.

Key Insight: The 'founder mode' philosophy contains valid leadership principles about staying engaged with details and hiring for strengths, but its dangerous packaging as CEO-centric mythology ignores that organizational dysfunction is a systems problem driven by leadership choices, not proof that everyone else is mediocre.

Charity Majors dissects Brian Chesky's 'founder mode' philosophy and hiring advice, acknowledging solid principles buried within but sharply criticizing his complete lack of accountability for Airbnb's organizational failures, his contemptuous treatment of employees, and the dangerous CEO-centric mythology that Silicon Valley continues to propagate. She extracts actionable lessons on hiring, leadership presence, and organizational efficiency while arguing that there are many valid architectural approaches to running a company.

Key Insight: The entire observability 1.0 vs 2.0 distinction reduces to one technical question—whether your telemetry is stored once as wide structured events (single source of truth) or scattered across multiple pillars and tools—and every other advantage of 2.0 flows as a consequence of that single architectural choice.

The fundamental distinction between observability 1.0 and 2.0 is not a marketing buzzword but a technical one: 1.0 scatters telemetry across multiple pillars, tools, and formats (many sources of truth), while 2.0 stores everything as wide structured log events in a single source of truth. Everything else—better developer workflows, sustainable cost models, high-cardinality exploration—flows as a consequence from this one architectural difference.

Key Insight: Sustainable employee retention comes from building fair, transparent systems for compensation and career development—not from heroic counter-offers that reward brinksmanship and erode organizational trust.

Charity Majors argues that companies should build fair, transparent compensation systems and invest in ongoing career development rather than relying on heroic counter-offers when employees threaten to leave. She contends that healthy turnover is natural, that managers should proactively identify superstars and single points of failure, and that exceptions to compensation frameworks—while occasionally necessary—compound into cultural damage and cynicism.

Key Insight: The shift from metrics-based observability to wide structured log events isn't an incremental improvement but a breaking change that unlocks fundamentally different — and vastly simpler — ways of understanding, debugging, and developing complex software systems.

Charity Majors argues that observability tooling needs a version bump: 'Observability 1.0' (metrics, logs, traces as separate pillars) is fundamentally incompatible with 'Observability 2.0' (wide, structured log events as a single source of truth). She contends that metrics-based tools are increasingly expensive and inadequate for understanding complex modern systems, while structured event-based approaches offer superior debugging, cost efficiency, and developer experience.

Key Insight: Banning political speech at work is not principled neutrality — it's leaders using their power to avoid the hard, uncomfortable work of actually leading through conflict and listening to their employees.

Charity Majors argues that leaders must prioritize business success above all else, but that banning political speech at work is a cowardly cop-out that protects CEOs from uncomfortable feedback rather than protecting the mission. She advocates for a middle path: maintaining neutral, mission-focused workspaces while genuinely listening to employees and doing the hard work of navigating tensions rather than silencing them.

Key Insight: Generative AI makes the already-easy part of software engineering (writing code) even easier, but does nothing for the hard parts (managing complex systems), so using it as justification to stop hiring junior engineers is a catastrophic mistake that will destroy the industry's pipeline of future senior talent.

Charity Majors argues that the tech industry's belief that generative AI can replace junior engineers is dangerously misguided, because writing code is the easiest part of software engineering while the hard parts—operating, understanding, and managing complex sociotechnical systems—require human judgment built through years of apprenticeship. By refusing to hire and train junior engineers, companies are cannibalizing their own future pipeline of senior engineers.

Key Insight: The observability cost crisis isn't primarily about the dollar amount on the invoice—it's that the traditional multi-pillar approach structurally guarantees that costs and value move in opposite directions, while a single-source-of-truth approach aligns them.

The traditional 'three pillars' approach to observability (metrics, logs, traces) creates a cost crisis where organizations pay to store the same telemetry data multiple times across different tools, with costs growing several times faster than traffic while the value derived actually decreases. Charity argues that 'observability 2.0' built on arbitrarily-wide structured log events as a single source of truth fundamentally changes the cost-value equation, making telemetry more valuable as you add more data rather than less.

Key Insight: Engineering managers are not overhead but a necessary abstraction layer in self-organizing systems — they reduce coordination costs, prevent information overload, and ensure that building the organization is someone's primary job rather than no one's.

Charity argues that engineering managers are essential even at startups because hierarchy is a property of self-organizing systems that reduces coordination costs and information overload. She makes the case through systems theory (managers coordinate between teams and reduce context switching) and through pragmatism (most orgs have managers because the model is well-understood, and manager-free experiments have repeatedly failed).

Key Insight: The most compelling reason to try engineering management isn't career advancement but that it forces you to develop foundational interpersonal skills — self-regulation, self-awareness, hard conversations, boundary-setting — that make you better at all of life's relationships.

Charity Majors argues that while the tech industry has rightly created alternatives to management as the only career path, engineering managers remain critically important as force multipliers. She makes the unconventional case that the best reason to try management isn't career advancement but personal growth — management forces you to develop foundational life skills like self-regulation, self-awareness, hard conversations, and boundary-setting that improve all your relationships.

Key Insight: LLMs' inherent nondeterminism will force the entire software industry to adopt observability-driven development and production-first feedback loops—modern practices that most teams have resisted despite knowing they should embrace them.

Charity Majors argues that LLMs are nondeterministic black boxes that cannot be adequately tested or debugged using traditional software engineering techniques, making observability-driven development essential. She contends that the shift toward LLMs will force engineering teams to adopt modern practices like shipping early, observing production behavior, and tight feedback loops—practices that benefit all software development but that most teams have been slow to adopt.

Key Insight: Rebuilding trust requires deliberately overcommunicating positive intent and engineering frequent low-stakes positive interactions, because in a low-trust environment every neutral statement will be read as an attack.

When trust is low in a working relationship, every communication gets interpreted in the worst possible light, creating a death spiral. The post offers concrete tactical advice for rebuilding trust through overcommunication, tentative language, engineered positive interactions, and explicitly stating intent — drawn from the author's experience rebuilding her fractured cofounder relationship.

Key Insight: The most common rookie manager mistake is over-optimizing for your team's happiness and loyalty at the expense of organizational effectiveness, and the hardest lesson is that truly caring for people sometimes means letting them struggle.

New managers often over-optimize for being liked by their direct reports while neglecting the broader organizational responsibilities of the role. Helicopter management—coddling people, preventing failure, and over-identifying with your team—can harm both the organization and the individuals you're trying to help. Great management requires balancing care for your team with strategic direction, stakeholder management, and serving the organizational system fairly.

Key Insight: Driving change without authority requires building credibility through good judgment, socializing ideas one-on-one before group settings, and picking battles that deliver visible wins for the team.

Charity Majors addresses how engineers at different career stages can drive change on their teams without formal authority. She argues that influence comes from good judgment, strategic relationship-building, and picking the right battles, offering tactical advice for junior engineers, new tech leads, and managers on how to introduce changes effectively.

Key Insight: Workplace rituals that transform failure from shameful to celebratory are powerful tools for building psychologically safe engineering cultures, but they must evolve as our understanding of workplace dynamics matures.

Charity Majors recounts how Linden Lab's tradition of wearing Shrek ears after breaking production created a psychologically safe culture around failure long before 'blameless retrospectives' existed as a concept. The opt-in ritual transformed what could be shame into celebration, teaching engineers that failure is inevitable, constant, and even funny. While acknowledging the practice might not translate to modern workplaces, she argues it was a brilliant piece of social engineering that made transparency about mistakes infectious across the entire company.

Key Insight: Great workplace culture isn't something leaders manufacture — it emerges naturally when they focus on organizational health and business success, creating the stable foundation that frees people to bring their own joy and creativity.

Charity Majors argues that companies should 'choose boring technology culture' by focusing on organizational health rather than cultural innovation. She distinguishes between formal organizational culture (which should be stable and load-bearing) and informal culture (which emerges naturally from people when the formal structure is healthy). The core thesis is that business success earns you innovation tokens, and most companies should spend those tokens sparingly on culture, instead focusing on executing well.

Key Insight: The open-source world's reflexive contempt for software vendors is a self-limiting bias that ignores how much value paid software creates, and vendor-side engineers can maintain credibility by leading with transparency about their biases rather than hiding them.

Charity Majors reflects on her journey from being an open-source zealot who dismissed software vendors to becoming one herself, and the karmic experience of having her expertise discounted because she's now 'selling something.' She offers practical advice for vendor-side engineers to maintain credibility by leading with bias disclosure, engaging competitors' strongest arguments, and being generous with expertise.

Key Insight: Architecture is a core engineering skill that should be embedded in teams, not externalized into a separate role that severs the feedback loop between decision-making and living with the consequences.

Charity Majors argues that the 'architect' role is often a locus of organizational dysfunction, where brilliant engineers are turned into glorified project managers who lose their technical skills over time. She contends that architecture should be a core engineering skill embedded in teams, not a separate role that unbundles decision-making authority from responsibility for results. The post explores several healthier patterns including embedded architects, architecture working groups, and engineer-architect pendulum swings.

Key Insight: Decoupling deploys from releases via feature flags transforms shipping from a high-stakes engineering event into a routine, low-risk operation that non-engineers can control.

Charity Majors argues that organizations should decouple deploys (building, testing, and rolling out code) from releases (changing user experience), because using the deploy process to control what users see is slow, flaky, and unreliable. Feature flags solve this by letting teams deploy code continuously while controlling user-visible changes independently, enabling progressive delivery and safer testing in production.

Key Insight: Distributed companies must treat in-person gatherings as essential infrastructure, not perks, and can do so responsibly by taking a layered approach to safety and being honest about what worked and what didn't.

Charity Majors describes how Honeycomb organized their first all-hands offsite in three years, detailing their layered COVID safety approach including testing, CO2 monitors, outdoor spaces, and social distancing options. She argues that in-person gatherings are not optional luxuries for distributed companies but critical necessities, and shares a detailed retrospective on what worked and what they'd improve.

Key Insight: The true measure of engineering leadership isn't how many people you manage, but how much impact you deliver per person — every achievement should be evaluated relative to the resources consumed to produce it.

Charity Majors argues that engineering leaders should be evaluated not by the size of their organizations, but by the ratio of impact to team size. She challenges the empire-building instinct in management, proposing that delivering outsized results with small, lean teams is a far better measure of leadership skill than simply accumulating headcount.

Key Insight: Platform engineering is the natural successor to DevOps, shifting the focus from managing infrastructure to enabling developers to self-serve and own their code in production through curated, product-like internal platforms.

Charity Majors argues that the operations profession is bifurcating: infrastructure expertise is moving to cloud providers while a new discipline called platform engineering is emerging to help software engineers self-serve and own their code in production. Platform engineering teams function as internal product teams that bridge third-party services and developer needs, representing the natural evolution of DevOps in a cloud-native world.

Key Insight: Organizations should treat hierarchy as a neutral tool for coordination rather than a status ladder, and must actively distribute power and transparency to technical contributors so people choose roles based on curiosity and fulfillment rather than chasing status.

Charity Majors argues that organizational hierarchies become toxic when conflated with social dominance and status, pushing talented people like her friend Molly into management roles they don't actually want. She advocates for treating hierarchy as a neutral organizational data structure rather than a measure of human worth, and calls for radical transparency, distributed decision-making power, and career paths that let people follow intrinsic motivation rather than climbing ladders by default.

Key Insight: Before delivering critical feedback, consider whether the ratio of critique to affirmation you've given someone accurately represents how much you actually value them—because they almost certainly don't know.

The post argues that people giving feedback should be mindful of the ratio of critique to affirmation they deliver, because recipients often don't know how valued they are and only remember the criticisms. Charity offers specific techniques for making positive feedback land—being specific, using the SBI framework for praise, grounding critique in overall reaction, and giving feedback that helps people grow.

Key Insight: True observability requires storing arbitrarily wide, structured raw events per request per service hop — not metrics, not unstructured logs, not pre-aggregated data — because only raw events let you ask questions you never anticipated.

Charity Majors argues that modern distributed systems require a fundamental shift from traditional monitoring and metrics to observability built on arbitrarily wide, structured raw events. She explains that as monoliths gave way to microservices, old debugging tools like printf and gdb became insufficient, and engineers must adopt structured events that capture rich context per request per service hop. The post lays out the technical requirements for true observability: structured, wide, raw, sampled events organized by request ID with trace awareness.

Key Insight: Engineering team rituals that emerge organically from the team itself create a powerful sense of belonging that transforms a job into a meaningful experience, and the best ones normalize failure, celebrate unglamorous work, and make no sense to outsiders.

Charity Majors reflects on the power of team rituals to create belonging, drawing from a book on workplace rituals and her own extensive experience at Linden Lab and Parse/Facebook. She argues that the best rituals emerge bottoms-up from teams rather than top-down from executives, and that they disproportionately contribute to the most meaningful workplace memories.

Key Insight: The best path back from CTO to engineer is full immersion in daily hands-on coding with a great team, starting fresh with new technologies rather than trying to resume where you left off, because rebuilding tactical skills and reconnecting with the emotional reality of shipping code matters more than preserving your title.

A former CTO asking about returning to engineering should come back as a regular software engineer, not a staff+ role, and spend at least 6 months doing hands-on daily coding with a great team. The transition requires not just refreshing technical skills but re-acclimating to the rhythms of deep focus work, reconnecting with curiosity, and rebuilding empathy for production code — similar to how moving into management required learning an entirely different way of working.

Key Insight: On-call suffering is never just a technical problem — it's a management accountability problem, and the two-way pact between engineering ownership and management support must be enforced for on-call to be sustainable.

On-call pain is not an inevitable cost of owning code in production — it's a sociotechnical problem requiring both technical fixes (alert discipline, SLOs, proper tooling) and organizational solutions (management accountability, fair rotations, humane policies). Engineering owns their code, but management owns the responsibility to make on-call sustainable, and failure to do so is a five-alarm fire that should be fixed with urgency.

Key Insight: The leap from engineering manager to director requires a fundamental identity shift—from leading a high-performing team to running the business—and most managers underestimate how different the job really is.

The post argues that engineering managers aspiring to become directors should understand that the director role is fundamentally different from management—not just a senior version of it. Directors run the business, manage managers rather than ICs, and must excel at managing up, out, and across the organization. Getting promoted internally is preferable to being hired into a director role at a new company, and candidates should proactively signal their career goals and demonstrate org-level impact.

Key Insight: Metrics aren't bad—they're just scoped to aggregate system health and third-party infrastructure, while your own code demands the richer, event-level understanding that only observability provides.

Charity Majors walks back her inflammatory anti-metrics rhetoric, clarifying that metrics aren't worthless—they're just the wrong tool for observability. She draws a clear line between 'your code' (which demands observability with rich, high-cardinality events) and 'other people's code' (third-party infrastructure where metrics and monitoring are the right fit).

Key Insight: The engineer-manager pendulum's two anxieties are asymmetric: good managers will always be recruited back into management, but technical skills genuinely decay, making it essential to strategically refresh them for both effectiveness and career optionality.

The post addresses two common anxieties people face when swinging between engineering and management roles: the fear of never getting another management opportunity, and the fear of being too rusty to return to engineering. Charity argues the first fear is misplaced since good managers are always in demand, while the second is more valid since technical skills genuinely erode over time. She advises engineers to be strategic about refreshing technical skills for both effectiveness and job security.

Key Insight: Job candidates should flip the interview power dynamic by rigorously evaluating companies through backchannels, probing questions about failure and diversity, and concrete signals like deploy frequency — and should leave without guilt if what they find doesn't match.

Charity Majors provides a comprehensive guide for job candidates to evaluate whether a company is healthy or toxic during the interview process. She argues that candidates hold more power than they realize and should rigorously scrutinize potential employers through backchannel research, probing questions about diversity, business health, team dynamics, and engineering practices. The post emphasizes that interviews are a two-way street and encourages people to leave quickly if a new job feels wrong.

Key Insight: True engineering excellence requires treating every business function as an equal partner, because without business success, even the best engineering culture becomes a cautionary tale.

Charity Majors argues that 'engineering-driven' culture often becomes 'engineering-supremacy,' where technical functions are valued above all others to the detriment of the business. She advocates for equal respect across all functions — engineering, product, design, sales, marketing — because business success is what ultimately enables a company to pursue its mission and values.

Key Insight: Resistance to frequent, automated deployments is driven not by legitimate technical concerns but by a catalog of cognitive biases that make inaction feel safer than action, when in reality speed and small changes are what make deploys safe.

Charity Majors catalogs the many cognitive biases that lead engineering teams to adopt overly cautious deployment practices like 'no Friday deploys,' arguing that every common justification for slowing down deployments is materially false. She frames resistance to continuous deployment not as rational risk management but as emotional reactions retroactively dressed up in noble-sounding language.

Key Insight: Organizational buzzphrases like 'breaking down silos' are red flags that signal someone lacks the specific, hard-won experience of actually diagnosing and solving complex communication and collaboration problems.

Charity Majors argues that the phrase 'breaking down silos' is a meaningless cliché that substitutes for actual critical thinking about organizational communication problems. She contends that real solutions to collaboration problems are complex and specific, and people who use vague buzzphrases almost never have the hands-on experience of actually solving these problems.

Key Insight: Including operations questions in software engineering interviews isn't just about evaluating technical breadth — it's a cultural signal that sets expectations about code ownership and operational responsibility from the very first interaction with a candidate.

Charity Majors argues that software engineering interviews should include operations questions, just as ops/SRE interviews now include coding questions. She contends that operational excellence is everyone's responsibility, and that interviewing for ops knowledge both identifies engineers who will own their code in production and sets cultural expectations from day one.

Key Insight: The true cost of observability is never just the vendor bill — organizations that cheap out on tooling pay far more in hidden engineering time, attrition, and degraded capability than they ever save.

Charity Majors argues that organizations should spend 20-30% of their infrastructure costs on observability, pushing back against the common instinct to minimize tooling spend. She makes the case that 'saving money' on observability by using free/open-source tools often costs far more in hidden engineering time, recruitment, and degraded developer experience.

Key Insight: Dashboards seduce engineers into pattern-matching against past incidents rather than methodically investigating present ones, and the industry needs to replace this habit with queryable, exploratory tools that support real debugging of unknown-unknowns.

Static dashboards are poor debugging tools because they encourage pattern-matching against historical answers rather than methodical investigation of current problems. While useful as high-level system health overviews, dashboards strip away the connective tissue between events, making it impossible to correlate attributes or follow a trail of breadcrumbs to diagnose novel issues. The industry needs to move toward queryable, exploratory interfaces that let engineers interrogate their systems rather than scan pre-built graphs.

Key Insight: Instead of planning careers around hierarchical advancement, engineers and managers should cultivate self-knowledge, preserve optionality by rotating between roles, and have the courage to choose work they genuinely love over titles and status.

Charity Majors maps out seven common career inflection points for engineering managers, arguing against rigid career planning and hierarchical ladder-climbing in favor of self-knowledge, preserving optionality, and following intrinsic motivation. She emphasizes that management is a career change (not a promotion), advocates for the engineer-manager pendulum, and urges people to prioritize doing work they genuinely love over chasing titles and status.

Key Insight: Engineering management career development should focus on mastering the craft itself — peer networks, confrontation skills, self-awareness, and sociotechnical thinking — rather than chasing promotions up the org chart.

Charity Majors lays out a practical roadmap for engineering managers to develop their careers, arguing that growth should focus on craft mastery rather than climbing the org chart. She covers concrete skills from confrontation and public speaking to understanding power dynamics and optimizing sociotechnical systems, emphasizing that most managers were dropped into the role with little guidance.

Key Insight: Engineering management should be treated as a lateral career change that prioritizes internal candidates with strong relationships and team trust, not as a promotion for your best technical performer.

When hiring an engineering manager, companies should always give internal candidates first consideration before looking externally, since effective management requires deep knowledge of the tech stack, existing relationships, and team trust. The post argues that management should be treated as a lateral career change rather than a promotion, and that the best engineer is rarely the right choice for manager.

Key Insight: Exit interviews should be treated not as a ritual to survive unscathed but as a strategic opportunity to drive change, structured with written evidence and delivered to people who actually have power to act.

Charity Majors advises someone preparing for an exit interview to focus not on self-protection or bridge-preservation, but on being effective. She provides tactical advice for structuring exit feedback as a written, evidence-based case that ties toxic behavior to material consequences and delivers it to people with actual power to act on it.

Key Insight: Fulfilling your core job responsibilities is the foundation that makes all your other valuable contributions — glue work, DEI labor, mentoring — count toward career advancement rather than being seen as distractions from unfinished work.

Charity Majors responds to the backlash from her previous post about prioritizing your core job responsibilities, addressing objections about glue work, DEI labor, gendered dynamics, and management failures. She clarifies that while extracurricular work like ERGs and mentoring should factor into promotions, they cannot substitute for fulfilling the technical requirements you were hired for. She acknowledges her advice assumes a high-trust environment and encourages engineers to take ownership of career clarity even when managers fail them.

Key Insight: Extracurricular contributions only count as signs of initiative when you're already meeting expectations on the core work you were hired to do — otherwise they become evidence of poor prioritization.

Charity Majors argues that no amount of extracurricular contributions — interviewing, mentoring, speaking, community building — can compensate for failing to deliver on your core job responsibilities. She illustrates through a story how high-visibility side work actually becomes evidence against you when your primary deliverables are slipping. The post urges engineers to ruthlessly prioritize their 'One Job' first, and to honestly reassess whether they're in the right role if they chronically can't find motivation for it.

Key Insight: Deploy delays don't just slow you down linearly — they create compounding organizational pathologies that force exponential growth in headcount and complexity to accomplish the same work a small team with continuous deployment could handle.

Teams that fail to implement true continuous deployment — where every merge auto-deploys to production in under 15 minutes — pay an enormous hidden cost in engineering headcount and organizational complexity. The delay between writing code and shipping it creates compounding pathologies that force teams to grow far larger than necessary to accomplish the same work.

Key Insight: Interviews are a two-way street, and candidates can reliably detect bad management culture by asking pointed questions about how work gets allocated, whether managers can say no directly, and whether management is treated as a peer role rather than a promotion.

The post provides a comprehensive guide of interview questions candidates should ask to evaluate whether a potential manager and management culture will be healthy or toxic. Charity argues that candidates should treat interviews as a two-way evaluation, offering specific questions for both managers and engineers that reveal red flags like involuntary managers, lack of career development paths, and evasive communication styles.

Key Insight: Early-career engineers should treat compensation as a tool for career optionality rather than a number that must always go up, because optimizing for salary over experience in your first decade can trap you in roles that stunt long-term growth.

Charity Majors argues that early-career engineers should prioritize experience and career growth over salary optimization. She pushes back against the common recruiter advice to never go backward on compensation, framing it as short-sighted thinking that treats salary as a one-way escalator rather than a tool for building long-term career value.

Key Insight: Engineering managers need both technical and social skills because modern software teams operate within complex sociotechnical systems where separating those domains creates fragile organizational structures and muddied accountability.

Charity Majors argues that engineering managers must have solid technical foundations, not just management skills, because modern engineering work involves complex sociotechnical systems where social and technical problems are inseparable. While non-technical managers can occasionally succeed through either exceptional personal qualities or organizational structures that compensate for their gaps, these are exceptions that shouldn't define hiring strategy.

Key Insight: Managerial worth is measured not in daily visible output but in the long trail of trust, team health, and crisis resilience you build over years — and pretending you don't need recognition for that work is dishonest.

The post addresses the common struggle managers face in feeling worthwhile when they're no longer the ones building things. Charity argues that managerial satisfaction is fundamentally different from engineering satisfaction — it's slower, less visible, and lacks the dopamine drip of shipping code. She offers practical frameworks for locating your impact in big-picture outcomes, small human moments, and crisis situations, while calling out the performative selflessness managers are expected to display.

Key Insight: A 15-minute CI/CD pipeline isn't a luxury—it's the foundation that aligns everything else for engineering team success, and most teams who think they can't achieve it are wrong.

Charity Majors argues that CI/CD lead time—from code merge to production deploy—should be under 15 minutes, and that achieving this is central to building high-performing engineering teams. She provides a comprehensive, community-sourced catalog of anti-patterns and bottlenecks that slow down build pipelines, organized by category from test design to AWS infrastructure choices.

Key Insight: True engineering seniority isn't earned by becoming the expert on one system — it's forged by starting over multiple times across different teams and stacks until you can succeed anywhere.

Charity Majors advises an engineer who became the most senior person on their team by default (at their first job) to leave and start over elsewhere. She argues that true seniority comes not from deep familiarity with one system, but from having learned and leveled up across multiple teams, stacks, and organizations over 5-8 years.

Key Insight: On-call is a mutual compact where management owes engineers sustainable conditions — protected time, good tooling, alert tracking, and treating every page as urgent — and failing this obligation justifies engineers walking out the door.

On-call responsibility is a two-way compact: engineers should own their code in production, but management must ensure on-call doesn't suck by investing in tooling, tracking alerts, protecting on-call time from project work, and treating every out-of-hours page as urgent. Managers who fail to hold up their end of this bargain deserve to lose their engineers.

Key Insight: Career progression depends less on individual merit and more on whether your current environment has the structural oxygen — the right ratio of work, people, and need — to support your advancement.

Engineers frustrated about slow career progression often overlook that promotion opportunities are situational — not every company has the right openings, oxygen, or need at every level at every time. Title inflation from making exceptions undermines leveling systems, and engineers should strategically evaluate whether their current environment actually offers the growth opportunities they seek rather than passively waiting to be promoted.

Key Insight: The cultural perception of management as a promotion traps bad managers in roles they shouldn't hold and starves organizations of great technical leaders who fear the stigma of "stepping down" — and companies must actively restructure power, pay, and prestige to break this cycle.

Charity Majors argues that the perception of management as a promotion is the root cause of bad managers persisting in tech, because returning to engineering is seen as a demotion that nobody wants to accept. She advocates for treating management as a lateral career change and support role, not a hierarchical step up, and provides a concrete roadmap for companies to restructure power dynamics so that engineering and management are seen as equally valuable but different paths.

Key Insight: Centralized war rooms for monitoring are actively harmful because they break the essential feedback loop between developers and the production behavior of their code, and no amount of dashboard-watching can replace the contextual knowledge of the engineers who built the systems.

Charity Majors tears apart the concept of centralized 'command center' war rooms for monitoring applications, arguing they are a waste of money rooted in outdated thinking. She identifies two fatal flaws: graphs can be automated and only catch known problems, and the people watching graphs aren't the ones who can actually fix issues. The approach actively harms engineering feedback loops by insulating developers from the consequences of their code.

Key Insight: Most engineers become managers to hack around organizational dysfunction, but in a healthy org the only honest reason to try management is simple curiosity — and the fastest way to cure the obsession with it is to actually do it.

Charity Majors argues that most engineers become managers to compensate for organizational dysfunction rather than the selfless reasons they claim in interviews. She contends that in healthy organizations, engineers shouldn't need to become managers for career progression, pay equity, or decision-making access, and that the only legitimate reason to try management is simple curiosity.

Key Insight: Your critical path is defined by asking 'what makes us money?' — keep the list of page-worthy operations as small as possible so you can explicitly acknowledge that everything else can wait.

Charity Majors explains how to identify your team's critical path by asking 'what makes you money?' — the essential business operations that justify waking someone up at 3am. She argues teams should keep this list compact and explicit, which also clarifies that everything else can wait until morning.

Key Insight: This is a personal lifestyle post about making boba at home, revealing Charity's characteristic voice and humor outside her usual tech topics, driven by her ADHD tendency to fixate intensely on one thing at a time.

Charity Majors shares her hard-won process for making boba (tapioca pearls) at home after months of trial and error during quarantine. The post is a practical cooking guide born from her ADHD-driven food fixation on boba, covering sourcing safe ingredients, avoiding ruined pans, and achieving the perfect chewy texture.

Key Insight: Engineering productivity should be evaluated at the team level through outcomes and DORA metrics, not through individual metrics that incentivize gaming and ignore the most impactful work.

Charity Majors argues that individual engineering productivity cannot be meaningfully measured through metrics, as creative professional work is too complex to reduce to discrete measurements. She advocates instead for outcome-based management, team-level health metrics, well-calibrated managers with technical judgment, and DORA metrics as proxies for team effectiveness.

Key Insight: Regularly practicing ethical decision-making as a team when stakes are low builds the trust and judgment needed to navigate real crises well.

Charity Majors describes Honeycomb's experiment of discussing hypothetical ethical dilemmas monthly as a team. She argues that ethical problems are fractally hard and that practicing these discussions when stakes are low helps teams make better decisions under pressure, builds trust, and amplifies employee voices.

Key Insight: In crisis periods, leaders should explicitly give teams permission to shed work and stop performing normalcy, redirecting all available energy toward the single highest-impact problem.

Charity Majors shares the advice Honeycomb gave employees during the pandemic: acknowledge that what's being asked is literally impossible, shed everything except your top priority, and spend zero energy on performing normalcy. The core message is that 30 minutes of focused creative energy on the biggest problem beats five hours of distracted availability theater.

Key Insight: Ehrenreich's 'Blood Rites' argues that humanity sacralizes war not because we are natural predators but because we are former prey animals, and our ritualization of violence is a vestigial expression of ancient blood sacrifice born from that deep evolutionary insecurity.

Charity recommends Barbara Ehrenreich's 'Blood Rites' as quarantine reading, summarizing its thesis that humanity's sacred feelings toward war originate not from innate aggression but from our evolutionary history as prey animals who venerated blood sacrifice. The book argues we are the 'nouveaux riche of predators' who go to war because we were once prey, and this discomfort drives our ritualization of violence. She connects this framework to understanding cultural phenomena from horror movies to Tiger King.

Key Insight: True observability is the ability to ask arbitrary questions about unknown system states without predicting them in advance, and vendors redefining it as 'metrics, logs, and traces' are actively preventing the industry from escaping its current dysfunction.

Charity Majors argues that observability is being deliberately watered down by monitoring vendors who rebrand their existing metrics, logs, and tracing products. True observability, borrowed from control theory, means the ability to ask any question about your system's internal state without predicting those questions in advance, which requires arbitrarily-wide structured events with high cardinality and high dimensionality — something no traditional monitoring tool provides.

Key Insight: Observability adoption is fundamentally a sociotechnical challenge best driven by empowering an engineering champion with context and autonomy, not by managerial decree — though leaders must be willing to use authority when the stakes demand it.

Charity Majors debunks common myths about observability adoption — that you only need it at scale, that it's harder than monitoring, and that it's purely technical — arguing it's valuable at any scale and actually easier than traditional monitoring. She then provides a practical playbook for engineering managers to drive observability adoption, centered on finding an internal champion, aligning incentives through on-call ownership, and knowing when to use managerial authority.

Key Insight: The engineer-manager pendulum isn't a demotion — senior ICs who've tasted management become uniquely powerful agents of organizational change, but only if they assert ownership over technical leadership rather than ceding it to the management hierarchy.

A veteran engineer who became a manager to drive sweeping DevOps transformation now feels trapped — bored by management's daily grind but afraid that returning to IC work means losing power and relevance. Charity argues that the two-year mark is the critical window to switch back, that senior ICs who've managed are 'supremely powerful beings,' and that the real next challenge is fighting to make organizations where management isn't a promotion.

Key Insight: Engineering managers deserve explicit rights — including honest feedback, emotional support, and the freedom to step away — alongside their heavy responsibilities, because codifying both keeps organizations honest as they scale.

Charity Majors presents a formal bill of rights and responsibilities for engineering managers, complementing an earlier post focused on engineers. The rights emphasize that managers deserve honest feedback, respect for their role, decision-making authority, emotional support, and the freedom to leave management. The responsibilities cover hiring, inclusive culture, giving feedback, planning, self-care, and staying vulnerable.

Key Insight: Blocking Friday deploys treats the symptom while worsening the disease — the real fix is investing in observability and tight deploy feedback loops so that every deploy, any day of the week, is safe and fast.

Charity Majors argues that blocking Friday deploys is a symptom of unhealthy deployment practices, not a solution. Drawing on her experience at Parse and Honeycomb, she demonstrates that the real path to protecting engineers' work-life balance is building a tight build/ship/observe feedback loop with observability, single-changeset deploys, and observability-driven development culture.

Key Insight: SLOs are not primarily a technical tool for measuring uptime—they are an organizational contract that defines how other teams and managers are allowed to interact with your engineering team.

SLOs serve as an abstraction layer that protects engineering teams from micromanagement, priority hijacking, and feature pressure by establishing clear boundaries and shared ownership of service quality. When stakeholders sign off on SLOs, they agree that reliability is the top priority, giving teams leverage to push back on disruptions and justify technical debt work. The framework works bidirectionally—teams that exceed their SLOs should stop polishing and ship features.

Key Insight: Startup hiring rejections are almost always about constrained organizational needs and team composition rather than a judgment of individual worth, and the real question hiring managers ask is whether they can set a candidate up for success — not whether the candidate is 'good enough.'

Charity Majors explains that startup hiring rejections are almost never about a candidate being 'not good enough,' but rather about constrained slots, team composition needs, and fit alignment. She walks through eleven honest reasons candidates don't get hired at Honeycomb, emphasizing that most are about organizational constraints and team dynamics rather than individual merit.

Key Insight: In the era of distributed systems and observability, paging alerts should be radically reduced to only user-impacting SLO violations, because the old model of accumulating per-failure alerts was really a debugging crutch that observability tools now replace.

Traditional monitoring accumulated excessive paging alerts because teams relied on pattern-matching from past failures to debug monolithic systems. With distributed systems, this approach collapses because failures are infinite and unique, so teams should delete all paging alerts and replace them with SLO-based alerts that only fire when users are actually impacted, using observability tools for debugging instead of alert clusters.

Key Insight: Engineering management involves trading away creative joy, technical growth, job mobility, and personal time for indirect influence through others — and most of the rewarding parts of management can be done as a senior IC without making that trade.

Charity Majors lays out 17 intrinsic reasons why engineers should think twice before becoming managers, from the loss of creative joy and technical growth to the emotional toll, fewer job opportunities, and the fact that most rewarding 'management skills' can be practiced as a senior IC. She argues for honest self-assessment before making the leap, while acknowledging management is worth trying with a full two-year commitment.

Key Insight: Friday deploy freezes treat the symptom instead of the disease — teams should invest in fast, small, observable deployments rather than accepting fear of shipping as normal.

Friday deploy freezes are a symptom of deeper infrastructure problems, not a responsible engineering practice. Rather than accepting deploy fear as normal, teams should invest in CI/CD pipelines, observability tooling, and smaller deployments to make shipping code a non-event. Slowing down deploys actually worsens reliability by batching changes and degrading engineers' judgment.

Key Insight: Leaning into acute pain builds skills, but chronic pain in a misaligned role will destroy your capacity—knowing which battles to power through and which to walk away from is the defining career wisdom.

Charity Majors reflects on her relationship with pain as a career growth strategy, from brute-forcing her way past public speaking terror to her painful tenure as CEO of Honeycomb. She concludes that while leaning into acute pain can build skills, chronic pain in a role you hate will only diminish you—sometimes the only way to succeed is to redefine success.

Key Insight: Successfully championing a third-party service requires acknowledging that security teams' concerns are legitimate while building a structured case that the rewards outweigh the risks — and that doing nothing carries its own risks.

This guest post (by George Chamales, introduced by Charity Majors) provides a practical framework for engineers trying to champion third-party observability and SaaS tools within organizations that have security and compliance concerns. It acknowledges that both the champion's optimism and the security team's caution are valid, and offers a structured worksheet for evaluating risks vs. rewards when proposing a new external service.

Key Insight: Getting security buy-in for observability tools is fundamentally a people problem, not a technology problem — developers must practice empathy by adopting the security team's negative-thinking mindset before approaching them with requests.

This guest post by Lilly Ryan advises development teams on how to work effectively with internal security teams when adopting third-party observability services. It emphasizes building empathy by understanding the security mindset through exercises like the 'Land Astronaut' game, preparing for compromise, and investing in long-term cross-team relationships rather than treating security as a gate to pass through.

Key Insight: Successfully operationalizing a third-party vendor integration requires designated ownership, ongoing security collaboration, and treating the vendor relationship as a living operational concern rather than a one-time procurement decision.

This guest post by Andy Isaacson covers the operational phase of rolling out a third-party observability vendor, from launch through long-term maintenance and eventual sunset. It emphasizes designating an Integration Lead to manage vendor relationships, regularly revisiting security checklists as usage evolves, and maintaining empathy with security teams throughout the lifecycle.

Key Insight: Legacy logging best practices actively harm observability in distributed systems — engineers must replace scattered log lines with wide structured events that capture full request context, enabling the computational investigation that modern systems demand.

Traditional logging best practices were designed for monolithic systems with expensive disks and simple architectures, but they fail completely in distributed systems where investigation requires computation across many services. Engineers need to replace log lines and log levels with arbitrarily wide structured events — one per request per service — that capture rich context and feed into systems capable of ad hoc querying.

Key Insight: Engineering managers must consciously resist the default ladder-climbing narrative and periodically return to hands-on technical work, because the intersection of technical and people skills is what makes them effective—and that intersection has an expiration date.

Engineering management is a career change, not a promotion, and managers face a critical fork: stay technical as a line manager (practicing the engineer/manager pendulum) or climb the organizational ladder—a mostly one-way trip that progressively erodes technical skills and narrows career options. New managers should commit to a minimum two-year tour of duty, resist the advice to completely stop coding, and understand that their technical skills begin seriously deteriorating after 3-5 years away from hands-on work.

Key Insight: The best way to reverse software sprawl without killing developer autonomy is to make the standardized path so well-supported that choosing anything else carries a real personal cost.

Engineering teams that give developers broad technical autonomy often end up with unsustainable software sprawl across languages, databases, and tools. The solution is creating a 'Golden Path' of fully-supported default components chosen by a small council of senior engineers, where developers can still choose non-standard tools but must support them entirely on their own. This preserves developer agency while creating natural pressure toward convergence and operability.

Key Insight: Running a platform at scale requires ruthless prioritization, user-centered observability, and the discipline to protect the platform from individual users while giving every user the tools to help themselves.

Charity Majors distills hard-won lessons from building and running platforms at scale into ten commandments, emphasizing the need to protect the platform from individual users, center observability on user experience rather than system health, and invest in fine-grained operational controls. The advice draws on her experience at Parse and Honeycomb, focusing on what it takes to keep a multi-tenant platform alive and healthy.

Key Insight: Leadership development is best accelerated not through formal training or hierarchical mentorship, but through reciprocal peer relationships built on vulnerability, trust, and the exchange of real, contextual stories.

Charity Majors argues that the most effective way to develop leadership skills is not through books, coaches, or mentors, but through peer relationships where leaders swap stories and support each other. She describes how she built small peer groups that met regularly to practice vulnerability and share real, contextual advice, and publishes her framework for others to replicate.

Key Insight: Making deploys safe isn't about preventing all failures — it's about building resilient pipelines, embracing software ownership, and creating a culture where failures are small, frequent, non-events that everyone knows how to detect and recover from.

Charity Majors argues that shipping software should not be a scary, high-risk event, and that organizations must invest in making their deploy pipelines resilient to failure rather than trying to eliminate errors entirely. She advocates for software ownership where every engineer who writes code also deploys, monitors, and debugs it in production, creating shorter feedback loops and better software. The path forward involves treating deploy tooling as first-class infrastructure, embracing failure as normal, and incrementally gaining confidence in releases through canaries, feature flags, and observability.

Key Insight: Engineers already hold the ultimate power — the power to create or refuse to create — but must actively communicate and strategically deploy their influence rather than ceding it to management by default.

Engineers possess far more latent power and influence than they typically realize, rooted in their unique ability to create and build. Rather than seeking management roles to gain influence, engineers should recognize and cultivate their existing forms of power — technical expertise, social skills, creative output — and deploy them strategically through communication and selective engagement.

Key Insight: Organizations must actively codify and protect engineers' autonomy, technical authority, and career investment because power will naturally and silently concentrate in management unless structural counterweights are deliberately maintained.

Power naturally drifts toward engineering managers over time, which can demoralize engineers and cause them to disengage or leave. To counter this, organizations should explicitly enumerate engineers' rights — autonomy, technical decision-making authority, career investment, and transparent feedback — alongside clear responsibilities for both engineers and managers.

Key Insight: Honest, strategic career advice for women in tech — stay technical, accumulate real power, then use it — is more empowering than the corporate diversity messaging that diverts energy from building actual influence.

Charity Majors post-mortems the backlash to her advice post telling women in tech to stay technical, earn power, and then use it to advocate for others. She walks through what feedback was valid (sloppy framing around gender identity, insufficient defensive writing) versus what was bad-faith pile-on, ultimately standing by her core advice while acknowledging specific communication failures.

Key Insight: Build technical credibility and financial power first, then leverage your seniority to change the system from a position of strength rather than vulnerability.

Charity Majors offers blunt, pragmatic career advice for women in tech: toughen up early, stay technical to build undeniable credibility, and then use your seniority to advocate for others. She argues against leaving tech entirely, instead urging people to quit bad companies rather than the industry itself.

Key Insight: Company values are only worth having if they're specific enough to your company that someone might read them and think 'this place is not for me' — because values that apply to everyone are meaningless.

Charity Majors describes her journey from deep cynicism about corporate values statements to reluctantly crafting one for Honeycomb, driven by top candidates consistently asking about company values. She argues that good values must be particular to the company, actionable for decision-making, and pithy enough to actually be used — not generic aspirational fluff.

Key Insight: The most effective technical leaders treat management and engineering as a pendulum rather than a one-way promotion, building rare and complementary skills by intentionally switching between the two roles throughout their career.

Charity Majors argues that engineers should reject the false choice between management and individual contributor tracks, instead embracing a pendulum approach of switching back and forth between the two roles. She contends that management is not a promotion but a lateral career change, and that the best technical leaders are those who have spent time in both roles, gaining complementary skills that make them uniquely effective.

Key Insight: Database operations demand paranoia and patience—treating stateful services with the same move-fast-and-break-things attitude used for stateless services is a recipe for catastrophic, often unrecoverable data loss.

Charity Majors dissects a MongoDB outage caused by CleverTap's reckless storage engine migration, arguing that the real problem wasn't MongoDB but engineers treating stateful database services with the same cavalier attitude they use for stateless services. She emphasizes that managing databases requires paranoia, careful planning, and months of testing—not weekend upgrades—and urges 'accidental DBAs' to invest in learning proper data management practices.

Key Insight: The DevOps vs SRE debate is fundamentally a context problem — Google's SRE practices are contextually brilliant but the industry needs the more adaptable, crowd-sourced DevOps philosophy because one-size-fits-all solutions don't exist.

Charity Majors argues that the DevOps vs SRE debate is largely a failure to appreciate context — Google's SRE practices are excellent for Google but shouldn't be blindly applied elsewhere. She contends that DevOps philosophy is more adaptable and crowd-sourced than Google's prescriptive SRE model, and criticizes Google's insularity and apparent unawareness of the broader industry's decade of cultural transformation around operations.

Key Insight: Serverless and SaaS abstractions are inevitable and largely positive, but they shift — not eliminate — operational responsibility, requiring application engineers to think deeply about reliability, debuggability, and their core differentiators.

As serverless and SaaS abstractions proliferate, engineering teams can outsource labor but cannot outsource caring about operational concerns. You still own reliability, debuggability, and storage even when you don't run the infrastructure, so application engineers must develop operations-minded thinking about their core differentiators.

Key Insight: Operational excellence is an emergent property that every engineer must own — no amount of abstraction, rebranding, or outsourcing to a dedicated team eliminates the need for operational skills and values.

Charity Majors argues that operations is not a team or a role but an emergent property of how organizations ship and maintain quality software, and that the serverless/#NoOps movement dangerously devalues critical operational skills. Drawing on her experience building Parse's serverless infrastructure, she contends that no matter how elegant the abstractions, engineers still need to care about persistent state, reliability, and operational excellence.

Key Insight: AWS networking via Terraform is full of unintuitive gotchas that aren't documented well, but once you've fought through the pain the payoff of reproducible infrastructure is enormous.

A practical brain dump of hard-won Terraform and AWS networking tips covering security groups, VPC peering, NAT gateways, route tables, and other infrastructure-as-code gotchas. Charity shares specific configurations and debugging strategies learned through painful trial and error, emphasizing the unintuitive nature of AWS networking when managed through Terraform.

Key Insight: Nail polish is a surprisingly durable and accessible way to personalize your tech gear, lasting years of daily abuse without chipping or fading.

Charity Majors evangelizes nail polish as the ultimate paint for personalizing tech equipment like keyboards, laptops, and monitors. She showcases her tradition of painting a new keyboard at every job and shares practical tips for using nail polish on electronics.

Key Insight: Sharing a single Terraform state file across environments means any change to staging can destroy production — separate state files per environment are the minimum viable safety net for infrastructure as code.

After a catastrophic Terraform outage caused by a poisoned shared state file — triggered by simple staging changes that took down all environments — Charity Majors walks through the painful debugging and recovery process, then argues forcefully for using separate Terraform state files per environment to limit blast radius.

Key Insight: VPC-per-environment is the best AWS networking pattern because it gives you real isolation while enabling you to treat infrastructure as testable, promotable code — which is the only way 'infrastructure as code' actually means anything.

Charity Majors compares three AWS networking patterns for managing multiple environments (flat network, account-per-env, VPC-per-env) and argues strongly for the VPC-per-environment model. She debunks outdated beliefs about VPC limitations and makes the case that VPCs enable treating infrastructure as testable, promotable code rather than duct-taped configurations.

Key Insight: Terraform is the best available option for versioned infrastructure orchestration, but its immaturity means you should constrain it to static infrastructure bones and never let it manage dynamic resources in high-reliability production environments.

Charity Majors shares her brutally honest experience adopting Terraform for infrastructure orchestration, documenting the progression from initial delight through debugging hell with modules and inscrutable error messages. She concludes that Terraform is best-in-class for infrastructure orchestration but is still too immature for high-reliability production use, recommending it only for defining static infrastructure bones rather than managing dynamic resources.

Key Insight: Surviving an acquisition means accepting that your product, customers, and culture now belong to someone else — and deciding honestly whether you can live with that or need to walk away.

Charity Majors reflects on the emotional and professional reality of being acquired by a large company (Facebook's acquisition of Parse), offering hard-won advice for startup founders and engineers going through the same experience. She emphasizes that trauma is normal, your product and customers are no longer yours, and you must either adapt to the new corporate culture or leave.

Key Insight: Growth requires leaving comfort behind — whether that means a database outgrowing its storage engine or an engineer outgrowing a role that no longer challenges them.

Charity Majors recaps her 2015 highlights: speaking at 21 conferences while restless as a manager, championing MongoDB's maturation through the RocksDB storage engine integration at Parse, and leaving Parse/Facebook after 3.5 years when comfort became stagnation.

Key Insight: This introductory post previews the themes that would define Charity's writing career: fixing broken tech hiring, making sense of infrastructure chaos, and navigating startup life.

Charity Majors introduces her new blog, outlining topics she plans to write about including tech hiring practices, infrastructure tooling, and startup acquisitions. The post is a lighthearted launch announcement that also explains the origin of her online handle '@mipsytipsy'.