1.1 Software engineering values¶

Overview and motivation¶

Software engineering values are the shared beliefs, norms, and everyday behaviors that shape how people build software together. They are not the posters on the wall or the words in the employee handbook. They are what actually happens when an incident wakes someone at 3 a.m., or when a junior engineer disagrees with a principal engineer, or when a deadline collides with quality. Values are the invisible system beneath every technical decision.

In a small team, values spread by osmosis: people sit together, absorb the norms, and self-correct. In a larger team, osmosis fails. Now you have to make values explicit, write them down, have leaders model them, and reinforce them through your systems. Skip that, and the culture fragments into dozens of incompatible micro-cultures that quietly tax every collaboration.

For a larger team, the stakes are structural. Weak values show up as attrition, slow decisions, hoarded knowledge, and repeated incidents whose root causes are never fully fixed. Strong values show up as fast, safe, reliable changes: engineers surface problems early, learn from failure, and take ownership. The gap between these two states is often wider than any technology choice.

Enterprises and government organizations feel this acutely, because they work at scale, under scrutiny, and over long timelines. Systems built today may run for a decade or more, staffed by people who never met the original authors. In these settings, culture is what carries intent across time and turnover.

Regulated enterprises face one more pressure: the temptation to substitute process for trust. When accountability is high and mistakes are visible, the reflex is to pile on controls, sign-offs, and blame. It is understandable, but it backfires. The most reliable, secure, and compliant organizations are usually the ones with the strongest learning cultures, not the most punitive ones. Values and compliance are allies, not opposites.

Key principles¶

• Psychological safety is the foundation; without it, every other practice degrades.
• Failure is data. Blameless learning turns incidents into durable improvement.
• Ownership means accountability for outcomes, not just outputs: "you build it, you run it."
• Writing is thinking. A culture that writes decisions down scales its judgment.
• Sustainable pace beats heroics; burnout is a systems failure, not a personal one.
• Diversity, equity, and inclusion are engineering strengths that improve decision quality.
• Values are modeled top-down and reinforced bottom-up; leaders' actions outweigh their words.

Recommendations¶

Build psychological safety deliberately¶

Psychological safety is the shared belief that you can speak up, ask questions, admit mistakes, and challenge decisions without fear of humiliation or punishment. It is the single strongest predictor of team effectiveness in large-scale studies. Build it deliberately. Have leaders own their own mistakes out loud ("here is a mistake I made and what I learned"). Meet bad news with curiosity rather than punishment. Invite dissent openly in meetings. Rotate who speaks first, so senior voices do not anchor the discussion. And make it normal to say "I don't know" and "I need help."

Practice blameless learning¶

When something breaks, look at the conditions that allowed the failure, not the person who triggered it. Adopt blameless postmortems: a written record of what happened, the timeline, the contributing factors, and concrete action items with owners and dates. Start from the assumption that everyone acted reasonably given what they knew at the time. Ask "what made this easy to get wrong?" instead of "who messed up?" And track action items to completion. A postmortem culture that never closes its follow-ups is just theater.

Establish clear ownership models¶

"You build it, you run it" makes the team that writes a service responsible for operating it, on-call included. This tightens the feedback loop between design decisions and operational pain, and that improves quality. Pair it with a service catalog that records, for every system, who owns it, how to reach them, its dependencies, and its runbooks. Keep ownership explicit and non-overlapping. Ambiguous ownership is how systems rot and incidents linger. When a team genuinely cannot operate a system on its own, give it platform support rather than diffusing accountability.

Cultivate a writing culture¶

Writing sharpens your thinking, and it creates artifacts that carry across time zones and years. Make design docs and decision records routine for significant changes: a short document that states the problem, the options considered, the proposed approach, and the trade-offs, circulated for comment before you build. This surfaces disagreement early, while it is still cheap, and it leaves a durable record of why you decided what you did. Keep templates lightweight and expectations in proportion to the decision's weight. And reward good writing in public.

Protect sustainable pace¶

Hero culture, where a few people repeatedly rescue the organization through unsustainable effort, is a symptom of weakness, not a virtue. It burns people out, concentrates knowledge dangerously, and hides the underlying problems you should be fixing. So measure and manage on-call load. If one person is paged constantly, treat that as a defect to engineer away. Make time off normal, protect focus time, and judge output over a quarter rather than a week.

Treat DEI as an engineering strength¶

Diverse teams make better decisions. They weigh more perspectives and fall for groupthink and blind spots less often, and that matters enormously for accessibility, security, and serving broad populations. Build inclusion into your everyday engineering: accessible documentation, inclusive language in code and interfaces, meeting practices that let quieter voices contribute, and a fair split of both the glamour work and the glue work.

Trade-offs: pros and cons¶

The central tension is short-term speed versus long-term health. Heroics and blame buy a burst of apparent control, then a slow collapse in morale and reliability. Blameless learning, ownership, and sustainable pace feel slower in any single week, but they compound into far higher velocity over quarters and years. Leaders have to be willing to absorb the short-term discomfort to protect long-term capacity.

Examples¶

Startup. A six-person startup runs on trust and hallway conversation, so no one writes the team's values down. When a founder-engineer pushes a bad migration and the CTO snaps at them in Slack, the room goes quiet, and the next two bugs get quietly hidden rather than surfaced. The team recovers by adopting one lightweight habit: a five-minute blameless "what made this easy to get wrong?" chat after each incident, no template required. That small ritual keeps the osmotic culture healthy without the process overhead a larger organization would need.

Enterprise. A large financial-services firm suffered a major outage when a routine configuration change cascaded across services. In a blame culture, the engineer who pushed the change would have been reprimanded, and that would be the end of it. Instead, a blameless postmortem showed that the deployment tooling made the dangerous change look identical to a safe one, that no staged rollout existed, and that the runbook was outdated. The firm invested in progressive rollouts and configuration validation, and similar changes now fail safely. Choosing to look at the system rather than the person produced a durable engineering improvement.

Government. A government digital service agency adopted "you build it, you run it" alongside a strict docs-first RFC (request for comments) process. Because its systems have to survive changes in political administration and staff turnover measured in years, every significant decision is recorded in a design doc that explains the context and trade-offs. New engineers, and incoming contractors, can read the reasoning behind a decade-old architecture instead of reverse-engineering it. That written institutional memory is what lets the agency keep public services reliable despite high turnover and strict accountability requirements.

Business case: motivations, ROI, and TCO¶

The return on culture is real but indirect, which is why it is chronically underfunded. Over a system's lifetime, the dominant cost is not building it. It is maintenance, incident response, rework, and the cost of losing and re-hiring skilled people. A strong learning culture improves every one of these. Blameless postmortems reduce repeat incidents. Clear ownership reduces mean time to recovery. A writing culture lowers the cost of onboarding and the cost of decisions made in ignorance of the reasoning that came before.

Take attrition alone. Replacing a mid-level engineer typically costs somewhere between half and two times their annual salary once you count recruiting, ramp-up, and the institutional knowledge that walks out the door. If a healthier culture trims regretted attrition by even a few percentage points across a thousand-person organization, the savings dwarf the modest cost of running postmortems and writing docs. The adoption cost is mostly leadership attention and a little process overhead. The cost of not adopting is paid continuously and invisibly: slower delivery, recurring incidents, and quiet talent flight.

To make the case to leadership, connect culture to metrics executives already track: delivery lead time, change failure rate, mean time to recovery, incident recurrence, and regretted attrition. Frame psychological safety not as a soft benefit but as the mechanism that makes every other engineering investment pay off, because unsafe teams hide the very problems those investments are meant to fix.

Anti-patterns and pitfalls¶

• Blame-and-shame incident reviews: they drive problems underground and people stop reporting.
• Hero worship: rewarding firefighting over fire prevention perpetuates the fires.
• "Values" that leaders violate: stated values contradicted by behavior breed cynicism.
• Ownership without support: assigning on-call for systems teams cannot realistically operate.
• Process as trust substitute: piling on sign-offs instead of building genuine safety.
• Docs theater: writing documents no one reads or that never influence decisions.
• Inclusion as a checkbox: hiring for diversity while excluding those same voices from decisions.

Maturity model¶

• Level 1 (Initial): Values are accidental and personality-driven; incidents mean blame; knowledge lives in a few heads.
• Level 2 (Managed): Some teams run postmortems and write docs, but practices are inconsistent and not reinforced by leadership.
• Level 3 (Defined): Blameless learning, ownership models, and writing culture are org-wide norms with clear expectations and tooling.
• Level 4 (Optimizing): Culture is continuously measured and improved; safety is high, learning is fast, and practices evolve with evidence.

Ideas for discussion¶

• Where in our organization do people not feel safe to say "I don't know" or "I disagree," and why?
• Do our incident reviews change the system, or just assign fault and move on?
• Are we rewarding heroics that we should be engineering away?
• Which important decisions from the past two years have no written record of their reasoning?
• How evenly is glue work and on-call load distributed across the team?
• Do our stated values match what actually gets people promoted here?

Key takeaways¶

• Values are the invisible operating system behind every technical decision; at scale, values must be explicit.
• Psychological safety is foundational; without it, other practices decay.
• Blameless learning converts failure into durable systemic improvement.
• Clear ownership ("you build it, you run it") tightens the quality feedback loop.
• Writing culture scales judgment across time zones and turnover.
• Sustainable pace and inclusion are long-term velocity multipliers, not costs.

References and further reading¶

• Amy C. Edmondson, "The Fearless Organization" and "Teaming"
• Google re:Work / Project Aristotle research on team effectiveness
• Sidney Dekker, "The Field Guide to Understanding 'Human Error'"
• John Allspaw, "Blameless PostMortems and a Just Culture" (Etsy Code as Craft)
• Nicole Forsgren, Jez Humble, Gene Kim, "Accelerate: The Science of Lean Software and DevOps"
• Gene Kim et al., "The Phoenix Project" and "The DevOps Handbook"
• Camille Fournier, "The Manager's Path"
• Will Larson, "An Elegant Puzzle: Systems of Engineering Management"
• Tom DeMarco and Timothy Lister, "Peopleware: Productive Projects and Teams"