Common wisdom among thought leaders discussing learning in organizations notes that most of the learning that occurs happens informally, or socially. A previous Skilful Minds post, Social Flow and the Paradox of Exception Handling in ACM , asserted:
people learning at work rely on social, or informal learning, around 80% of the time. Interestingly, I noted in a former post, Social Learning and Exception Handling, that John Hagel and John Seeley Brown contend that “as much as two-thirds of headcount time in major enterprise functions like marketing, manufacturing and supply chain management is spent on exception handling.” It is not coincidence that the two numbers are aligned.
The most basic point to remember is that exceptions to formal business processes require efforts to design a scalable learning architecture that supports content co-creation needed to adapt to emergent challenges and manage the flow of that adaptation through an enterprise’s ecosystem. Whether judging an adaptation successful requires it to result in new formal learning content, i.e. content co-creation, or a new business process, i.e. organizational innovation, or both, remains an open question.
Informal, social learning is key to exception handling since both make up most of what people do in organizing work in enterprises.
Of course, for every generalization there is usually an exception. My posts on business exceptions to this point largely focus on Barely Repeatable Processes (BRP) where informal and social learning assists employees solve issues raised by the need to improvise and handle exceptions to maintain a good customer experience, or solve issues experienced by other stakeholders such as business partners, suppliers, etc.
Recently, while reading General Electric’s A Connected World blog, one case described there led me to think about informal learning and collaboration with a different twist. It caused me to reconsider exceptions and look at the way attempts to make processes better by using working knowledge learned informally also produces exceptions in some organizational contexts.
Informal Learning, Collaboration, and Quality
In Quality vs Quantity: Why Faster Is Not Always Better Barry Lynch of GE explains a case in which GE’s Proficy Workflow solution prevented the use of informal work practices on the factory floor.
One company implemented the Workflow solution with two main goals: reduce the number of “off quality” batches per month and increase the speed of batch production. On one of my visits, the automation manager and I were talking about the system and how they had not had a single batch rejected due to production issues since it went live. Based on the costs of a lost batch, this was huge for them, but they had not seen the increased speed they were expecting in the primary batching area.
To investigate, we both went down to the line and met with one of the operators using the system. We asked her honest opinion of the system, and she was very complimentary on how it helped her manage daily tasks. Then we asked, “But why have you not been able to speed up the process?” Her response was straight to the point: “With this system in place no one takes the shortcuts we used to. The system makes sure we all make the same batches the same way consistently.”
So, we concluded that the quality issues seemed to be caused by people trying to speed up the process as opposed to following their own documented processes. They made a few more batches, but those gains were offset by expensive rejects that occurred.
In other words, the practical knowledge gained from informal learning on the factory floor allowed employees to take shortcuts to speed up batch production, even though the unintended result was to increase off-quality batches. A classic speed vs. quality tradeoff. It would, of course, be useful to know why operators in this situation felt the need to speed up production prior to the GE system implementation. A variety of scenarios could explain it.
An in-depth factory floor ethnographic investigation could have revealed the informal work practice before the sytem implementation, perhaps providing useful insight into ways to further optimize best practices. Yet, without further knowledge of the organizational context, an understanding of how employees on the factory floor developed such practical knowledge and why they chose to use it when they did is not provided by Lynch’s post.
My underlying point is simply that informal learning, depending on organizational context, has its own limitations that we all need to keep in mind as we think through the ways in which it adds value to business outcomes.