I come from an education background. I've been a part-time music teacher for almost 30 years and both of my parents started their careers in teaching. I know a few things about how to teach and what effective learning looks like and I've had to adapt my style and delivery to meet my students where they are (rather than where I wish them to be). My youngest students, fairly immature in their familiarity with instruments, music and musicianship, need fun activities, lots of coaching and smaller goals. More advanced students who have been learning the instrument for a while benefit from new challenges, technical guidance and tools to help them direct their own learning.
So what's the difference between learning at school and learning on the job? And is organisational learning even a thing? Here's what I observe:
First of all, let's talk about learning.
Learning isn't simply about reading a book and recalling facts. Just in the same way teaching isn't about standing there and reciting facts while expecting students to unquestioningly accept them. There is a pedagogy involved in any learning system and organisations are no exception. Wikipedia defines pedagogy as:
...the theory and practice of learning, and how this process influences, and is influenced by, the social, political, and psychological development of learners
That last part is important. In any learning system, there are social, psychological and political (i.e. behavioural) influences acting on the individuals within it. Those forces act on teams (and individuals) in a range of different ways:
How individuals and teams think
How those teams relate to each other and the world outside the immediate team
The language, symbols, and texts individuals conform to when writing or recording information
Self-management
Participation and contribution
These matter because they express behaviours besides merely acquiring knowledge. Participants of learning organisations need opportunities to develop their capabilities as users of knowledge and apply those competencies in diverse contexts. The difference between organisational learning and documentation goes beyond what the individual has discovered and commits in writing; it's about how a team responds to that information and how their behaviours and shared mental model of the system is shaped by new information. Looking at how a team responds to new situations, events or stress, and how that team infers based on what it's observing and sensing is how you can gauge how well the team has learned.
Learning in organisations
What happens to pedagogy outside of the academic environment? Does it suddenly cease to apply? Most organisations (I'm speaking about technology / software businesses here, but presumably this applies more widely) expect their engineers to write documentation. Leaving code comments, descriptive pull requests and wiki resources should be considered a core competency of even the most junior team member. But writing something is not in itself learning. Neither is simply reading something. Organisations seem to follow a belief that if it's written down then it's learned, but as any teacher will tell you, learning is a social process: it happens through social interaction. How people respond to an idea individually influences those around them.
Dr. Cat Hicks and John Allspaw are two particularly potent minds on the topic of organisational learning and system resilience. Cat Hicks has published a report that revealed a tension between what an organisation said it valued and what individual contributors actually understood: "the work that code writers needed to do to understand code often did not feel like what was rewarded in the evaluation of their work". In her research, Dr. Hicks recommends:
Involve people in defining how their “success” is measured.
Encourage more developmental feedback, separate from performance evaluation.
Give technical teams more time for collaboration and documentation, and make documentation “count.”
Identify opportunities for celebrating and sharing collaborative support and examples of active problem-solving.
Make the costs of learning debt visible.
John Allspaw is a resilience evangelist who has established a credentialed career discussing resilience engineering and incident management. Specifically, when looking at incidents and their post-event reviews, John consistently describes the behaviours that teams need to take together in order to reveal insights, surprises and a more cohesive shared understanding of systems:
Update your mental models together (post-incident reviews, agile retros, team meetings)
Externalise your mental models (write things down, cross-reference information, bring information closer to the surface)
Inquiry as the basis for learning together (asking beyond "why did X happen" and moving to "what surprised us? Who knew something no-one else knew? What could we see but not find in written material?")
Practice what you learn together
Both Allspaw and Hicks advocate beyond simply writing things down. For teams and, by extension, organisations to be truly effective, how that written information is socialised, explained, queried and refined is as important - if not more so - than actually writing it down in the first place. Knowledge can be written, but simply having a written artefact is not evidence of team learning. The social, psychological and political environment in which individuals are operating (i.e. the team "culture") determines the effectiveness of learning.
During incidents, a team is required to infer, act on instinct, query and explore based on the mental model held by its members. Hopefully there's good documentation that helps guide the team towards the right course of action, but coordination, adaptation, cognitive processing... these are all learning behaviours based on available information and experience.
Documentation is a pull system in the sense that the individual writing it can notify people that an artefact has been created, but it's up to the rest of the team to take the time to read and digest that artefact. As Cat Hicks' research shows, team members will prioritise the thing they're incentivised to prioritise. That might be writing code, product meetings, security and incident management, or design research sessions. Product teams are always busy, stretched for time and under pressure. It's incredibly easy (and common) to focus on trying to ship the next thing and dedicating all available energy and time in service of what's right in front of you, but therein lies the problem: teams that fail to build in slack time for sharing stories, discovering surprising nuggets and generally working together to collaborate a shared understanding of a system are inevitably going to be more reactive, less-equipped to respond to emergencies and less resilient to change.
Organisational vs individual learning
When I had a robust debate with my colleague at work about learning we were struggling to bring each other to our respective points of view. Her argument was (and I'm being incredibly reductive here for brevity's sake): "learning is fundamentally grounded in the artefacts an individual has access to". In essence, there is no true "organisational" learning; it's all just individuals who learn a thing and then bring that to their team. My argument on the other hand was that there is a difference between individual learning and organisational learning.
Individual learning does indeed rely on a person building knowledge based on their own experiences, mental models and access to resources (e.g. documentation, books, videos / screencasts, conferences / events, and so on). Organisational learning on the other hand is the team's, department's or organisation's response to new information being brought in. It's the cultural ability to problem-solve, reflect, empathise and adapt, and that is fundamentally predicated on a team's psychological safety, trust, empathy and ability to experiment and fail safely.
A learning culture within an organisation means:
people feel they can speak up about issues, problems and mistakes
mistakes aren't viewed as a reflection on the individual, but as a source for learning by the team
people can talk about differences of opinion and disagree
people are open to new ways of doing things and new ideas are valued
Agile and learning
The Agile Manifesto has twelve principles for an effective agile process. Notice that it doesn't talk about scrum, kanban or devops. The manifesto asserts that agile methodologies are about people over process; working systems over documentation. The twelfth principle talks about how a team should reflect back on what it has delivered:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
In other words, the team should seek to continuously improve by inspecting its behaviours and learning through adaptation and experimentation. Individuals can (and definitely should) contribute written or recorded information in response to a change in the system (e.g. new feature added, existing one changed, incident occurred in an areas of the product), but the organisation's culture in how it encourages, supports and measures how that individual knowledge is socialised around the team - or wider practice - is where the actual collective organisational learning occurs.
Further reading:
John Allspaw - Dark Debt: https://medium.com/@allspaw/dark-debt-a508adb848dc
Organisational Learning: https://www.valamis.com/hub/organizational-learning
Dr. Cat Hicks - Asking For Help in Learning: https://www.drcathicks.com/post/when-we-ask-for-help-in-learning