Culture matters

Three levers, and what actually moves them

Companies shape behavior with three broad tools: incentives, process, and culture. The words get used loosely, so concrete examples help:

• Getting people to show up to meetings on time

  • Incentive: dock pay for people who are late
  • Process: don't allow anyone who's late into the meeting
  • Culture: people feel strongly about showing up on time

• Getting people to build complex systems

  • Incentive: require complexity in promo criteria
  • Process: make process for creating or executing on a work item so heavyweight that people stop doing simple work
  • Culture: people enjoy building complex systems and/or building complex systems results in respect from peers and/or prestige

• Avoiding manufacturing defects

  • Incentive: pay people per good item created and/or dock pay for bad items
  • Process: have QA check items before shipment and discard bad items
  • Culture: people value excellence and try very hard to avoid defects

Old-school thought leaders often push a culture-only position, arguing that tools and process are secondary to simply getting people to care. That kind of overstatement has fueled an equally extreme backlash, dismissing cultural explanations entirely in favor of incentives and system design. The reality is that culture has measurable, large-scale effects. Manufacturing defect rates, for example, vary persistently between countries on a timescale of decades, robust across companies—even when the same process and incentives are imported factory by factory.

The same dynamic shows up in software. A post by Jamie Brandon on moving faster captures it well:

The main thing that helped is actually wanting to be faster.

Early on I definitely cared more about writing 'elegant' code or using fashionable tools than I did about actually solving problems. Maybe not as an explicit belief, but those priorities were clear from my actions.

I probably also wasn't aware how much faster it was possible to be. I spent my early career working with people who were as slow and inexperienced as I was.

Over time I started to notice that some people are producing projects that are far beyond what I could do in a single lifetime. I wanted to figure out how to do that, which meant giving up my existing beliefs and trying to discover what actually works.

Velocity can also be heavily influenced by what a person believes is normal. Working at a company with unusually high productivity set a baseline that has stuck with me for my entire career, as it did for others who started at fast-moving startups. People who have only worked at large companies tend to accept a slower pace as simply how things are; those with a different reference point typically notice the difference immediately.

Almost none of us operate anywhere near our actual capacity, and what we think is achievable is often the biggest limiting factor. In programming specifically, we are far enough from the Pareto frontier that there are free wins available once you notice they exist.

Culture broadcasts what is possible

One of culture's quiet but powerful effects is that it sets ideas about what's possible. At RC, a disproportionate share of well-respected non-academic tech conference speakers turned out to be alumni, yet most speakers had never given a talk before attending. Asked how they got started, many said they simply hadn't realized how straightforward the process is. Once an environment makes an activity look normal and attainable, a lot of people will try it. The same applied to blogging: given both the sense that it's feasible and the technical knowledge that any decent toolchain will work, many RC alumni became readers and writers. This is skill acquisition through exposure, not instruction, but it works.

Some skills are heavily attitude-dependent. Debugging is a good example: having a good attitude is a major component of effectiveness. This is something my first full-time employer, Centaur, was unusually good at instilling, to the point that nearly everyone in my org there would be considered a very strong debugger by normal tech company standards.

At big tech companies, it's common to see people give up after a few random attempts. In an extreme case, an engineer at a large company told me it never makes sense to debug a bug taking more than a couple of hours—engineer time is too valuable. That person picked up this rule from their first team, and carried it for years. Starting out in an environment where debugging serious problems is the norm changes your default behavior. At Centaur, people did not walk away from a bug they didn't understand, even when the symptom was trivial, because the underlying cause could be serious once a chip shipped. Regardless of the symptom, people came in day after day and tracked down nasty nondeterministic bugs that ate weeks or months, without frustration or surrender. Watching that culture as a new hire made it natural to adopt it.

There is a big gap between deliberately leaving a known-trivial bug unfixed and never having developed the skills to debug anything nontrivial.

A culture of ownership: what it looks like

Centaur had, per capita, by far the lowest serious production bug rate of any company I've worked for: well under one per year across roughly a hundred engineers. Plenty of teams of ten that I've encountered had at least ten times that rate. This result wasn't driven by unusually heavyweight process—Centaur was very light on it. Neither was it an incentive story compared to big tech companies.

The cultural component was a sense of ownership that crossed team boundaries. People fixed problems on sight, or engaged the obvious owner directly. There were no roadmaps, standups, or kanban boards used to prioritize important work. People did necessary work unprompted. This is the opposite of what I've seen at two of three major tech employers, where the median person avoids anything outside their team's mandate, and cross-team problem reports routinely meet the reply: "not on our roadmap for the quarter, perhaps in two quarters." That same two-quarter response repeats indefinitely. In my experience, large-company tech culture routinely lets huge, extremely costly problems slip through the cracks because nobody wants to pick them up—something I never observed at Centaur.

A side effect of that culture is that fixable high-value problems accumulate in ways that border on absurd. At big companies you're constantly ticking off issues that are worth more to the company than my entire expected lifetime earnings, each solvable by any intern. And the same forces that keep problems unsolved mean the people who solve them aren't rewarded. Attempts to fix this with incentives or process—cash for fixing prioritized problems, JIRA-driven marathon project spreadsheets—work far less well than instilling a culture of ownership in the first place.

Where values come from (and where they go)

Culture doesn't just act on people when they're an employee. It forms habits and expectations that transfer between jobs. In eight years at Centaur I found only one trivial problem whose fix was worth more than a lifetime's compensation, simply because problems got solved before reaching that point. People carry that standard with them, and it's a trait that is shared across very different disciplines. Books about being effective in sports or competitive games tend to boil down to the same underlying attitudes: serious observation and improvement of skills, avoiding emotional self-sabotage, and using intuition.

There is much to be said for choosing a job partially on the basis of what kind of cultural values you'll absorb. The same set of forces is familiar outside programming. To paraphrase the standard law-school pattern: idealistic students join intending to save the world, then gravitate to whatever is most prestigious, which typically isn't public-interest work. Just about everyone assumes it won't happen to them; very few people can maintain values that everyone around them treats as alien without absorbing some of the room's norms.

Appendix: Bay area culture

The Bay Area's willingness to attack problems is infectious. Griping about any given industry exists everywhere, but in the Bay, someone complaining about a messy industry a year ago with an intent to fix it may well have founded a startup since. This isn't a difference of basic talent. It's that a norm of starting companies makes it feel possible, especially with all the supporting infrastructure and network effects that follow.

Not all of it is admiration-worthy. Flakiness is famously widespread to an extent that surprised me—even a stated intention to be 15 minutes late was interpreted as a cancellation. The "saying yes to avoid conflict" norm that actually means "no" is equally dangerous and corrosive for internal management.

Appendix: Centaur's hiring process

People often assume a company with very high output must have unusually selective hiring. Centaur was actually less selective than Google, Microsoft, or Twitter, and no more selective than IBM or Micron. The lever was onboarding, not filtering.

Among new grads we struggled to recruit at all, since no one had heard of the company. In fact, a classic FizzBuzz-style coding screen failed one requirement: nobody, including the most capable candidates, could complete it, so it had zero discriminatory power. We simply dropped it.

This worked because we hired people other companies weren't competing over. We didn't filter by prestige or rely on algorithms puzzles. Employees still wrote hairy concurrent microcode and produced tools at a velocity and correctness level I haven't seen elsewhere. Fake-programmer stories are real but rare. One was caught at a top-tier company only because interview footage showed the person hired was not the same person who showed up for work. Another was a "senior SWE" (L5/T5) at Google for years, hiding that they could not write a loop or tell = from == until a forced pair-programming session. Meanwhile, a small firm can go a decade without asking a coding question and never hire anyone who can't code—because fake candidates mainly plague large, prestigious targets.

Appendix: importing culture

Culture is two-way street, but that's surprisingly easy to overlook when interviewing senior leadership or senior ICs. In hire loops for very senior roles, I have never once seen someone besides myself raise the issue of cultural compatibility, aside from blatant red flags like bigotry or harassment. Without that discussion, it's extremely common for a senior person to import a culture that's incompatible with the one they're joining, causing friction and high attrition as things settle into place.