Climate for learning: building generative engineering cultures

At the start of a DevSecOps transformation at a Tier-1 bank, we expected the hardest work to be technical: migrating legacy pipelines, integrating SAST, and automating compliance gates. We were wrong: culture was harder. Engineers had spent years watching incidents trigger blame and concerns about technical debt get treated as disloyalty. Staying quiet and following the process was the safest career move. Fixing the tooling was quick. Learned helplessness took much longer.

It took two years to understand that culture change is not a programme you run alongside the technical transformation. It is the transformation. Ron Westrum's research on organisational typologies provided the language, Amy Edmondson's work on psychological safety provided the framework, and the DORA research programme supplied the empirical evidence for the business case: generative culture is not a "nice to have", it is a statistically significant predictor of software delivery performance, organisational performance, and employee wellbeing. Every technical capability we invested in, CI/CD, observability, infrastructure as code, delivered returns only to the degree that the surrounding culture let engineers use them effectively.

Why culture is an engineering capability

A positive climate for learning gives people the safety to experiment and keep improving. In engineering organisations, culture is not separate from technical capability; technical capability grows out of it. You can deploy the most sophisticated CI/CD platform in the industry, but if engineers are afraid to push code to production because a failed deployment means a career-limiting incident report, your investment is wasted.

The Westrum organisational culture model

In 2004, sociologist Ron Westrum published "A Typology of Organisational Cultures" in the BMJ Quality & Safety journal. He identified three types of organisational culture based on how information flows:

Characteristic	Pathological (Power-Oriented)	Bureaucratic (Rule-Oriented)	Generative (Performance-Oriented)
Information	Hidden	Ignored	Actively sought
Messengers	Shot	Neglected	Trained
Responsibilities	Shirked	Narrow	Shared
Bridging	Discouraged	Tolerated	Encouraged
Failure	Covered up	Leads to justice	Leads to inquiry
Novelty	Crushed	Creates problems	Implemented

The model connects culture directly to outcomes. In generative cultures, information flows freely, failure leads to learning rather than punishment, and novelty gets implemented. The DORA research confirmed this empirically: Westrum culture predicts both software delivery performance and organisational performance.

What generative culture looks like in practice

A generative culture is one where individuals feel safe to take risks, learn from failures, and share ideas openly. Leading engineering teams in banking, I saw it in specific, observable behaviours. Postmortems were blameless: we ran them under a strict rule that postmortem documents could not contain individual names, and the focus was always on systemic factors, the process, tooling, or environmental condition that allowed the failure to occur. Communication was open and honest, including the ability to challenge decisions made by senior leaders without fear of retaliation. Team members felt safe to admit mistakes and ask questions without fear of retribution. And ownership was shared: siloed "my code, your problem" thinking gave way to collective responsibility for quality, reliability, and security.

Example: changing incident response culture in banking

At the bank, the incident response process was deeply pathological. A production incident would trigger a "war room" where the first 30 minutes went to assigning blame rather than restoring service. Engineers had learned to hide information, delay incident declarations, and write postmortem reports as exercises in self-protection.

The team replaced this with a structured, blameless incident response process modelled on Google's SRE practices. The key changes:

1. An Incident Commander role separated from the engineering teams involved, removing the conflict of interest in declaring and managing your own incidents.
2. A postmortem template that explicitly prohibited individual blame and required identification of systemic contributing factors.
3. Postmortem review sessions open to the entire engineering organisation, which normalised treating incidents as learning opportunities.
4. "Excellent Postmortem" awards that celebrated the most insightful analyses, creating positive incentives for candour.

Within 18 months, the mean time to declare an incident dropped by 40% and engineers were no longer afraid to raise the alarm. Mean time to recovery improved in parallel, because information flowed freely during incidents instead of being hoarded.

Psychological safety

Amy Edmondson, the Novartis Professor of Leadership and Management at Harvard Business School, defined psychological safety as "a shared belief held by members of a team that the team is safe for interpersonal risk-taking." In The Fearless Organization (2018), she drew on two decades of research to demonstrate that psychological safety is the foundation of high performing teams.

Her research also shows that psychological safety does not mean an absence of accountability. High-performing teams combine high psychological safety with high performance standards. High standards without safety produce anxiety. Without either, apathy. Safety without standards produces comfort, but not excellence.

Emerging empirical research connects psychological safety to sustained engineering performance. Sesari, Sarro, and Rastogi (2025) studied over 60,000 pull requests across multiple open-source repositories and found that contributors show greater likelihood of sustained participation, both short-term (1 year) and long-term (4-5 years), in repositories with higher psychological safety, as measured through merge decisions, comment patterns, and interaction quality. Their data-driven methodology for assessing psychological safety at scale provides a model for engineering organisations that want to move beyond survey-based measurement to continuous, objective assessment of team health.

The psychological safety and performance standards matrix

	Low Performance Standards	High Performance Standards
High Psychological Safety	Comfort Zone	Learning and High Performance Zone
Low Psychological Safety	Apathy Zone	Anxiety Zone

The goal is the top-right quadrant: teams that feel safe to take risks, ask questions, and admit mistakes, while being held to exacting standards of quality, reliability, and delivery.

Example: psychological safety in regulated environments

Building psychological safety in banking involves a paradox: you operate in one of the most heavily regulated environments on earth, and there are genuine consequences for compliance failures. The temptation is to create a culture of fear around compliance. But fear produces concealment, not compliance.

We separated two concerns: the system is accountable for compliance (automated controls, pipeline gates, audit trails), while people are accountable for learning and improvement. When an engineer bypassed a security control, the response was inquiry, not punishment. Why did they feel the need to bypass it? Was the control creating friction without adding value? Was there a gap in training? This approach consistently uncovered systemic issues that, once fixed, prevented entire categories of future violations.

Letting teams choose tools

Letting teams choose the tools that suit their work promotes autonomy and efficiency. The DORA research found that teams that can choose their own tools are more likely to be high performers. This does not mean anarchy. It means providing sensible defaults (golden paths) while allowing teams to deviate when they have a justified reason.

In banking, this is a delicate balance. Enterprise architecture teams often mandate tooling for legitimate governance and procurement reasons. The distinction that matters is between constraints that serve genuine risk management (approved container registries, mandated SAST tools) and constraints that exist purely out of organisational inertia (everyone must use the same IDE, all projects must use the same test framework).

Supporting that autonomy in practice takes several things. Teams must be able to evaluate and select tools against their specific requirements, within the bounds of security and compliance policy, and must hold the authority to make architectural and tooling decisions in their own domain while staying aligned on cross-cutting concerns. Experimentation needs formal support, such as time-boxed spikes and proof-of-concept work. At the bank, we created an "Innovation Time" allocation of two days per sprint for experimentation and learning. And golden paths must not become golden cages: well-supported default toolchains make the right thing easy while leaving the door open for teams that need to diverge.

Example: tool autonomy in practice

When we rolled out the DevSecOps pipeline platform, we offered a golden path CI/CD template that included compilation, testing, SAST, DAST, SCA, and deployment. Most teams adopted it gratefully; it saved them weeks of pipeline engineering. One team, though, was working on a high-frequency trading system and needed sub-second build times the standard template could not deliver. Rather than forcing them into a one-size-fits-all solution, we gave them the freedom to build a custom pipeline, with the constraint that it satisfy the same security and compliance gates. They delivered a pipeline 10x faster than the standard and eventually contributed optimisations back to the golden path that benefited everyone.

The same principle applies to choosing an AI coding agent. This site's own golden path is Claude Code (see AI-powered SDLC with Claude Code), chosen deliberately rather than by default, and documented as a recommendation, not a mandate. A team with a genuine reason to prefer a different agent should be free to make that case the same way the trading team made its case for a custom pipeline: show that the golden path's constraints (project memory, hooks-enforced quality gates, permission boundaries) are met some other way, not just that a different tool is available.

Measuring culture

Culture can feel intangible, but it can be measured. The most effective approaches include:

• Westrum survey instruments embedded in quarterly engineering health checks, measuring information flow, collaboration, and novelty acceptance.
• Incident metrics as cultural proxies: time to declare incidents, postmortem completion rates, and the ratio of systemic to individual findings in postmortem reports.
• eNPS (Employee Net Promoter Score) for engineering teams, tracked over time to detect trends.
• Voluntary attrition rates as a lagging indicator. By the time this metric moves, the cultural damage has already been done.

Benefits

When people are safe to experiment, they try more things, and some of those things pay off. Engineers stay at organisations where they feel respected, heard, and able to grow, so in a competitive talent market culture is a retention strategy. Generative cultures also respond faster to regulatory changes, market shifts, and technology disruptions, because information flows freely and novelty is implemented rather than crushed. And the DORA research demonstrates a statistically significant relationship between Westrum generative culture and software delivery performance metrics.

References

1. Westrum, R. (2004). "A Typology of Organisational Cultures." BMJ Quality & Safety, 13(suppl 2), ii22-ii27. The foundational paper establishing the pathological-bureaucratic-generative culture typology and its relationship to information flow and safety outcomes.

2. Edmondson, A.C. (2018). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley. Two decades of research on psychological safety, with practical frameworks for leaders seeking to build high performing teams.

3. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. Provides the empirical evidence linking Westrum generative culture to software delivery performance and organisational outcomes.

4. Edmondson, A.C. (1999). "Psychological Safety and Learning Behavior in Work Teams." Administrative Science Quarterly, 44(2), 350-383. The original academic paper establishing the construct of psychological safety and its relationship to team learning behaviour.

5. Dekker, S. (2014). The Field Guide to Understanding 'Human Error'. CRC Press. Essential reading on just culture, systems thinking in incident analysis, and why blame is both unjust and counterproductive.

6. Google re:Work. "Guide: Understand Team Effectiveness." Available at rework.withgoogle.com. Google's Project Aristotle research, which independently confirmed psychological safety as the most important factor in team effectiveness.

7. Sesari, E., Sarro, F., & Rastogi, A. (2025). "Safe to Stay: Psychological Safety Sustains Participation in Pull-based Open Source Projects." arXiv:2504.17510. https://arxiv.org/abs/2504.17510