The founder called me six months after closing their Series A. They'd grown from 3 to 18 engineers, and something had gone wrong. "The energy is different," she said. "When it was just me and two engineers, we moved fast, we argued about technical decisions, we cared deeply about quality. Now it feels... corporate. People show up, do their tickets, go home. The passion is gone."
She'd hired well—strong engineers from good companies. She'd paid competitive salaries. She'd bought the nice chairs and the good monitors. But somewhere along the way, the thing that made her early team special had dissipated. She couldn't name exactly what had been lost, but she knew it was gone.
What she'd lost was culture. Not the surface-level stuff—the perks, the office layout, the team events—but the deeper patterns: how technical decisions get made, what behaviors get rewarded, how people treat each other when things get hard. She'd assumed these patterns would persist automatically as the team grew. They hadn't. Culture doesn't scale by accident; it either gets built deliberately or it gets replaced by defaults—usually bad ones.
At SmithSpektrum, I've worked with dozens of founders on this exact problem[^1]. The pattern is consistent: the first ten hires feel natural, almost effortless. The culture just exists because everyone was hired by the founders and absorbs their values through proximity. Then somewhere between fifteen and thirty people, the culture starts fragmenting. New hires absorb values from their immediate teams rather than from founders. Subcultures form. The original energy dissipates. By the time founders notice, significant damage has been done.
Building engineering culture deliberately—naming it, reinforcing it, evolving it—is one of the most important things founders do. It's also one of the least understood.
What Culture Actually Is
Culture is not what you say. Culture is what you do.
It's not the values posted on your website. It's the behaviors that actually get rewarded. It's not what you claim to believe about quality or speed or collaboration. It's how you behave when quality, speed, and collaboration are in tension with each other.
An engineering culture that says it values quality but ships features before they're ready has a culture that values speed over quality—regardless of what the wall poster says. A culture that says it values collaboration but promotes engineers who hoard knowledge has a culture that values individual achievement—regardless of the all-hands messaging.
This matters because engineers are observant. They watch what happens, not what's claimed. They notice who gets promoted, who gets fired, who gets listened to, whose ideas get resources. They calibrate their behavior to match the actual reward system, not the stated one. If you want to change the culture, you have to change the reward system—and that requires understanding what's actually being rewarded today.
Culture also isn't static. What works at ten engineers doesn't work at thirty. What works at thirty doesn't work at a hundred. The practices that defined your early culture may need to evolve as you scale. The engineer who set technical direction by walking around and having conversations can't do that with five teams across three time zones. The culture has to adapt, and adaptation requires intention.
The First Ten: Culture by Osmosis
In the earliest days, culture forms through proximity to founders.
When there are five or eight engineers, everyone works directly with the technical founders. They see how decisions get made. They observe how the founders respond to bugs, to delays, to disagreements. They absorb attitudes toward risk, toward quality, toward customers. The culture is transmitted through daily interaction without anyone consciously teaching it.
| Culture Element | How It Shows Up | How to Assess | Red Flag |
|---|---|---|---|
| Psychological safety | People admit mistakes openly | Ask about last failure | Blame culture |
| Technical excellence | Code review thoroughness, testing | Look at merged PRs | "Ship it and fix later" |
| Ownership | Engineers drive decisions | Who decides scope/timeline? | Waiting for permission |
| Collaboration | Cross-team work is smooth | Ask about dependencies | Finger-pointing |
| Learning | Time for growth, experimentation | Training budget, hack time | "No time for that" |
This works because the feedback loop is tight. An engineer who makes a decision inconsistent with founder values gets corrected immediately—often before they even realize there was a misalignment. The founder says, "Actually, we always check with customers before building that," and the engineer learns. Multiply this across hundreds of small interactions, and culture gets transmitted effectively.
The danger of this phase is assuming it will continue. Founders think, "I hired people like me. They get it. The culture will persist." But they hired people who absorbed culture through direct exposure. When those people hire others, and those others don't have direct founder exposure, the transmission chain breaks. What gets passed down is a diluted version, shaped by each person's interpretation rather than direct experience.
Some founders try to extend this phase artificially—insisting on interviewing every hire, having the entire team in one room, keeping the company small. This works for a while but doesn't scale. Eventually you need more engineers than founders can personally acculturate. The question isn't whether this phase ends; it's whether you've built systems to replace it before it does.
Making Culture Explicit
The transition from osmosis to intentional culture-building usually happens between ten and twenty engineers.
Making culture explicit means naming the values and behaviors that define how you work. Not corporate-speak values that could apply to any company—"integrity," "excellence," "teamwork"—but specific values that describe actual trade-offs you make.
"We ship fast and fix fast" is a value that means something. It says you'll accept some bugs in production in exchange for speed, and you'll prioritize fixing them quickly when they occur. A different company might value "we ship when it's ready"—accepting slower delivery for higher quality. Neither is objectively better; both are legitimate choices. But you have to choose, and you have to name the choice.
"We debate ideas, not people" describes how disagreement works. It says you expect vigorous technical debate, but the debate is about the work, not about proving someone wrong or making someone look bad. A different company might value "trust the expert"—deferring to whoever has the most domain knowledge. Again, both are valid; what matters is that you've chosen and named it.
The process of making culture explicit often surfaces disagreements among founders. One founder believes in moving fast and breaking things; another believes in careful planning. One thinks the best idea should win regardless of source; another thinks experience should carry weight. These tensions exist in every founding team, but they're rarely surfaced until you try to write down what you believe.
The conversation is valuable precisely because it's hard. Working through disagreements about values—and reaching actual consensus, not papering over differences—creates a foundation that can be transmitted to others. If the founders aren't aligned, the culture won't be aligned either.
Transmission Mechanisms
Once culture is explicit, you need mechanisms to transmit it to new people.
Onboarding is the most important mechanism. The first weeks at a company shape an engineer's understanding of how things work. Deliberate onboarding—not just "here's your laptop, good luck"—communicates what matters. It should include explicit discussion of values: what they mean, why they exist, what they look like in practice. It should include stories: examples of engineers who exemplified the values and what happened. It should include shadowing: watching how experienced engineers actually work, not just hearing about it.
The best onboarding programs pair new engineers with culture carriers—people who deeply understand and embody the values. This isn't the same as a buddy who helps you find the coffee machine. A culture carrier can explain why decisions get made certain ways, can model the right behaviors, can course-correct when they see misalignment. They need to be chosen carefully and supported in the role.
Rituals reinforce culture through repetition. A weekly demo where engineers show what they've built communicates that building things matters. A postmortem process that focuses on learning rather than blame communicates psychological safety. An architecture review that genuinely considers alternatives communicates that decisions should be debated. The rituals you create—and how you actually conduct them—become culture transmission mechanisms.
Recognition and rewards are the most powerful transmission mechanism. What gets celebrated? Who gets promoted? What behaviors get called out positively in all-hands? Engineers pay attention to these signals. If you want to build a culture of mentorship, celebrate people who mentor. If you want a culture of ownership, promote people who take ownership. If you want a culture of quality, recognize people who catch bugs before production. The behavior you reward is the behavior you'll get.
The Role of Technical Decisions
Engineering culture is shaped heavily by how technical decisions get made.
In some cultures, senior engineers make architectural decisions and others implement. In others, decisions are made collectively through RFCs and discussion. In others, whoever is building something gets to decide how to build it. None of these is inherently right; each has trade-offs. But the pattern you establish becomes culture.
If you want engineers to take ownership, they need real decision-making authority. Nothing kills ownership faster than making engineers ask permission for every technical choice. But ownership doesn't mean isolation—engineers can have authority while still getting input from others. The art is finding the balance between autonomy and coordination that matches your values.
Code review culture matters more than most founders realize. How code review is conducted—whether it's nitpicky or high-level, adversarial or collaborative, fast or slow—shapes how engineers feel about their work. I've seen cultures where code review is feared and cultures where it's welcomed. The difference comes from how the culture was established and reinforced.
Technical debt decisions reveal true priorities. Every team accumulates technical debt; the question is how you handle it. A culture that never allocates time for debt reduction is a culture that doesn't really value code quality, regardless of stated values. A culture that's willing to slow feature development for important refactors is a culture that backs up its quality claims with resource allocation.
Hiring for Culture
Hiring is where culture gets built or eroded, one decision at a time.
Hiring for culture doesn't mean hiring people who are similar to existing team members. That path leads to homogeneity and blindspots. Hiring for culture means hiring people who share your values and ways of working—regardless of their background, personality, or working style.
The distinction matters. An engineer who is quiet and introverted can absolutely share a culture that values vigorous technical debate—they may just express it differently than an extroverted colleague. An engineer from a completely different background can share a culture that values ownership—their experience expressing ownership may just look different.
Identifying cultural fit requires asking the right questions. Don't ask abstract questions about values; ask about specific situations. "Tell me about a time you shipped something before it was ready. What happened? What did you learn?" The answer reveals their actual relationship to speed versus quality trade-offs—not what they think you want to hear, but how they actually operate.
Reference checks are underutilized for culture assessment. Former colleagues can tell you how someone actually behaved, not how they present in interviews. Did they take ownership or wait for direction? Did they elevate others or hoard knowledge? Did they handle disagreement constructively? These behavioral patterns persist across companies.
The hardest culture decision is passing on a skilled engineer who doesn't fit the culture. Technical skills are valuable, but a culture mismatch creates problems that ripple outward. One engineer who doesn't share the values—who cuts corners when the culture values quality, who hoards information when the culture values sharing, who dismisses feedback when the culture values collaboration—can damage the culture far more than their technical contributions benefit it.
Evolving Culture as You Scale
Culture must evolve as the organization grows, but evolution isn't the same as abandonment.
Some practices that define early culture don't scale. When you have five engineers, everyone can weigh in on every technical decision. When you have fifty, that's a recipe for paralysis. The culture value—something like "everyone's perspective matters"—can persist, but the practice has to change. Maybe you move from consensus to designated decision-makers who must solicit input. The value is preserved; the implementation evolves.
The core values should be relatively stable—they represent who you are as a company. The practices that express those values can and should change. Founders who try to freeze practices in place end up with organizations that can't scale. Founders who let values drift end up with organizations that have lost their identity. The goal is evolving practices while preserving values.
Subcultures will form as you grow, and some variation is healthy. The infrastructure team might have different norms than the product team—different relationships to risk, different relationships to deadlines. What matters is that the core values are shared across subcultures. Each team can have its own flavor while still being recognizably part of the same organization.
Major transitions—new executives, acquisitions, rapid hiring—are cultural risk moments. Each represents an influx of people who weren't shaped by the existing culture. Managing these transitions requires extra attention: more explicit culture communication, more careful assessment of cultural fit, more deliberate integration.
When Culture Goes Wrong
Sometimes culture goes wrong despite good intentions.
A common failure mode is values-reality mismatch. The stated values say one thing; the actual behaviors say another. Engineers experience cognitive dissonance—they hear about quality but see shortcuts rewarded. This mismatch is more corrosive than having no stated values at all. At least without stated values, engineers aren't being told one thing while experiencing another.
Another failure mode is toxic positivity. The culture emphasizes positivity so strongly that legitimate concerns can't be raised. Engineers stop flagging problems because raising problems is seen as negative. Technical debt accumulates. Bugs ship. Everyone smiles through the dysfunction because the culture doesn't permit acknowledging that things aren't working.
A third failure mode is values weaponization. The culture values become tools for attacking others. "That's not ownership" becomes a way to shut down disagreement. "That's not quality-focused" becomes a way to nitpick colleagues into submission. Values should enable good work, not provide ammunition for internal politics.
Recognizing when culture has gone wrong requires listening. Exit interviews are one source—people who are leaving will tell you things that people who are staying won't. Engagement surveys are another, though the questions have to be specific enough to surface real problems. Direct conversation with trusted engineers who will tell you the truth is perhaps most valuable.
Fixing broken culture is hard but possible. It starts with honestly acknowledging the gap between stated and actual values. It requires changing the behaviors—especially leadership behaviors—that contradict the values. It often requires parting ways with people who embody the wrong culture, regardless of their other contributions. And it requires patience—culture doesn't change overnight.
The founder whose culture had dissipated? We spent three months rebuilding it. First, she got honest about what the actual culture had become—she named the gap between early days and current reality. Then she articulated what she wanted the culture to be—not a return to the past, but a version that could work at their current scale. She changed some practices, reinforced the values in hiring and promotion decisions, and modeled the behaviors she wanted to see.
A year later, the culture wasn't identical to the early days—that wasn't possible or even desirable at their new size. But the essential character had returned. Engineers cared about technical decisions. People argued constructively about architecture. Quality mattered not because of process but because of values.
"I learned that culture doesn't maintain itself," she told me. "You either build it deliberately or it becomes something you didn't choose."
References
[^1]: SmithSpektrum engineering leadership advisory, culture building, 2019-2026. [^2]: Schein, Edgar. "Organizational Culture and Leadership," 5th Edition, 2017. [^3]: Horowitz, Ben. "What You Do Is Who You Are," 2019. [^4]: Netflix Culture Memo, "Freedom & Responsibility."
Building engineering culture? Contact SmithSpektrum for organizational design and leadership advisory.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum