Engineering Culture: How to Build It from Scratch

Spotify published its “squads, tribes, and guilds” model in 2012 and the industry copied it en masse. The problem: Spotify has publicly admitted that model never worked as described in the famous videos. It was an aspiration, not reality. And thousands of companies adopted it without questioning it.

Engineering culture is not copied from another company. It is built deliberately, adapted to your context, your people, and your objectives. There is no universally “correct” culture. There is the culture that allows your team to do their best work.

This guide covers how to build an engineering culture from scratch, which elements are fundamental, what mistakes to avoid, and how to maintain the culture as the team grows from 5 to 50 people.

What Engineering Culture Is

Practical Definition

Engineering culture is the set of values, practices, and unwritten norms that determine how the technical team makes decisions, solves problems, and works together.

It is not:

• A “values” document nobody reads
• A list of tools and technologies
• Office design or company perks
• Rules written in a handbook

It is:

• How technical decisions are made (consensus, individual authority, committee)
• How errors are handled (blame vs learning)
• What gets prioritized when there is conflict (speed vs quality, features vs technical debt)
• How knowledge is shared (documentation, pair programming, internal talks)
• What behaviors are rewarded and which are tolerated

Why It Matters

A strong engineering culture directly impacts:

Productivity. Teams with clear culture make decisions faster because guiding principles are internalized. They do not need to escalate every decision.

Retention. Senior engineers have options. They stay in places where they feel respected, have autonomy, and can do work they are proud of.

Quality. When quality is a cultural value (not just a rule), engineers maintain it even when nobody is watching.

Hiring. A reputed engineering culture attracts talent. Internal referrals are the most effective hiring channel, and they only work if your team wants to recommend your company.

The Pillars of a Solid Engineering Culture

Pillar 1: Ownership (End-to-End Responsibility)

Teams or individuals are responsible for their components or services from code to production. They do not write code and “throw it over the wall” to another operations team.

How it is implemented:

• Whoever writes the code deploys it
• Whoever deploys it monitors it
• Whoever monitors it responds when it fails
• Teams have autonomy to decide how to build and operate their services

Benefits:

• Incentivizes quality (if your code fails at 3AM, you fix it)
• Reduces the distance between decision and consequence
• Empowers engineers to make decisions

Risks:

• Without support, it can lead to burnout
• Needs clear boundaries (on-call rotation, hour limits)
• Does not work if the team lacks adequate tools

Pillar 2: Technical Excellence

Technical excellence does not mean perfection. It means the team has clear standards and consistently works to maintain them.

Concrete practices:

Mandatory code reviews. All code goes through at least one review before being merged. Not as a quality gate but as a practice of learning and consistency.

Testing as norm. Tests are not optional. Testing level adapts to context (more tests for critical logic, fewer for prototypes), but the practice of testing is non-negotiable.

Managed technical debt. A fixed percentage of time (typically 15-20%) is dedicated to reducing technical debt. Do not wait until it becomes unsustainable.

Decision documentation. Important architectural decisions are documented in ADRs (Architecture Decision Records): what was decided, why, and what alternatives were discarded.

Blameless post-mortems. When something fails in production, what happened and how to prevent it is analyzed. Never “who did it.” The goal is to learn, not punish.

Pillar 3: Transparency

Information flows freely within the team. There are no knowledge “black boxes” or information silos.

Concrete practices:

Technical decisions in the open. Important decisions are discussed in public channels (not direct messages) so the entire team has context.

Visible metrics. Team metrics (DORA, availability, production bugs) are visible to everyone. Not to shame but to inform.

Shared technical roadmap. The team knows what will be built, why, and how it is prioritized. Not just the next sprint, but the 3-6 month vision.

Access to business information. Engineers understand the business context. They know why certain features are prioritized and how the product generates revenue.

Pillar 4: Continuous Learning

Technology changes constantly. A team that does not learn becomes obsolete.

Concrete practices:

Dedicated learning time. Between 5% and 10% of time is dedicated to learning: courses, conferences, experimentation, technical reading. Not as a perk but as an operational necessity.

Internal talks (tech talks). Regular sessions where team members share what they have learned. 30 minutes, no production pressure. Works best biweekly with voluntary participation.

Real retrospectives. Not theater. Retrospectives where real problems are identified, concrete actions are proposed, and previous actions are followed up on.

Safe experimentation. Mechanisms to try new technologies or approaches without risking production (feature flags, sandbox environments, “innovation” time).

Pillar 5: Autonomy With Alignment

Teams and individuals have autonomy to decide how to solve problems, but they are aligned on what problems to solve and why.

How it works:

• Leadership defines the “what” and “why” (business objectives, strategic priorities)
• Teams define the “how” (architecture, tools, process)
• There are guiding principles (not rigid rules) that ensure consistency between teams
• Deviations from principles are allowed if justified

The balance is delicate. Too much autonomy without alignment produces chaos (every team does what they want). Too much alignment without autonomy produces bureaucracy (everything requires approval).

How to Build Culture Step by Step

Step 1: Define the Values (a Few Hours)

Gather your team (or tech leads if the team is large) and answer:

• What matters most when there is a conflict between speed and quality?
• How do we want to handle errors?
• What level of autonomy does each person have?
• How do we make technical decisions?
• What differentiates us from other teams we have worked on?

No more than 5 values. If everything is important, nothing is. Examples: “End-to-end ownership,” “Quality as norm,” “Radical transparency,” “Continuous learning.”

Step 2: Translate Values Into Practices (First Weeks)

Each value translates into concrete, measurable practices:

Step 3: Lead by Example (Permanent)

Culture is defined by what leadership does, not what it says. If the CTO says quality matters but pushes to deliver without tests, the real message is “quality does not matter.”

Critical leadership behaviors:

• Participate in code reviews (not just as reviewer, also as author)
• Attend retrospectives and act on results
• Admit mistakes publicly
• Dedicate time to learning and communicate it
• Protect the team from external pressures that compromise quality

Step 4: Hire for Culture (From the First Hire)

Technical skills can be learned. Values are much harder to change. Hire people who fit the culture you want to build.

Do not confuse “cultural fit” with “people like me.” You want diversity of perspectives but alignment on fundamental values. A team where everyone thinks alike does not innovate. A team where nobody shares basic values does not function.

Step 5: Reinforce and Adjust (Continuous)

• Publicly recognize behaviors that reinforce the culture
• Quickly address behaviors that erode it
• Review values and practices annually (culture evolves)
• Regularly ask the team how they feel about the current culture

Common Mistakes When Building Culture

Copying Another Company’s Culture

What works at Google does not work at a 10-person startup. What works at Netflix does not work at a consultancy. Context matters enormously.

What you can copy: Specific practices that solve concrete problems (blameless post-mortems, ADRs, time for learning).

What you cannot copy: The general philosophy without adapting it. Netflix’s “freedom and responsibility” works with highly selective senior engineers. It does not work the same with a junior team.

Confusing Culture With Perks

Ping-pong tables, free snacks, and Friday beers are not culture. They are perks. A strong culture with modest perks retains better than a weak culture with luxurious perks.

Not Addressing Behavior Problems

Tolerating toxic behaviors (aggressive communication, knowledge hoarding, systematic PR blocking) destroys culture faster than anything else. One toxic person can make five good people leave.

Declaring Values Without Practices

“We value quality” is empty if there are no concrete practices backing it up. Values without practices are aspirations. Practices without values are bureaucracy. You need both.

Scaling Culture From 5 to 50 People

From 2 to 5 People

Culture is implicit. Everyone knows each other, works together, and norms are transmitted through osmosis. The risk is not documenting anything and depending on collective memory.

Key action: Start documenting decisions and practices. You do not need a handbook, but you do need a living document describing how the team works.

From 5 to 15 People

Informal communication is no longer sufficient. You need more structured processes.

Key actions:

• Formalize code reviews and the deploy process
• Establish regular retrospectives
• Create documented onboarding for new members
• Define who makes what types of decisions

From 15 to 50 People

Teams fragment into sub-teams. Culture can diverge between teams if not actively maintained.

Key actions:

• Create guilds or cross-functional groups to maintain technical consistency
• Establish shared architectural principles
• Implement a calibration process between managers
• Organize regular events that bring the entire technical team together
• Hire or promote managers who fit the culture

How to Measure Culture

Periodic Surveys

Anonymous quarterly questions:

• “I feel safe to admit mistakes” (1-5)
• “I have autonomy to make decisions about my work” (1-5)
• “I receive useful and constructive feedback” (1-5)
• “I understand why we prioritize the projects we do” (1-5)
• “I would recommend this company to an engineer friend” (1-10, eNPS)

Indirect Indicators

• Voluntary turnover: If people are leaving, something is not working
• Onboarding time: How long it takes a new member to be productive
• Participation in optional activities: Tech talks, hackathons, documentation contributions
• Referral ratio: How many hires come through employee recommendations

Conclusion

Engineering culture is not created with a document or a one-day workshop. It is built deliberately with clear values, concrete practices, and leadership that reinforces them every day.

Three principles for building a solid engineering culture:

1. Few, concrete values. Maximum 5, translated into measurable practices. If you cannot measure it, it is not a practice, it is a wish.
2. Leadership defines culture. What you do matters infinitely more than what you say. If you want a quality culture, your code must go through code review.
3. Culture is continuous maintenance. It is not a project with an end date. It is a daily practice that requires constant attention.

If you need help building or improving your team’s engineering culture, our free technical audit includes an evaluation of team practices and dynamics.