Through my encounters with Engelbart’s work, the seeds were planted that grew into a lifelong career and passion for creating my interpretation of Dynamic Knowledge Repositories (DKR) to raise collective IQ, with surprising successes.
I have interpreted Engelbart’s “ABC” as follows:
The “A” level activity is carrying out the work. The workers add to the DKR by documenting what they are doing and how they are doing it.
The “B” level activity is improving the human and tool systems. In my case, creating models of the work flow and the production process.
The “C” level activity is improving the improvement process. It is the meta-level—improving the process for how the “B” level activities are carried out.
I helped a small manufacturing group demonstrate what I call, “Actionable Engelbart.” The CEO of a very people-oriented business wasn’t happy with one of the big-name content management systems. He wanted a more flexible and adaptable system for product design, manufacturing, sales and customer service.
I listened to the various teams describe how they wanted the computer system to be designed. Next, I built a tool so the team could build models of the systems they described; including the ordering process, customer profiles, manufacturing processes, shipping and pricing, and the layout of the factory floor. We also made models of the team workflows. I made sure that modifying the models or building new models was easy. The new models became part of the DKR, which drove the business and facilitated the raising of the collective capability.
If a worker added a new model or modified an old one, it resulted in higher productivity. Additionally, other team members could investigate all details of the new model, which leveraged not only the model, but the acquired knowledge about the model. This created an improved capability for the entire team.
This created a new paradigm. The employees could design and modify their own tools and processes to make them better. They were able to represent what a product should look like, changes in the factory floor, how a work order could be set up, etc. The employees felt empowered. They didn’t have to use a system designed by someone else – it was THEIR system.
Interestingly, more aspects of the computer system benefited from flexibility than we initially hypothesized. For example, the customer profile forms were modeled on a standard industry practice. It turned out the customer service representatives pushed for more flexibility in their systems. A wonderful woman named “Kim” said that each customer was an individual and she needed a variety of approaches on how to input and access each profile.
We asked her to design a model for the customer profile application. She knew just what to do. We removed the standard industry code and based customer service on Kim’s models. The entire company, and particularly the sales department, were able to increase their capability and sales. When we made certain procedures fixed, based on best practices in the industry, the employees began saying, “No, no! We want to be able to improve this.” The company augmented the best practices to create their own internal, flexible models for almost every aspect of the business.
The changes in the system evolved as a result of the changes in the way people worked. And their customer relations improved as the tools improved. For example, people answering the phones were the first point of contact with the customer. As they found new ways to improve their connections with customers, they made changes to their interactions, and that affected the whole system of the company.
Before we began writing code to implement a process, we asked, “Does this task or system benefit from flexibility in the design?” Some tasks and systems don’t need to be flexible. For example, their accounting system, which followed structured tax standards and guidelines, would not benefit from a flexible model. However, allowing workers in customer interaction, product design, production and delivery to create their own tools increased their capability. We allowed all employees to create and modify the models at every level. So the workers, who mostly engaged in “A” level activity—such as sales, product design, facilities maintenance, production, shipping, and pricing—were engaging in the “B” level activities as well. They were, in fact, improving their processes.
So, we were successful at creating a system for the “A” level activity, the programs the employees used everyday. Then we were able to get the “B” level working well, allowing employees to create and modify models to improve the current “A” processes. It was the third level of abstraction—creating a model of all the “B” levels, or, in other words, a “model of models”—that was tricky.
The manufacturing company achieved unexpected efficiencies and financial success. The business went from 31st to 3rd in sales within a couple of years; they had that much more capability with the same number of people. Their teams were generating a better customer experience than a company 10 times larger. It was not only because the workers were more efficient, but, more importantly, the employees became more capable. They supported each other as the tools supported them. They were supercharged. It was a beautiful thing to see —it changed my life and I vowed I would do whatever I could to help this happen on a larger scale.
By creating models of a team’s process, constraints and big obstacles become apparent and can be eliminated, empowering the group and the individuals to move forward. In order to improve, human processes and tools need to evolve to meet the goals of the organization. If either the tools or the processes are rigid, the collective cannot improve. If you identify the constraint and it cannot be fixed, then the collective is locked into the current level of capability. Of course, sometimes there are people who refuse to change and this can be obstructionist. The bigger problem, in my mind, is when a process or tool cannot change. Most tools do not adapt well to the collective.
Unfortunately, the collective is forced to adapt to the tools.
Later, I tested a similar “A,” “B,” and “C” process with a city bus maintenance and repair company. We augmented their systems. Once we created models of what they were doing, the constraints of the systems became apparent. They then created new models and figured out how to improve their own workflow. As a result of the process, they improved their capability so much that workers had free time at the end of the day. In order to avoid layoffs, they began a new service. They bought old scrap buses and refurbished them. So they expanded their business without adding additional personnel. The old buses are still on the road as “retro buses.”
Again, we were able to support a collective to be creators of their co-evolved human and tool systems. It has been so exciting to apply these ideas and see the results.
When employees have the capability to change their own processes and procedures and inter-link their own systems with tool systems to make them flexible and easy to manipulate, then the tools can adapt. With these improved tools people’s capabilities improve in each of “ABC” bootstrap levels.
When one or more people assemble into a group (Engelbart’s collective), there is a baseline capability of that group. The group becomes a unique entity with the capability to receive input, add value, and produce meaningful results. For example, this could be sales, production, or services. When you increase the capability of the group, it can receive more input, add more value and produce more meaningful results.
Today, leadership usually extends a group’s capability by recruiting more members. Engelbart had a different idea. The group’s capability can be improved by improving the improvement process. There are times when it is necessary to extend the capability of a group by bringing in additional members. However, there is an enormous amount of latent capability in any group that can be realized by following Engelbart’s ABCs.
I am now involved in a project to help build what Engelbart has asked for a “DKRs of DKRs,” helping individuals who have studied and applied the framework to share their insights with one another through co-evolution, improving organizations and tools. I am confident that we will see the realization of Engelbart’s dream of raising our collective intelligence so we can solve the urgent, complex global problems that threaten humanity.
__________________________________________________________
Darla is CIO of Hewett Research with a passion to build flexible, adaptable systems based on the collective intelligence of the people in the enterprise. These systems are self-generating/self-correcting and can instantly adapt to any change or innovation in the business or supply chain. She is also a core member of Program for the Future.
Engelbartbookdialogues's Blog 