Building a Learning Culture in Nine Steps

This post is excerpted from the DevOps Enterprise Forum paper “How to Thrive (or Fail) in Building a Learning Culture: A Leader’s Guide.”

Leaders in today’s age of digital and AI are challenged by accelerating disruption to their existing customers, markets, and technology. To survive and thrive, leaders must foster a learning culture by finding ways to leverage and integrate knowledge, experience, and creativity across their workforce, supply chain, and the broader ecosystem.

Creating a learning culture is hard. We cringe when we hear horror stories, and we celebrate success stories. There is much to learn from both! This paper assembles patterns of behavior often found in learning organizations. For each pattern, we identify a key principle, illustrate it with stories of it being transgressed and stories of it being adhered to, and give specific actions you can apply tomorrow. Each learning pattern is independent from other patterns, allowing leaders to understand and apply them separately or in small groups depending on their needs:

• Pattern 1: Learning Moments
• Pattern 2: The Power of Experimentation
• Pattern 3: Provide Time and Space for Learning
• Pattern 4: OKRs for Learning
• Pattern 5: Leaders Who Model Vulnerability Encourage Learning
• Pattern 6: Ship the MVP, not the Prototype
• Pattern 7: Embrace the Inspector
• Pattern 8: If it Hurts, Do it More!
• Pattern 9: Give Intent

An implicit belief underpins each of these patterns: learning involves detecting and correcting error, as said by Chris Argyris and Donald Schon in Organizational Learning. When we talk about learning, we mean learning from our actions and our experiences, not simply something that takes place in a classroom. There is a lot of value in learning theory. However, the available learning day-to-day in our organizations—the learning that is available to everybody—is an endless source of improvement. Leaders of learning organizations want everyone to learn, all the time.

Pattern 1: Learning Moments

Leaders who are insatiable learners create the environment for a learning culture to thrive in their organization. This fuels the enterprise’s ability to dynamically transform—to anticipate and explore opportunities that create competitive advantage.

One leader who models this behavior is Garry Ridge, CEO and Chairman of the Board for WD-40. Garry introduced the concept of a learning moment as a “positive or negative outcome of any situation that needs to be openly and freely shared to benefit all.” The learning moment is an opportunity to grow from the experience of your colleagues. Learning moments sound like: “Wow, I just had a learning moment! Here’s what it was and what I learned from it.”

Research by Dr. Ron Westrum observed that bureaucratic cultures expect mistakes to result in punitive actions, typically a series of administrative procedures, mounds of documentation, and corrective actions captured in personnel files. The bureaucratic focus is on enforcing justice. Worse, for those unfortunate enough to work in what Dr. Westrum describes as a pathological organization, mistakes frequently result in blame, scapegoating, and punishment.

Conversely, Garry Ridge’s approach to learning moments is consistent with what Westrum describes as a generative culture. Mistakes are expected, especially when focusing on innovation and reasonable risk-taking. The response to mistakes is to extract value from the experience. Those learnings are openly shared so that everyone benefits from the insights provided. Such a response to mistakes requires and promotes psychological safety and a growth mindset in the corporate culture.

(Read the full paper for example stories and actions to take.)

Pattern 2: The Power of Experimentation

The traditional way of managing work and people makes strong assumptions about the available knowledge at the start of development. Most new initiatives have user, market, technical, and other uncertainties and assumptions: Will the solution meet users’ needs?

Will it have the intended business impact? Will the new technologies work and integrate as expected? Despite these questions, traditional projects begin by creating detailed specifications for an unvalidated solution and a fixed schedule to build it. Even worse, when teams begin execution, the expectation becomes conformance to the fixed requirements and schedule and not learning more about the users, markets, technology, and other assumptions.

Leaders must stop valuing conformance to cost and schedule and start communicating the value in quickly learning about unknowns and assumptions. Instead of requesting project status on dashboards, ask teams about their unknowns and what small experiments they perform to understand better, characterize, and address them. And ask how new knowledge is informing the solution and what impacts it may have on the business direction.

(Read the full paper for example stories and actions to take.)

Pattern 3: Provide Time and Space for Learning

Leaders encourage organizational learning by providing both time and space for all employees to grow and learn from each other. They provide time by ensuring hours away from routine, product-based work for experimentation that may improve the current solution offerings, create potential new offerings, or improve the way offerings are built and delivered. To provide time, leaders prioritize exploration and research work (for example, spikes) in the backlogs. They also support learning events outside normal product development, such as hackathons, which encourage cross-organizational learning.

Leaders also provide the space that enables learning. The space required for learning has many dimensions and includes:

• Physical space: Groups need sufficient physical space to collaborate on their work activities, whether in the office or at home. Space, seating, and tables designed for collaboration are easily reconfigured based on need.
• Technology: Dry erase boards, screens, connectivity, physical equipment (particularly in hardware-reliant systems), virtual telepresence—it also should be easily reconfigurable.
• Comfort: The innovation space must be inviting. The furniture and floor plan are comfortable and encourage collaboration. The space is free from disruption and acoustics/noise and has appropriate furniture, floor plan, and lighting.

(Read the full paper for example stories and actions to take.)

Pattern 4: OKRs for Learning

Andy Grove, former CEO and Chairman of the Board of Intel, introduced his version of Management By Objectives to the world in his 1983 classic High Output Management. John Doerr of Kleiner Perkins learned this approach of objects and key results (OKRs) during his time at Intel and introduced it to the young management team at Google. From Google, OKRs made their way into the larger software zeitgeist following the viral success of a video on OKRs from Google Ventures. OKRs offer the promise of great execution, given the success of the flagship companies. Often lost in this promise of execution is the role of learning. As Andy Grove puts it, judgment is “developed through experience and learning from the many errors one has made in one’s career.”

(Read the full paper for example stories and actions to take.)

Pattern 5: Leaders Who Model Vulnerability Encourage Learning

Learning requires vulnerability and humility. A perfect person does not need to improve. The first step in change is admitting you have a problem. Every management level must role model vulnerability and humility to encourage others to do the same.

In large organizations, people are often idolized because of their position, and maintaining that perception becomes a priority for the individual. Changing that behavior is difficult.

(Read the full paper for example stories and actions to take.)

Pattern 6: Ship the MVP, Not the Prototype

Early prototypes, proofs of concepts, and mock-ups create learning opportunities early in the product development life cycle. They enable fast feedback that reduces rework and produces higher-quality products. Opportunities for organizational learning are reduced when engineers are discouraged from making prototypes.

Understanding the difference between a prototype and a minimum viable product (MVP) is important. A prototype is a mock-up of how something could work. A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers, who can then provide feedback for future product development.

Great prototypes can establish stakeholder buy-in, secure resources, and build excitement about a new feature, product, or initiative. Sadly this excitement can close our eyes to the fact that a prototype needs considerable work before it is ready to ship as a product. As a result, it is tempting to “ship the prototype” and deliver a product full of technical debt and partially working features. This can lead to a product that looks rushed or requires extensive manual upkeep and therefore has high operational costs.

For several reasons, prototypes may be intentionally incomplete, including:

• Animations may be used instead of actual features. Since “seeing is believing,” the human mind is apt to assume that if they see it, it exists.
• The demonstration “script” intentionally avoids incomplete or missing features, giving the unintentional impression that the product is more ready than it actually is.
• The architecture “under the hood” may be more like scaffolding than a real foundation. It may be wasteful to design the architecture too early; thus, prototypes have little infrastructure to support them. This may include disaster recovery, operational procedures, monitoring, SLO, and so on.
• Important decisions around scale, service delivery, and user training are yet to be decided.

(Read the full paper for example stories and actions to take.)

Pattern 7: Embrace the Inspector

David Marquet, retired Navy submarine captain and author of the book Turn the Ship Around, describes a cultural shift he instituted among his crew that he calls “embrace the inspector.” Outside teams frequently inspect military units to ensure mission readiness, safety, and adherence to established standards. Corporations have equivalent patterns in the form of auditors, external regulators, independent verification and validation (IV&V) teams, governance boards, and more.

In both military and commercial contexts, there is a well-known pattern of “gaming the system” by hiding important information from the “inspectors” to avoid a bad report and the inevitable scrutiny that would result. Critiques are often met with a defensive response. These patterns lead to an adversarial relationship between the inspectors and the inspected.

Captain Marquet took a very different approach with his crew. Inspectors were enthusiastically welcomed aboard the ship and immediately provided all the information and documentation needed to perform their work. Known problems were not hidden but were discussed openly to learn from the inspectors how other ships had solved similar issues. Making problems visible in official reports also surfaced systemic challenges that needed higher-level focus and resources to resolve.

The shift of viewing inspectors as a source of learning to improve performance played a key role in transforming Captain Marquet’s ship from the worst in the fleet to a consistent streak of superior inspection ratings. Captain David Marquet stated that embracing the inspector “turned out to be an incredibly powerful vehicle for learning….Over time our sailors learned a lot and became incredibly good at their jobs; they also continued to evince a hunger for learning.”

A similar theme is described in the book Investments Unlimited: A Novel About DevOps, Audit, Compliance, Security, and Thriving in the Digital Age. Drawn from the authors’ real-life experiences, the book highlights the value of promoting a transparent and cooperative “we’re all in this together” culture among technology, audit, security, and compliance functions within an organization. Such a culture drives relentless improvement and advanced practices, such as automating audit controls in the DevOps pipeline.

(Read the full paper for example stories and actions to take.)

Pattern 8: If It Hurts, Do It More!

A learning culture learns through rapid iteration. It is important to create opportunities for this learning to happen. The more frequently something must be done, the more incentive there is to optimize the process. When something happens infrequently, it is easier to rationalize delaying improvements and muddling through broken or non-optimal processes.

The decision of how frequently to do a process should be based on its business value, not on the current state of the process, which may be in disarray. Or, as your parents probably told you, practice makes perfect. When we avoid a painful process, we miss an opportunity to improve it through repetition.

Typically processes do not induce physical pain. However, certain tasks are resisted due to an emotional reaction against processes that are painful to execute. The task may be brittle and prone to failure. It may require hours of babysitting and ad hoc adjustments along the way. None of those are attributes of a smoothly running, pain-free process.

It is easy to rationalize delaying an improvement when the next time the process will be executed is months or quarters away. Typical rationalizations include:

• This process happens so infrequently; surely we can survive a little pain once a year/month.
• We have plenty of time to fix it; why fix it now when other, more urgent fires are burning?
• Maybe someone else will be assigned the task next time; fixing it now won’t help me. Maybe they’ll be more inclined to fix the problems.

On an emotional level, avoiding painful and risky processes is natural. We all learned to avoid touching a hot stove at an early age! However, business decisions should be made based on potential value.

If improving a process has the potential to deliver more value, doing it more frequently has the potential to deliver multiplicative value. The increased frequency creates pressure to optimize the process.

(Read the full paper for example stories and actions to take.)

Pattern 9: Give Intent

Like the pattern of “embrace the inspector,” this insight into leaders creating a learning culture comes from Capt. David Marquet and his book Turn the Ship Around. Faced with the unexpected task of commanding a class of submarine he was unfamiliar with, Marquet quickly discovered that he could not use the command and control task assignment style that was traditionally taught in the Navy. His solution was to elevate his orders to a higher level of direction, which he described as giving “intent” instead of giving detailed technical commands. It was then the responsibility of the members of the crew to receive the captain’s intent and translate it into the specific technical actions that would be required of their station to execute that intent.

Further, Marquet also trained the crew to communicate their intent to him, creating a closed-loop communication system. He gave his intent to the crew, and they gave their intent for how they would carry out his guidance back to him. As long as the crew’s intent conveyed they understood his direction and were on a path to success, Marquet would respond to their intent by affirming, “Go do that.” If there was a misunderstanding, this feedback loop would allow the captain to clarify his intent before the instructions were acted upon.

This process of giving and receiving intent aligns with the principles of decentralized decision-making. It encourages a learning environment since workers can no longer mindlessly follow whatever instructions they are given. That legacy leadership pattern that has existed throughout human history, further codified in Frederick Taylor’s scientific management approach, requires little to no learning by anyone other than the leader. In contrast, decentralized decision-making requires workers to translate a broad set of guidelines and guardrails into specific tasks that will achieve the desired outcomes. Since that translation won’t always be entirely correct the first time, the closed-loop communication process of giving and receiving intent (feedback) requires perpetual learning by both leaders and followers.

Finally, Capt. Marquet clarified that decentralized decision-making requires workers to have the technical competence and organizational clarity needed to make the right decisions. Technical competence means they must have the knowledge, skills, and experience needed in their assigned domain. Organizational clarity means they also understand the larger context (mission, vision, values, strategy, guardrails, policies, and so on) within which their decisions must be made.

(Read the full paper for example stories and actions to take.)

Conclusion

A learning culture is fundamental to any organization’s sustainability in today’s dynamic digital landscape. Learning faster than the competition is not only a key differentiator but the mainstay of enduring organizational success. The nine patterns explored in this paper, from Learning Moments to Giving Intent, provide a robust guide to fostering such a culture. These patterns are anchored on the premise that learning is an ongoing process of detecting and rectifying errors, moving beyond the confines of traditional classroom instruction to capitalize on the wealth of knowledge, experience, and creativity that exists within every stratum of the organization.

However, introducing a learning culture is not a one-off event. Leaders need to champion these patterns while maintaining an environment that promotes learning and growth at every level. A learning culture builds a resilient organization that can weather change and disruption. This journey may be challenging but ultimately leads to lasting growth and evolution.

Read the full paper with case studies and actions to take in the Fall 2023 DevOps Enterprise Journal.

- About The Authors

Jeffrey Shupack

Digital Transformation | SAFe Fellow & SPCT

Follow Jeffrey on Social Media

• 
• 

Harry Koehnemann

SAFe Fellow and Principle Contributor Scaled Agile Inc.

Follow Harry on Social Media

• 

Jeffrey Fredrick

Coauthor of Agile Conversations

Follow Jeffrey on Social Media

• 
• 

Steve Mayner

SAFe Fellow and Principal Consultant at Scaled Agile, Inc.

Follow Steve on Social Media

• 
• 

Thomas Limoncelli

ManagerManager Stack Overflow, Inc

Follow Thomas on Social Media

• 
•