Learning, bodies of knowledge, and half-lives

half life curveWe think of learning relative to a body of knowledge; we talk about learning a foreign language, data science, corporate finance, or carpentry. Academic degrees are built around demonstrating mastery of a body of knowledge.Professions are defined and certified in terms of mastering a specified body of knowledge.

I have two problems with this thinking from the perspective of learning. Who specifies what constitutes the relevant body of knowledge? And, how do you handle the problem of updating the body of knowledge? The way we conventionally think about those two questions seriously interferes with our ability to learn in the environment we face.

What is it about the environment that triggers my worries? The pace of change. We’re familiar with Moore’s Law, for example. There is the exponential growth in multiple measures of data and information. There is the exponential growth in scientific publications.

The simplest organizing idea here is the notion of the half-life of knowledge. We know that this half-life is shrinking in all sorts of fields.

What happens when that half-life is shorter than the time it takes to update a relevant body of knowledge and fold the new knowledge into certification processes and school curricula? Professional associations worry about this. Schools doing curriculum design worry as well. Organizations that find schools and professional associations moving too slowly worry and respond by creating corporate universities.

What does it all mean from the perspective of an individual trying to cope? What do you do if you understand that you can’t simply turn the problem over to the experts?

The standard responses of going back to school or trusting in the continuing education requirements of your chosen field are insufficient. All of those responses are rooted in the assumption that learning is simply about mastering a body of knowledge.

One of Alvin Toffler’s oft-quoted observations is that “the illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn.” He had a handle on this problem. We need to master another layer of skills, to see the body of knowledge as something dynamic and evolving.

From that vantage point we take on responsibility for actively updating and maintaining the bodies of knowledge that concern us. Whatever our central interests, we have to also acquire basic competence in how learning works and in how knowledge is created. We need to become our own curriculum designers and our own research directors.

Temporary technology limits shouldn’t become design patterns

Things are the way they are because they got that way

– Ken Boulding

This is a quote attributed to Boulding by Jerry Weinberg in his excellent Secrets of Consulting. My students will tell you that I am fond of bringing it into many a class discussion. It’s somehow more useful to me than trotting out Santayana’s observation about learning history.

We’re all hot for the new, new thing and innovation is always better when it’s disruptive. For all that, when thinking about new technology we would do well to spend time and thought understanding how we got to the current situation. Predicaments today grew out of decisions yesterday that made sense when they were made. If we want to leave fewer predicaments for our successors, we need to understand how those earlier logic trains derailed.

For example, consider the Y2K issue of the late 1990s; the transition from 1999 to 2000 raised the threat that computer programs might fail because of the common practice of storing only the last two digits of the year in computer files and databases. That common practice grew out of technology limits with storage and data access. There was also an unexamined assumption about the likely longevity of the systems being built in the 1960s, 70s, and 80s. Why worry about a problem that was decades in the future; surely the programs would be replaced long before then.

There seems to be a deeper issue at work that is troubling me. Design is always driven by constraints and requirements; what limits exist on what you hope to do. We fail to appreciate how technology constraints evolve very differently from other constraints. We treat certain limits on our designs as if they were integral to solving the problem at hand when they are actually temporary speed bumps in the technology. We solve the immediate problem—the dates in our files fit the space available—at the expense of creating a bigger problem later.

We talk of “technical debt” but I don’t think the notion works with less technical decision makers. Debt suggests you trade future interest payments for a solution now. What we do instead is lock the organization’s future within boundaries that disappear and make us look stupid to those who designed smarter.

Organizational decision making is often hampered by shortchanging the future. We don’t seem to have good methods for avoiding these mistakes in technology. Temporary technology limits become design constraints which become design assumptions that get baked into design patterns and then outlive their usefulness.

Project management, rocket science, and donuts

time to make the donutsDunkin Donuts ran a legendary ad campaign in the 1980s—“Time to Make the Donuts.” You can still find the ads online. They celebrated commitment to doing the work. What they ignored was the need to manage the work. In fact, they reinforced the idea that work and management were two distinct things.

For making donuts or widgets or Toyotas this is possibly a useful distinction. For the work that most of us do today, it does more harm than good. In the donut world work is about following recipes and management is making sure that workers follow the recipes. There’s a lot that can go into following and managing recipes; how accurately do workers follow the recipes, how fast, how many per shift.

But where do the recipes come from?

If you’d prefer to remain in a worker/manager universe, they arrive by innovation magic. Some mysterious, creative process serves up new recipes and processes to be plugged into the existing system. Perhaps there will be some change management pain and disruption to be absorbed. Perhaps you will turn to some specialist or consultant to carry out this odd work. Then, everyone can get back to work.

I think this explains something I always struggled to understand when pitching consulting projects or proposing change efforts within organizations. Decision makers always seemed to object to the project management line item and tasks in proposals and plans. For that matter, project team members weren’t keen on the process of managing the work; they wanted to focus on what they saw as the fun part of the work.

It all makes sense if doing and managing are two separate activities. But you can’t do that when they are intertwined. When the doing shapes what needs to be managed and the managing calls for picking your way through the doing then you are much more tightly coupled than the mythology of workers marching forward as managers point to the goal in the distance.

I’ve been fascinated by NASA’s recent flyby of Ultima Thule by the New Horizons Mission. If you’re interested, I’d recommend a recent Nova broadcast, Pluto and Beyond. One thing that struck me was that project management isn’t rocket science but successful rocket science certainly depends on effective project management.

This all matters because the work we are all doing these days is a lot closer to rocket science than it is to making donuts. We’d better start acting as if we believed that.