Defining Cultural Infrastructure

Culture is underrated and poorly understood

Most leaders will tell you culture matters. Very few can define it precisely, and fewer still can explain the mechanism by which it affects product outcomes. There are many in-depth explorations and definitions of organisational culture, but the best I have found comes from Edgar Schein:

Culture is the deeper level of basic assumptions and beliefs that are shared by members of an organisation, that operate unconsciously and define in a basic ‘taken for granted’ fashion an organisation’s view of its self and its environment.

The key word is unconsciously. Culture is not what you write on the wall or put in your onboarding deck. It is the accumulated set of beliefs, formed by early leadership decisions and reinforced by repeated success, that eventually operate without anyone noticing. Culture is the way things are done here. Research confirms that once established, culture becomes implicit, enduring and highly impactful. It shapes every decision: what gets built, who gets hired, how teams communicate, what risks get taken.

The question is whether there is a culture that consistently leads to better product outcomes. Having worked across organisations at different stages and in different industries, I believe the answer is clearly yes. But before I get to what that culture looks like, it is worth understanding why so many organisations get it wrong.

Why culture resists change

Organisations struggle with culture for three structural reasons.

First, over time companies lose the knowledge of why a given cultural practice exists and how it leads to success. When people do not understand the origin of a behaviour, they become reluctant to challenge it. This is especially common in larger or older organisations.

Second, culture solidifies. It takes a long time to establish, but once it does, breaking it apart requires immense organisational leverage. That leverage has to come from the most senior leader. Cultural change cannot be delegated to a programme or a consultant.

Third, culture is easy to feel but hard to measure. This makes it difficult to justify investment in changing it, and even harder to demonstrate progress. Organisations led by highly analytical leaders tend to deprioritise culture for exactly this reason.

What effective product cultures have in common

Rather than walk through a full taxonomy, the pattern I have observed repeatedly is that effective product cultures share a few specific traits.

They are comfortable with uncertainty. The best teams treat uncertainty and experimentation as a feature, not a bug. They align around value rather than predetermined outputs, iterating as they learn. Organisations that demand certainty from their technical teams end up restricting creative problem solving, expanding feedback cycles, and falling behind competitors.

They do not treat software delivery as a manufacturing process. Software value streams are complex collaboration networks that need to be aligned to products, not linear pipelines with predictable outputs. When organisations expect their technical teams to deliver like a factory floor, the impact gets worse at scale: productivity declines and waste increases due to disconnects between the architecture and the value stream. Effective teams have timelines aligned around value. Approaches and outputs evolve freely as more information is learned, and early experiments are iterated on.

They obsess over communication structure, not org structure. Melvin Conway observed that organisations produce systems whose structure mirrors their communication structure. Coplien and Harrison expanded on this in the context of agile organisations: if the parts of an organisation do not closely reflect the essential parts of the product, or if the relationships between organisations do not reflect the relationships between product parts, the project will be in trouble. This has been validated empirically. A study at Microsoft found that increased dependencies and organisational complexity were the most significant predictors of defective releases, over and above code churn, code complexity, and pre-release bugs.

The mistake many organisations make is assuming that adopting agile frameworks (scrum, scaled agile, etc.) will improve outcomes. In practice, management teams implement these structures on top of pre-existing communication channels and with limited autonomy. They adopt the ceremony without the guiding principle of communication efficiency. If communication structures remain top-down and teams cannot reduce dependencies, changing the org chart can actually make things worse. Effective teams are small, decoupled, and empowered because those structures optimise for communication efficiency and autonomy. The focus is not on the shape of the team, but on ensuring teams can work with the least friction and the most autonomy.

They invest seriously in technical talent. The market for top technical talent is extremely competitive, with low supply and high demand, especially at the senior end. Engineers and technologists care about more than compensation. They want to be involved in ideation, surrounded by capable peers, and given autonomy to make decisions. As Patrick Kua describes in his excellent talk on engineering culture: “Engineers join software teams because they want to solve problems. They don’t want to just implement code.” Organisations that treat technical talent as a commodity, or that are unwilling to provide empowering environments, end up with poorly engineered solutions and high attrition. The best organisations ignore traditional constraints like time in role, location, or specific backgrounds, and fully focus on building collaborative and driven teams.

The cultural infrastructure framework

Through research, conversations with colleagues, and my own experience working with and advising technical and product teams, I arrived at a set of factors that are key for evaluating and influencing culture. I condensed these into a framework I first used to discuss the impact of culture on Apple’s services and app store strategy, which I call the cultural infrastructure of a technical team. It has three parts.

Communication Structure is how the people within an organisation communicate and cooperate. It is primarily determined by the distribution of roles and responsibilities, but also by the channels and norms of communication. This is the mechanism that distributes and guides culture.

Values are the ethics and principles of a company and its employees. These form the beliefs that govern culture.

Incentives and Business Models describe how an organisation motivates its employees and conducts its business. These are the levers that reinforce and shift culture.

In the same way that technology infrastructure is the arrangement of components that enables a product to function and evolve, cultural infrastructure is the arrangement of cultural components that enables a product to be designed and delivered effectively. To build effective product cultures, leaders need to carefully set and adjust these three factors.

Subcultures and practical application

Larger organisations have the added complexity of subcultures: areas that operate differently from the core culture. Beyond setting an overall company culture, this framework can be used to understand subcultures and the interactions between them. Understanding these dynamics is relevant to product strategy, operating model design, restructuring plans, vendor selection, outsourcing strategy, and recruitment.

I will explore the three pillars in more detail in future writing.