(Originally published on Kinder Wiser collaborative blog)
I’m an IT guy. I’ve been working for 25 years in this business doing just about any job you can think of. I’ve been working in different industries, different countries, using different types of technologies, from IBM Mainframe technology built in the 60s to 00’s avant-garde mobile start-ups.
My strategy to survive in this fast-pace changing business has been to think in patterns. This comes from IT industry standards called Design Patterns. The baseline is : for every problem that will slow you down you while designing a software solution, someone has already bumped into it and standardized a generic design solution.
This is both a bless and a curse and here’s why …This is a bless because it has saved me time, it has allowed me to easily navigate the IT world and be somehow successful. The curse is that it has deeply shaped the way I think : rather than really trying to understand the problem, I’ve just tried to recognize known situations to apply prepackaged patterns : talk about preconception and jumping to solutions ! What’s more, this thinking results in over-engineering (a disease of Java programming language and more generally enterprise software) and a tendency to tackle world complexity with abstract, generic and complicated solutions while forcing patterns where they may not have necessarily applied.
This is just a continuity of the way I’ve been educated : building stocks of knowledge (accumulating patterns as “how to” or anti-patterns as “how-not-to”), thinking the more stocks I have, the more weapons I will have to shoot problems and discordant voices down. The issue here is that you don’t eradicate problems this way, just their symptoms : the difference between fast thinking and deep thinking. Not to mention that in the process you don’t really show much respect to people.
For the last couple of years it has just occurred to me that lean thinking is different. It aims at really showing respect to people while trying to understand the problem (and being kind to it), then making hypothesis, testing them and learning while measuring the difference between the expected result of hypothesis and the real world. Learning while doing and fully, deeply understanding what hinders our thinking process while surfacing our preconceptions. As Joshua Foer puts it, this helps in trying not to stay too long on the OK plateau and the comfort zone to get back to the cognitive stage.
Design Patterns are stocks of knowledge and, as such, static entities, which make every problem looking like the proverbial nail. Learning is a dynamic discovery process. Accumulating stocks of knowledge is not learning : this is what Lean has helped me to clearly see.
You may want to have a look at John Seely Brown’s perspective on learning, because it aligns with the title and last paragraph of your blogpost:
And also this article:
Hi Luc ! Many thanks for the comment and the links that I will check them out. Funnily enough, I have The Power of Pull co-written by John Hagel and John Seely Brown on my reading list for January. Have a great year 2014.