Platforms and frameworks eat culture for breakfast

This blog is based on Nigel Kirsten's presentation "Platforms and frameworks eat culture for breakfast" from SymfonyCon 2024. Kirsten is Chief Product Officer at Upsun. We utilized AI tools for transcription and to enhance the structure and clarity of the content.

At SymfonyCon 2024, Nigel Kirsten, Chief Product Officer at Platform.sh, shared a simple but sharp idea: the tools we choose do not just support our work. They shape how we work together. Pick the right platforms and frameworks, and you can nudge a team toward better habits without a single “culture program.”

Why this matters

Peter Drucker, the management guru famous for his organizational insights, once said that "culture eats strategy for breakfast." His point was simple but profound: no matter how brilliant your strategy, if your organizational culture can't execute it, you'll fail.

Kirsten builds on this idea with a modern twist. In today's software-driven world, he argues that "platforms and frameworks eat culture for breakfast." The technology choices we make as developers don't just affect our code; they fundamentally shape how our organizations work, collaborate, and evolve.

Understanding organizational culture types

Management thinker Peter Drucker made “culture eats strategy for breakfast” famous. Nigel agrees that culture is critical. What is different today is the power of software. Our tools shape our daily tasks, our handoffs, and our sense of ownership. Choose well, and you change how teams plan, test, deploy, and learn.

Understanding organizational culture types

To understand how technology influences culture, we must first recognize the various types of organizational cultures that exist. Ron Westrum's research identifies three primary types:

• Pathological (Power-Oriented) organizations operate through fear and control. Failure leads to scapegoating, teams work in isolated silos, and bringing bad news to leadership often results in shooting the messenger. Cooperation across the organization remains minimal.
• Bureaucratic (Rule-Oriented) organizations focus heavily on rules and procedures. While they allow some cross-functional work, they discourage innovation and maintain narrow responsibilities for each role. Everything becomes about following the established process rather than achieving outcomes.
• Generative (Performance-Oriented) organizations represent what most tech companies aspire to become. They encourage high cooperation across teams, share both risks and responsibilities organization-wide, promote collaboration between different departments, and treat failures as opportunities for inquiry and improvement.

When developers complain about organizational culture, they're usually expressing frustration that their workplace doesn't operate as a generative culture.

Why traditional culture change programs fail

The statistics on organizational change are sobering. While popular business wisdom claims that 70% of change management initiatives fail, the reality is more nuanced. The original research suggested that 50-70% of organizations fail to achieve the dramatic results they seek, a significant difference from outright failure, but still concerning.

Kirsten's experience consulting with various organizations confirms these challenges. Most culture change programs fail because they focus on only one aspect of what researchers call "socio-technical systems."

The socio-technical systems reality

Every organization that uses technology operates as a socio-technical system with four interdependent components:

1. Technology - The tools and platforms used
2. Tasks - The work that needs to be accomplished
3. People - The individuals and their skills
4. Organizational structure - How the company is organized

Changes in any one area create ripple effects across all others. When you adopt new technology, it changes what tasks are possible. New tasks require individuals to acquire a diverse range of skills. These changes often necessitate adjustments to organizational structure.

This interconnectedness explains why culture change programs that focus solely on "people issues" or "technical solutions" typically fall short. Successful transformation requires understanding and addressing all four components simultaneously.

The container revolution: A case study in cultural change

The rise of containerization technology provides a perfect example of how technical choices drive organizational transformation. Before containers, most large organizations maintained strict separation between development and operations teams. Developers wrote code and handed it over to operations teams for deployment, a process that often created bottlenecks and friction.

Containers changed this dynamic dramatically. Suddenly, developers could package their applications in a way that made deployment much more straightforward. This wasn't just a technical improvement; it was a fundamental shift in organizational power and responsibility.

"The big change that containers made was that suddenly devs could take on responsibilities in an organization that previously had to be done by the operations team," Kirsten explains. "In most companies, there were more devs than there were operations people, so this essentially democratized the process of deployment."

The results were profound. The traditional system administrator role largely disappeared, replaced by infrastructure engineers who were essentially software developers specializing in operational concerns. Many large organizations literally restructured their teams, reducing operations staff while hiring more developers.

This transformation couldn't have been predicted solely from the technical specifications of container technology. The cultural and organizational changes emerged from the practical implications of how the technology was used.

How human psychology complicates change

Understanding why technology choices matter for culture requires acknowledging an uncomfortable truth: humans are imperfect information-processing machines. We're subject to numerous cognitive biases that influence how we make decisions and adapt to change.

Kirsten highlights several biases that are particularly relevant to software teams:

• The anchoring effect demonstrates how the first piece of information we receive heavily influences our subsequent judgments, even when that initial information is completely random. This affects everything from project estimates to architectural decisions.
• The IKEA effect reveals that people value things significantly more (about 63% more, according to research) when they've participated in building them. This has significant implications for software refactoring and re-architecting decisions; teams become emotionally attached to code they've written, making it difficult to replace even when better alternatives exist.
• Loss aversion refers to the phenomenon where the psychological impact of losing something is roughly twice as strong as the positive impact of gaining an equivalent amount. This makes it emotionally challenging for teams to throw away existing code, even when starting fresh would be more efficient.

These biases aren't character flaws; they're part of human nature. But they do make certain types of organizational change more difficult, particularly when that change involves abandoning existing work or approaches.

Choosing technology that drives positive change

Understanding these psychological realities helps explain why thoughtful technology choices can be so powerful. Good platforms and frameworks can work with human nature rather than against it.

Kirsten analyzed Symfony through this lens and found several attributes that promote a healthy organizational culture:

• Dependency injection facilitates collaboration among different teams by allowing them to work on distinct parts of a project while maintaining clean interfaces between components. This technical feature directly supports better cooperation.
• Modularity and the toolbox approach allow teams to adopt practices incrementally without requiring massive organizational changes. Teams can start small and build momentum.
• An opinionated methodology provides consistency across teams, making it easier for developers to transition between projects and for team members to understand each other's work.
• Style Consistency reduces cognitive load when switching between different parts of a codebase, supporting fluid team membership and reducing the barriers to collaboration.

These technical features create organizational affordances, making certain types of collaboration easier and more natural.

The double-edged nature of technology choices

Technology choices can also drive undesirable cultural changes. Kirsten shared his own experience from the early 2000s, when the immediate feedback loop of PHP development led him into problematic patterns.

"I could edit files directly on a server via SFTP and suddenly they were there," he recalls. While this immediacy felt powerful, it created several organizational problems. The lack of formal processes meant no one else on his team felt comfortable making changes to his code. Testing happened in production. He became a single point of failure, unable to take vacations and ultimately burning out.

The problem wasn't PHP itself, but rather the lack of organizational affordances in his development setup. The technology made certain things easy (rapid deployment) while making others difficult (collaboration, testing, knowledge sharing).

Long-term support (LTS) versions exemplify another instance of how technical decisions create organizational trade-offs. While LTS releases provide stability for large customers, they can also slow innovation by removing the pressure to stay current with updates.

Practical steps for driving cultural change through technology

For individual developers and team leads, Kirsten offers concrete advice for using technology choices to improve organizational culture:

If you want shared responsibility for testing, don't just talk about it build it into your infrastructure. Create CI/CD pipelines for every new project, even if they start empty. Make it trivially easy for someone to add a test when they find a bug.

If you want fluid team membership, invest in consistency. Use linting tools, style guides, and shared frameworks that make it easier for developers to move between different parts of the codebase.

If you want visibility across the organization, build observability into your service frameworks from the outset. Don't make monitoring and logging an afterthought; make them automatic consequences of deploying new services.

The key principle is to create "walking skeletons", basic infrastructure that makes good practices the path of least resistance, instead of requiring developers to remember to do the right thing, make the right thing the default. 

Leadership implications

For engineering leaders, the message is equally important: pay attention to the technology choices your teams are making. These decisions aren't just technical—they're shaping the culture of your organization, whether you realize it or not.

Look at your technology roadmap through a cultural lens. Ask questions like:

• How will this platform affect collaboration between teams?
• What behaviors will this framework encourage or discourage?
• Are we making it easier or harder for people to do high-quality work?

The goal isn't to micromanage technical decisions, but to understand their broader implications and ensure they align with the organizational culture you're trying to build.

Moving beyond complaints about culture

One of Kirsten's most practical pieces of advice is to stop talking about "culture" as an abstract concept. Culture often feels too broad and intangible for individual contributors to influence directly.

Instead, focus on specific, actionable organizational dynamics. Rather than saying "we need better culture," identify concrete problems: "We need better cooperation between the frontend and backend teams," or "We need to reduce the time it takes to get feedback on new features."

These specific problems can often be addressed through thoughtful technology choices combined with process improvements.

The path forward

The relationship between technology and organizational culture is complex and often unpredictable. We couldn't have foreseen how smartphones would enable ride-sharing services that would change urban transportation, or how social media would transform the travel industry through influencer culture.

Similarly, the full organizational implications of our technology choices often only become clear in retrospect. But this unpredictability doesn't mean we're powerless. By understanding the principles of socio-technical systems and human psychology, we can make more informed choices about the platforms and frameworks we adopt.

As developers, we're not helpless observers of organizational culture; we're active participants in shaping it. Every time we choose a framework, set up a deployment pipeline, or design an API, we're influencing how our organizations work.

The question isn't whether our technology choices will affect culture; they will, whether we think about it or not. The question is whether we'll be intentional about using these choices to create the kind of organizations we want to work in.

In a world where software continues to reshape every industry, developers who understand the relationship between technology and culture will be the ones who build not just better applications, but also better organizations. And in the end, better organizations build better software, creating a virtuous cycle that benefits everyone involved.