Understanding culture

Many people are aware of culture, and understand that it is important. But often people struggle to define it, and even fewer can articulate the impact it has on the success of an organisation. There are many in-depth explorations and definitions of organisational culture, but the best description is from Edgar Stein’s, Organisational Culture and Leadership.

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. — Edgar Stein

Edgar focuses on the concept of beliefs. A belief is a viewpoint or framework for understanding and interacting with the world. He argues that the early actions of leaders create beliefs, which are further strengthened in the face of repeated success and survival. Beliefs start to unconsciously influence every action taken by the individuals within an organisation. Over time, beliefs solidify into a shared understanding — a culture. More succinctly, culture is the way things are done here.

“Culture is the way things are done here.”

The unconscious influence of culture is precisely what makes it so powerful. Research shows that once you establish a culture, it becomes implicit, enduring and highly impactful. From implementation, to hiring, culture plays a role in every single decision made at an organisation. The question then becomes in what manner does culture impact these decisions, and if we focus on software products¹, is there a culture that leads to more successful outcomes?

Non-technology organisations versus technology-centric cultures

To be able to answer the question of the impact of culture, I considered my experiences working within technology at numerous organisations. I noticed that organisations whose primary business was not technology or software struggled to successfully execute, despite them adopting the same tools and practices. I hypothesised that an organisation’s poor technology execution is due to the fundamental cultural differences between delivering software and non-software products.

To understand if this was the case, I wanted to dive into some of the differences that may exist between organisations delivering software solutions to teams that primarily didn’t. I started by defining both extremes. On one side are the long-running, slower moving traditional organisations whose primary business was not delivering technology and on the other side are fast moving, newer technology-centric organisations. These factors are generalisations, most companies are between these dimensions. However, this framework is useful for exploring if the impact of culture is different between types of organisations.

Uncertainty and iteration

Traditional organisations often operate within largely stable core business processes in long-established sectors. These factors create cultures that are prescriptive and cautious. This caution leads to a requirement of certainty across the business. Caution causes feedback cycles to expand, leading to more top down decision-making, and a restriction in the ability of teams to creatively solve problems. Cautious practices are valuable to traditional organisations because they protect the organisation from making costly errors and give executives increasing control over outcomes. For these traditional organisations, their fear of risk obstructs its technology teams from efficiently problem-solving. Over time, these organisations typically find themselves a step behind their competitors as their technical teams are unable to get to the root of customer problems.

For technology-centric organisations, the opposite is true. They embrace uncertainty, and see their comfort in uncertainty as an asset. These organisations thoroughly understand that the speed of change in technology is increasing, and roles and responsibilities are merging. To deliver features in increasingly growing uncertainty, technology-centric teams align their values to risk-taking and constant evolution. This experimentation leads to both greater success through iteration and a more in-depth understanding of customer pain-points. For effective software teams, uncertainty, and exploration is a feature, not a bug. The ability to navigate and explore uncertainty is essential to optimising outcomes.

For effective software teams, uncertainty, and exploration is a feature, not a bug.

Communication & dependencies between teams

Communication is one of the most important factors when considering the differences between traditional and technology-centric cultures. Building complex software requires large teams to collaborate effectively, which makes software teams highly sensitive to communication structures. Organisational structure has a large impact on the communication between teams. A well-designed organisational structure allows communication to flow naturally between team members with the same objectives and reports. When the reports become fragmented or the teams expand, communication becomes more difficult.

Melvin Conway was the first to highlight the relationship between communication, organisation structure, and system design.

Conway’s Law — Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure. — Melvin Conway

Conway’s law can be expanded on, specifically regarding digital products. In Coplien and Harrison’s book about agile organisational patterns;

If the parts of an organisation (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organisations do not reflect the relationships between product parts, then the project will be in trouble … Therefore, you must ensure the organisation is compatible with the product architecture

Conway’s law has been in seen in studies at large technology firms. Organisations with increased dependencies and greater organisational complexity being the most significant predictor of errant release code. This is over an above other factors such as code churn, code complexity and the number of pre-release bugs.

Traditional organisations have sought to combat this. They have embraced numerous agile practices (scrum, scaled agile, etc.), but in practice management teams implement these standards with pre-existing communication channels, and limited autonomy. This leads to implementation of these agile practices without adhering to the guiding principle of communication efficiency. The key mistake Traditional organisations make is in assuming that by simply applying agile organisational structures they will get better product outcomes. In reality, regardless of the organisational structure, if communication structures remain top down and teams cannot reduce dependencies with each other, changing structure can actually reduce the quality of a team’s output further.

The key mistake Traditional organisations make is in assuming that by simply applying agile organisational structures they will get better product outcomes.

Technology-centric organisations understand that the key is not org structure, but instead communication structure. Technology-centric organisation work in smaller, decoupled, and empowered teams because these structures optimise communication efficiency. The focus is not on the structure of their teams, but ensuring that the teams can work with the least amount of friction and the most amount of autonomy.

Linear Delivery

Traditional organisations have tried and tested structures that require predictable delivery. A project or task has a set time and aside from an expected amount of error, the results are easy to predict. These traditional organisations expect these delivery pipelines to be aligned across the organisation, including software. Leadership at Traditional organisations expect their software teams to function this way and often dictate product outputs, in some cases devising entire suites of products up front, without experimentation or understanding of value.

Technology-centric organisations produce product outputs non-linearly. This is because software value streams are not manufacturing processes², but complex collaboration networks that need to be aligned to products. The impact of linearly delivered software is exacerbated in larger organisations because as software scales, productivity declines and waste increases due to disconnects between the architecture and the value stream. Rather than focusing on meeting expected outputs of software projects, Technology-centric organisations timelines are aligned around value. Approaches and outputs evolve freely over time as more information is learned, and early experiments are iterated on.

Approach to technical talent

One of the biggest drivers of the success of a product is the quality of technical talent available. The market for top technical talent is incredibly competitive. There is a low supply and high demand for top talent, particularly more senior talent. Both of these factors make talented technical employees difficult to source and hard to retain. Furthermore, top talent is often very aware of the effect of the culture and environment on their success. Talented engineers and technologists care about more than compensation; top talent wants to be involved in ideation, to be surrounded by like-minded individuals, and be given the autonomy to make decisions. In Patrick Kua’s excellent talk on engineering culture, he describes it perfectly;

“Engineers join software teams because they want to solve problems. They don’t want to just implement code.” — Patrick Kua

Traditional organisations struggle to retain and attract top technical talent needed to deliver products. Traditional organisations frequently view technical talent as a commodity. These organisations are either reluctant to provide adequate compensation or empowering environments. Low-quality talent produces poorly engineered solutions, and the inability to retain talent reduces team efficiency, ideation, and motivation.

Technology-centric organisations invest heavily in their ability to attract and retain talent. They understand the importance of providing the right conditions, incentives, and structure. They ignore traditional constraints like time in role, location, or specific/homogenous backgrounds to instead fully focus on hiring and promoting talent that can form collaborative and driven teams.

Changing culture

Working through this framework, it is evident that culture is truly a significant contributor to products success, but often organisations struggle to address it. This is not from a want of trying, there are numerous structural reasons why organisations struggle to change their culture;

• Over time, companies lose knowledge of why a given cultural attitude or practice happens and how it leads to success. The lack of understanding in why organisational practices exist, makes teams wary of challenging it. A lack of cultural understanding often present in larger organisation or organisations that do not have clear focus on their company culture.

• Culture takes a long time to establish, but once it does, it solidifies. Trying to break apart long-established cultures requires immense organisational leverage, which means it has to come directly from the most senior leader at the organisation. Cultural change requires focused leaders with the willingness to make culture a priority.

• Culture is an element of an organisation that is easy to feel, but not as easy to quantify or measure. This immeasurable nature of culture makes it difficult to justify the investment in changing it, or measure the impact of strategies to improve it. This makes organisations with highly analytical leaders less likely to change their culture.

These reasons led me to believe that there was a need for a clear framework to help evaluate an organisation’s culture and help to understand the mechanisms that drive its change.

The cultural infrastructure framework

Through research, input from colleagues and my experiences working with and advising technical and product teams, I arrived at a set of factors that were key for evaluating and influencing culture. I condensed these factors into a framework which I first coined to discuss the impact of culture on Apple’s services and app store strategy to as the cultural infrastructure of a technical team. It has three parts;

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

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

• Incentives & Business Models — how an organisation motivates its employees to produce results and conducts its business to earn a profit.** These are the levers that reinforce and shift culture.**

In the same way as technology infrastructure is the arrangement of components that enables a product to function and change; the cultural infrastructure is a summary of the cultural components that allow a product to design and delivered effectively.

To build effective product cultures, tech leaders need to carefully set and adjust these factors to create high preforming cultures. Larger organisations have the added complexity of subcultures — areas of an organisation that operate slightly differently from the core culture of an organisation. Beyond setting an overall company culture, this framework can be used to understand subcultures and the interactions between them. Understanding the impact of the overall culture and various subcultures is relevant to numerous key processes within an organisation, such as:

• Product strategy
• Operating model and restructuring plans
• Vendor selection
• Outsourcing strategy
• HR and recruitment strategy

In further articles in this series I will explore the three pillars of cultural infrastructure in more detail, expand on the concept of subcultures, and cover how they input into the process I referenced out above.