Swimming against the tide of your own skills: the importance of unlearning

Photo by 愚木混株 cdd20 on Unsplash

Which is harder, acquiring new beliefs or discarding old ones?

Last week, I wrote about how technologists can respond to the pressure - and the frequent interview question - to stay current, to keep their skills and knowledge fresh and up to date. Tim Pieters suggested that I consider the related topic: how we unlearn. That is, how we shed beliefs and practices which are no longer helpful.

I think that unlearning is harder than learning.

Both require humility, but learning requires an easier sort of humility: we need simply to admit that we are ignorant, and that we need to put in the effort to read, listen, watch and practice. Unlearning requires us to admit that we were wrong, that prior decisions and efforts were made on the basis of beliefs that we now consider to be mistaken.

Similarly, learning and unlearning both require that we change our habits, that we behave differently. But unlearning requires a more profound shift. Acquiring new habits is a matter of conscious practice: we choose to do something which we are not very good at over and over again until it becomes routine. In contrast, shedding old habits requires conscious vigilance: we must look out for the patterns of behaviour we want to change, catch them, and choose to do something different. This is especially hard when those patterns of behaviour are comfortable and natural, and when we are used to thinking of them as something we are good at.

Let me illustrate with an example.

I started my career in the era of Big Methods: structured approaches to designing and building systems, with a heavy emphasis on upfront activity. They seemed to be founded on the belief that, if you did enough thinking, planning and design at the beginning of a project, then build, deployment and testing would be easy. They attempted to create predictability and eliminate risk. These are rational things to want in a field notoriously full of failed projects, missed deadlines and blown budgets. The only problem was that these Big Methods rarely created accurate predictions or reduced risk. Nevertheless, I learnt the habit of trying to figure out as much as possible as early as possible.

The natural challenge to this habit, the trigger for unlearning, might naturally seem to be Agile. However, things started to unravel long before then: I was already hearing about concepts such as Rapid Application Development and other forms of iterative approach in the early 1990s. It seemed that there were other ways to address risk and uncertainty than attempting to plan them out of the project. Over time, and through many hard lessons, I came to learn that software development is inherently unpredictable. There are some things we can be relatively confident about - how much money we want to spend, what outcomes we want, and how long we are prepared to take - but there are other things that we only find out by doing them - exactly how hard this hard problem is, whether users actually want the product, and how well this team performs.

I cannot say that there was a single moment when I suddenly unlearnt my previous beliefs and habits (life would be a lot easier if our brains worked that way). Rather, I underwent a gradual shift and realisation over several years. If my experience is anything to go by, unlearning takes time - and the more deeply embedded the old learning, the more time it takes.

Even today, I have to admit that the instinct to make a Big Plan and a Big Design are still with me. I don’t know if this is a natural way for humans to approach the world, or whether it is a result of experiences in my early career. But I do know that I have to consciously unlearn this approach each time I start a major endeavour, and push myself to acknowledge the unplannable - and figure out how we can organise the work to maximise discovery.

And there’s a further twist which makes this process even more difficult. It would be neat and convenient to say that everything I learnt in the era of Big Methods was wrong, and everything that I learnt in the era of iteration and Agile was right. But it’s not that simple. There is a place for planning, and some of the techniques I learnt during that phase of my career remain relevant and useful. When building multi-year investment cases and benefits profiles, it’s not enough to say that we will figure out the numbers through discovery: we have to make a prediction with an appropriate level of confidence (although we must also build the off-ramps to deal with the times when our predictions are wrong).

This means that unlearning must be more than simply discarding an old approach in favour of a new approach: it must be a thoughtful examination of the beliefs, practices and skills which got us to where we are - and a questioning of when, how and whether they continue to be useful.

I have long believed that leaders and managers should be role models of learning. They should demonstrate the humility that they would like to see in their teams, by admitting when their skills need refreshing, and by visibly taking the time to learn. This reflection on unlearning (thanks Tim!) has reminded me that leaders and managers should be role models of the other sort of humility as well: the humility that leads them to review their mental toolkit, and admit that not everything within it works as well as it should.