Build "boring" engineering orgs - Charity Majors | Craft 2025

June 04, 2026

Build “boring” engineering orgs - Charity Majors (Talk Outline)

A Craft 2025 conference talk (Budapest) by Charity Majors — co-founder and CTO of honeycomb.io, pioneer of modern observability, co-author of O’Reilly’s Observability Engineering and Database Reliability Engineering, veteran of Parse (acquired by Facebook), Facebook, and Linden Lab (building Second Life). She “loves three things: free speech, free software, and single malt scotch.” The agenda title was “Build Boring Engineering Orgs” — a planned tribute to Dan McKinley’s decade-old essay “Choose Boring Technology” — but she “went into the weeds” and retitled it “In Praise of Normal Engineers.” Structure: debunk the 10x-engineer myth → teams own software → why we should design for “normal” people → seven concrete practices for forging 10x teams → how a great org mints world-class engineers → hiring for the right people, not the best → Q&A.

1. Opening & Framing

1.1 Returning to Budapest

Her last visit to Budapest was in 2017 — she’d said then it was “the most beautiful conference I’ve ever been to.”
Seven or eight years later, “much older and more world-weary,” it still holds up — “it’s just lovely.”

1.2 There is an art to software, not just engineering

In software “we’re always talking about the engineering aspects of it, but there’s an art to it, too.”
Something lovely about being in a beautiful place that focuses on the craft of what we do.

1.3 The title change: from “Boring” to “Normal”

The agenda title (build boring software / boring engineering orgs) was to be a tribute to Dan McKinley (“Funley McFunley” — she couldn’t remember exactly) who wrote a piece a decade ago about choosing boring technology and why it matters.
His point: boring software isn’t bad — it just means the failure circumstances are well understood.
She “went into the weeds” and retitled the talk “In Praise of Normal Engineers.”

2. The 10x Engineer Myth

2.1 The magician engineers we’ve all met

Most of us have run into a few engineers who seem magician-like.
Their ability to reason about complex mental models, leap to non-obvious yet elegant solutions, or emit waves of super high-quality code seems unreal.
She has met a bunch of these people over her career.

2.2 Why the 10x meme is so durable

These magicians partly explain the “curious durability of the 10x engineering meme.”
The meme is based on flimsy, shoddy research.
The claims defending it are often hilarious: e.g., “10x engineers have dark backgrounds,” “they’re rarely seen doing UI work,” “they are poor mentors and interviewers.”
Some claims blatantly double down on stereotypes (“I can get fooled by anyone who looks like Mark Zuckerberg”) — but “damn if it doesn’t just feel true.”

2.3 Her actual stance: “So what?”

She is NOT one of the people who hate the phrase — she thinks there is some truth: some engineers really are dramatically more productive than others.
She doesn’t find that threatening; her reaction is “So what?”
It’s not individual engineering prowess that sets the pace of delivery.

2.4 Self-proclaimed 10x engineers are “raging [expletive]”

The reason the phrase provokes such reaction: people who self-identify as 10x engineers are “almost all raging [expletive].”
People who see themselves as team members first are more likely to be good team players.
Most of the best engineers she knows are pretty humble people.
Working with people who “strut around and talk about being 10x engineers” is a whole different story.

3. Teams Own Software

3.1 The smallest unit of software ownership is the team

Individual productivity matters, but it doesn’t matter the most.
Individual engineers don’t own software — software teams own software.
The smallest unit of software ownership and delivery is the engineering team.

3.2 Everyone shares the same pipeline

Everyone uses the same software delivery pipeline.
If it takes the slowest engineer 5 hours to ship one line of code, it takes the fastest engineer 5 hours to ship a single line of code too.
Time spent writing code is typically dwarfed by time spent on every other part of the software development lifecycle.

3.3 Individual owners are single points of failure

We have a term for a lone individual owning software: a single point of failure.
There is no universal answer or universal truth when it comes to this.

3.4 When individual ownership is acceptable

It’s normal at young startups to have individuals owning software.
The biggest existential risk then is not knowing if you’ll still be alive in four, five, six months — you’re racing to find product-market fit before running out of money.

3.5 When ownership must move to a team

As soon as you’re planning for a company meant to last years into the future, ownership must be handed to a team.
Individual engineers get sick, go on vacation, leave the company — it should not risk the business every time this happens.

3.6 The leader’s job: craft high-performing teams

If teams own software, the key job of any engineering leader is to craft high-performing teams.
“If you must 10x something, 10x this — build 10x engineering teams.”

4. Productivity Is Business Impact

4.1 Are you working on the right thing?

The single most important thing to understand about engineering productivity: are you working on the right thing or not?
Are you moving the business materially forward day after day after day?

4.2 Software engineering = solving business problems

Software engineering is not about writing the most lines of code.
It’s about solving business problems using technology.
The only truly meaningful measure of productivity is business impact.

4.3 Senior/intermediate engineers are the workhorses

Senior and intermediate engineers are often the workhorses of the industry — consistently moving the business forward step by step.
Staff+ engineers don’t get to “put on their headphones and crank” — they’re heads-up, looking around, solving coordination problems.
If you must be a staff+ engineer just to move the business forward day by day, something is deeply wrong with your organization.

5. Pedigree Obsession Is Backwards

5.1 The pedigree trap

“World-class” org talk gets “wrapped around the axle” about pedigrees — Ivy Leagues, whether people worked at FAANG (ex-Google, ex-Facebook).
At startup incubator events: “We just hired someone from Google” — as if that proves anything.

5.2 The best orgs are the opposite

The best engineering organizations are ones where you don’t have to be a world-class or pedigreed engineer just to move the business forward.
A truly great org lets perfectly normal workaday engineers with decent skills and ordinary experience consistently move fast, respond to users, ship code, fix things, understand the business, and move it forward.

5.3 Individual-excellence focus lets leaders off the hook

Focusing on individual excellence and superstars mostly lets leaders off the hook.
”Any jackass can build an org where the best engineers in the world can get [stuff] done. It’s not hard.”
The real competitive advantage: build socio-technical systems where less-experienced, normal engineers convert their effort into product and business momentum — and you can draw from a broader talent pool.

5.4 The “top 10% of talent” language is off-putting

This language is everywhere: Netflix (“we target the top 10% of global talent”), Coinbase (she thought it was a spoof at first, “haha that’s funny — oh no, they’re serious”).
She finds it so off-putting she’d never apply / never join such a company.
Some people find it intrinsically motivating to measure themselves against the best — she doesn’t think that’s necessarily a healthy dynamic.

5.5 The insecurity behind it — and the salary question

The whole 10x-engineer thing “comes from insecurity.”
When people brag about only hiring the “top blah blah percent,” ask: are you ready, willing, and able to pay them salaries in the top 10% — or top 0.1%?
If you’re not prepared to pay at the same rate you’re hiring, “rethink your strategy.”

5.6 Great orgs mint world-class engineers (foreshadowed)

A truly great org that optimizes for constant learning and mentorship consistently mints world-class engineers — but “we’re getting ahead of ourselves.”

6. On the Word “Normal”

6.1 Why “normal” is a loaded, attention-grabbing word

She admits she uses “normal” partly as an attention grabber.
Many technical people got attached to their identities as “smart kids” — she did too.
The software industry reflects and reinforces a preoccupation with intelligence “at every turn.”

6.2 We are mostly normal people with specialized practice

It can be humbling to think of ourselves as normal — but most of us are pretty normal people with many years of highly specialized practice, experience, apprenticeship.
There’s nothing wrong with that.

6.3 Excellence has many axes

Even “certifiable geniuses” on some axes are pretty normal on others.
There are many ways to be exceptional: kinesthetic, emotional, spatial, musical, linguistic.
“Normal” also encompasses a wide range of neurodiversity and neuro-spiciness.

6.4 Great engineers are forged, not born

Nobody is born a great software engineer — “zero babies were born good at algorithms.”
Great engineers are forged / made, not born.
There’s little more value to wring from thinking of ourselves as special; more value comes from thinking of ourselves collectively as normal people who have practiced a niche craft for a long time.

7. Design Systems for Normal People

7.1 Hire for strengths, design systems for our normalcy

When hiring talent and building teams, focus on the ways people are strong, exceptional, top of their field.
When building socio-technical systems for software delivery, focus on all the ways we are normal.

7.2 Normal people have cognitive biases and limits

Normal people have confirmation bias, recency bias, hindsight bias.
Our eyes are drawn to the color red (unless colorblind).
We work hard, care, do our best — but we also forget things, get impatient, zone out.
Responding to an outage at 2am we’re less likely to get it right than in the middle of the business day.
When we see the same text block back at us over and over, we stop reading it.

7.3 We are embodied beings

Our emotional state affects the quality of our work.
Our relationships impact our ability to get stuff done.

7.4 The payoff of designing for normal

When systems are designed to be navigated by normal engineers, all the excess brilliance they have gets poured into the product and moving the business forward — instead of being wasted navigating the systems.

8. Seven Practices for Forging 10x Teams

Framing: turning normal engineers into 10x teams starts by realigning away from an individualist “hire the smartest” mindset toward composing teams and developing talent. This is harder for leaders — it takes more skill and more caring than looking for the “best” engineers and shoveling money at them. “That’s okay.”

8.1 Practice 1 — Keep the deploy interval short and sweet

If it takes two months to deploy your code, that’s a huge cognitive carrying cost.
The shorter the interval, the lower the cognitive carrying cost.
Intercom’s saying: deploy ”with the heartbeat of your company” — it should happen constantly, automatically, without thinking.

8.2 The software engineering “death spiral”

When the feedback loop is long and laggy, a death/dust spiral forms.
It takes a long time to get diffs out → so diffs get longer.
Longer diffs → take longer to code review.
People must page projects in and out (put one down for a week or two while something’s in the pipeline).
Rare infrequent deploys bundle up many diffs by many people → they break more often than not.
Breakage destroys people’s days debugging → everything gets slower → people wait on each other more.
You then need more and more specialists: build/release engineers, more SREs, more managers, more project managers, more Jira tickets, more software.
Anecdote: you find a cool little app, research the company, and discover they have 800 engineers — “doing what?” Probably waiting on each other to get stuff done.
These are systems that feed on each other — either feeding downhill (worse) or uphill (better).
Working under a six-month lag before shipping requires being “one of the greatest engineers in the world” — but their brilliance goes toward fighting their own system, not moving the business forward.

8.3 Practice 2 — Make it easy to do the right thing, hard to do the wrong thing

This is why she is excited about the platform engineering movement.
Her definition: platform engineering is about treating engineers like people.
It applies classic product development practice and design thinking even though the “customers” are internal engineers.
Goal: engineers can self-service — deploy, roll back, understand, and debug their own software.
“The fastest way to ship a line of code should also be the easiest.” Engineers are people too.

8.4 Practice 3 — Every engineer owns their code in production

Every engineer should be able to deploy their own code, figure out if it’s working as intended, and take the right action.
Better yet, invest in feature flags so you can flip things on/off without a whole new deploy.
One of the original flaws of software: splitting the world into developers who write code and ops who understand the code.
That’s a bad feedback loop because it’s cut in half — the people getting feedback about what works must be the ones best positioned to act on it.
Remember people do this at the worst possible time from a human point of view.

8.5 Practice 4 — Invest in observability, tests, and tooling

She states her bias upfront: her company does observability.
Much of the long, laggy loop is due to poor sensemaking abilities — “the dark matter of software engineering”: you can’t see it; all you see is that everything is slow.
High-quality tools, tests, and observability — the ability to visualize your work — is a big part of what makes engineering abstractions accessible to actual engineers.
Trying to understand code by reading lines in the IDE requires being a world-class engineer — not a great use of world-class cycles.
To cut CI/CD time, start by visualizing it as a trace so you can see where all the time is going — then it becomes “just engineering.”

8.6 Practice 5 — Have dedicated internal-tools people

You must have people whose job it is to make engineers efficient.
“If it’s everybody’s job, it’s nobody’s job” — somebody has to own it.
Set internal SLOs: e.g., anytime it takes over an hour to run tests and deploy an artifact to production, invest in paying that down.
Engineering productivity is not something you can outsource — “we’ve all learned this lesson.”

8.7 Practice 6 — Learning is the norm, growth is the baseline

People do their best work when they feel a sense of belonging.
The first step toward a real meritocracy is building an inclusive culture — otherwise you just mimic and repeat society’s existing biases and lose talent.
Everyone should feel safe to ask questions, be wrong, explore, make mistakes — that’s what learning looks like.
This isn’t “squishy” or anti-performance — ”this is what excellence looks like.”

8.8 Diverse teams are resilient teams (within Practice 6)

A monoculture (all worked together at Google, then Facebook, predict each other’s reactions) can move faster than any other team.
But a moment comes — good problems or bad — when they must scale, bring on people from different backgrounds, or someone gets sick or pregnant — and “everything falls apart,” derailed fast.
When teams are already used to a mix of genders, racial backgrounds, identities, age ranges, family status, and geographical locations as standard operating procedure, they can roll with it.
Instead of asking “are they a culture fit?” (which no one can define), ask ”what angles/axes of diversity do they bring — ones we need, ones we don’t have?” — that’s a huge plus.

8.9 Practice 7 — Assemble a range of levels

The best teams are not a straight lineup of staff+ and principal engineers.
Many of those engineers are bored or doing what they’ve done a thousand times — banging out an API endpoint or login page for the 300th time on autopilot, not thinking, having stopped learning.
The best teams are hungry to learn and expect to challenge themselves every day.
Everyone is used to being a newbie — picking up new skills, languages, frameworks.
The humility of being new when someone younger/newer can help you is healthy.
Getting hooked on the feeling of challenging yourself is the healthiest thing for a 40-year career.

9. A Great Org Mints World-Class Engineers

9.1 What makes engineers happy

Shipping a lot, shipping fast, helping each other, building in a collaborative environment where nobody is expected to already be the master with all the answers.

9.2 The Honeycomb example

Honeycomb has ~250 people, maybe 70–80 engineers (“not as big as most of y’all”).
Many of those engineers could walk out tomorrow and make at least half a million a year at any FAANG company.
Could they have done that when they arrived a couple years ago? No — most could not.
They can now because they worked with a world-class team and became world-class engineers.
A couple have left for Nvidia — “god bless, I’m delighted they’re making bank for their families” — but most stay because it’s fulfilling to work where new voices and freshness are valued and you get to build the next team of world-class engineers.

9.3 Don’t come to depend on your brilliant engineers

If you’re lucky enough to have world-class engineers, your role as leader is to leverage their brilliance for customers and other engineers without coming to depend on it.
“These people don’t belong to you” — they can leave at any moment, and that has to be okay.
An org tightly wrapped around one or two or a dozen “wizard” engineers is a huge liability.
These people can be enormous assets — assuming they’re team players who keep egos in check (probably why tech companies obsess over hiring them, especially in Silicon Valley).
Companies over-index on finding people after they’ve already been minted, which reinforces and replicates the prejudices and inequities of the world at large.

9.4 Talent vs. opportunity

”Talent may be evenly distributed across populations. Opportunity is not.”

10. Clarifications: This IS the Pursuit of Excellence

10.1 What she is NOT saying

She is not saying excellence doesn’t matter — “oh, it really does.”
She is not saying manage to the lowest common denominator (a reaction she got when she first published on this).
She is not saying don’t manage people out or don’t have high standards.

10.2 What she IS saying

“This is how you have high standards.”
Excellence is not something people show up with “done, baked” — excellence is a learnable skill.
There’s no such thing as a 10x engineer as a fixed personality attribute you can drop into any context and get 10x — it’s specific and situational.

10.3 Excellence is everywhere, but must be specific

“The potential for excellence is everywhere” — a million ways excellence can flower and be called for.
Precision and specificity is how we bridge the gap — you can’t flatten engineering to one universal productivity metric.
Excellence differs across contexts: a security consultancy ≠ a 12-person VC-backed payments startup ≠ a 50,000-person enterprise hardware company ≠ someone doing open source for 30 years.
Advice: recruit, interview, train, and retain — know what excellence means to you specifically, hold standards high, and build an org oriented around developing that excellence.

11. The Fundamental Attribution Error & Systems

11.1 We overweight individuals, underweight systems

Humanity (“the entire human race”) places too much emphasis on individual agency and characteristics and not enough on the systems that shape us.
Sociology’s term: the Fundamental Attribution Error (FAE) — we see a person and attribute their state to who they intrinsically are, not to the context, opportunities, and happenstance that brought them there.

11.2 Your company is a system

“Your company is a system.” What kind of engineers does your system mint? Who do people become inside it?
The work is reusable: any investment in making it easy for juniors to level up gets reused every time someone joins, changes teams, or learns a new skill.
Ask: what kind of engineer does your system forge — a team player, or someone who feels stack-ranked?

11.3 Know your business

”Talent is as common as dirt. The potential for excellence is everywhere.”
There is no substitute for knowing your business.
Unless you’ll pay everyone top-10% / top-1% salaries, you must be specific.
Questions to ask yourself:
- What is your time horizon? (A six-month survival horizon needs a very different strategy from a one-to-two-year horizon, much less a decade-long corporation.)
- How difficult, novel, differentiating is the engineering labor you need?
- What intersections of expertise do you need?

11.4 Look at your most successful engineers

Look at the engineers every manager would love to clone and every junior looks up to.
What do they have in common? How did they get there?

11.5 The dirty little secret: much of engineering isn’t that hard

“A lot of engineering is not that hard” — a lot of work just needs to get cranked through.
But doing it makes us excellent and primes us — ”like lifting weights, we do the reps doing the easy stuff.”
Then when real hard technical challenges come, we have good judgment or niche skills — exciting and fun.
Be an org that values continuous learning, development, curiosity, and experimentation, and invests in its talent.

12. Conclusion: Hire the Right People, Not the Best

12.1 Shift the focus of hiring

Many issues — candidates self-selecting out because the language is off-putting, poor diversity of applicants — would improve just by shifting hiring away from “the best people” toward “the right people.”
The right people: excited about your problems, good teammates, good communicators.

12.2 The Honeycomb interview: the conversation is the interview

Honeycomb uses a take-home test (extend a piece of code) — but that’s not the interview.
The interview is a conversation afterward with a couple of engineers who’d be your peers.
You talk through your decisions: What did you do? Why? What were you thinking when you tried this? If you’d had more time, what would you have done? How would this scale?
The point: you get to know each other a little.

12.3 Selecting for communication

Many engineers can do the work but can’t talk you through it or explain it.
Honeycomb decided early — hiring a distributed team — to select heavily for communication skills.
They care more about ”can you think through / talk me through / have a conversation about the problem” than what the code looks like.
This was pre-pandemic; when everyone went virtual during the pandemic, the specificity served them really well.
Communication skills predict collaboration skills and success.

12.4 Be the kind of place people don’t want to leave

Teams that love collaborating, teaching, explaining, and hearing each other get a little better every single week.
Engineering talent and good human beings are drawn to such places ”like a moth to a flame.”
It feels good to ship, to move the business forward, to sharpen your craft, and to stick around and train the next generation.
“Be that kind of place — be the kind of company they don’t want to leave.”

13. Q&A

13.1 Q1 — What’s the deal with the kitten on the bottom of your slides?

(The most-upvoted Slido question — the most questions the conference had seen so far that year.)
She hadn’t even noticed there was a kitten — “I’m a new cat mama, and it’s really invaded every part of my [life].” Quick, easy answer.

13.2 Q2 — How can hiring managers shift their filters from “who’s the best” to “who will thrive here”?

Start with who is thriving here now.
Then check for problems: if “women engineers don’t seem to thrive here, I guess we won’t hire any” — that’s a problem.
Look at the characteristics of who finds the work meaningful — e.g., Etsy talked of “code as craft” and built a culture appealing to people who see code that way.
Managers can’t do it without support from above — she’s “not a top-down person,” but you can’t unilaterally build a good culture on your own team, or it becomes a team out of step with the rest of the company (not a good fit). “Complicated question, great question.”

13.3 Q3 — How do you balance simplicity/stability (“boring tech”) with engineers’ desire to learn and play with the new and shiny?

“Easier question.”
Rule of thumb: the closer you get to laying bits down on disk, the more conservative you should be — databases (ooh), operating systems (ooh).
But developer tools and frontend stuff is where “you get to [mess] around and find out” — there’s a gradient.
The golden path model is valuable: a set of tech that is official and supported by SREs; if you veer off the path, you support it yourself. Two policies that serve people well.

13.4 Q4 — Werner Vogels said “run what you wrote”; AWS/Netflix put devs on call. Devs don’t like being on call — do you have a separate ops team, or make devs take the calls so they cooperate?

“It depends — there is no one right answer.”
Ideally, we put engineers on call not to make everyone equally miserable but to shorten and tighten the feedback loop so things actually get better.
She’s sympathetic that people don’t want to be woken at 3am — “it’s not okay that anyone’s getting woken up at 3am,” not just okay because it’s an ops person instead.
The right destination: short, tight feedback loops where the person with the most context is best equipped to fix it and is the one who gets paged.
But there’s a long, wiggly journey to get there, depending on the situation on the ground.
Ideally don’t break up that feedback loop — the people writing the code should get the alerts, and it must be sustainable and compatible with actual life and family.

People & References Cited

Charity Majors — speaker; co-founder & CTO of Honeycomb (honeycomb.io); pioneer of modern observability.
Prior companies: Parse (acquired by Facebook), Facebook, Linden Lab (Second Life).
Books (O’Reilly): Observability Engineering, Database Reliability Engineering (co-authored).
Dan McKinley (“Funley McFunley”) — author of the “Choose Boring Technology” essay (~a decade old) that inspired the original title.
Werner Vogels (Amazon CTO) — “run what you wrote” (cited in Q4).
Companies named: Netflix (“top 10% of global talent”), Coinbase (top-talent LinkedIn post), Google & Facebook/FAANG (pedigree examples), Nvidia (where a couple of Honeycomb engineers left), Intercom (“deploy with the heartbeat of your company”), Etsy (“code as craft”), AWS/Netflix (dev-on-call).
Concepts: the 10x-engineer myth; teams (not individuals) own software; single point of failure; product-market fit vs. long-term horizons; business impact as the real productivity metric; pedigree obsession; “the right people, not the best people”; designing socio-technical systems for “normal” people; cognitive biases (confirmation/recency/hindsight); embodied beings; platform engineering as “treating engineers like people”; the deploy death/dust spiral; deploy “with the heartbeat of your company”; feature flags; dev/ops split as a broken feedback loop; observability as the “dark matter” of software; visualizing CI/CD as a trace; internal SLOs; “if it’s everybody’s job it’s nobody’s job”; inclusion as the first step to meritocracy; diverse teams as resilient teams; culture fit vs. axes of diversity; assemble a range of levels; a great org mints world-class engineers; the Fundamental Attribution Error (FAE); “talent is as common as dirt, opportunity is not”; “great engineers are forged, not born”; excellence as learnable/situational/specific; the golden path model; conservatism “close to the bits on disk”; communication skills predicting collaboration.

Video: https://www.youtube.com/watch?v=SWiyikJGcjc — Transcript via yt-transcript.sh; outline generated from the transcript.