Unarticulated needs: context

December 16, 2016

I promised yesterday that I would pick up the question of unarticulated needs, so that is the subject to today’s post. I’m using a metaphor of rock formations for this, per the image. You might be able to deduce what lies beneath from surface features but its hard, especially if there are multiple interacting aspects of the wider ecosystem. Now I have been fascinating with this subject for years and I first articulated it oh so many years ago when I was designing and build decision support systems. I was generally working at or close to board level. Often they were articulating company structures, in particular ownership, for the first time to someone outside of the inner circle. We were not just coding for transactional data, but we were creating new capability that would have been unimaginable only a few years earlier when spreadsheets were considered novel. So I would sit down with someone and extract a set of requirements. I’d then implement it and proudly show them the results. The initial reaction was excitement, followed by serious engagement with the system. Then they would start to realise what they should/could have asked for and the requirement would change, often radically. This was not a result of failure on either side, but simply the fact that you can only articulate things in context and they didn’t have sufficient knowledge of the capability of technology to imagine, let alone articulate what was possible.

I realised then that I had some advantage. I had been in a development accountant role for the best part of three years and was largely self-taught on computers and programming languages. I’d moved out of a line accounting role into a software house to expand on that. Little did I know that they had been looking for someone with my skills for over a year – back then few people had both application and computing skills. If I had know I could have negotiated a better package! Either way I got thrown into an intensive two weeks of training in the software and discovered I had been sold as an expert a month before I joined. As I indicated above I started carefully, but in increasing despair (everything I delivered had to be changed per the above) I adopted a different strategy. I stoped talking about what they wanted, or interviewing them. Instead I sat by their side or walked around with them. Over coffee or lunch I’d prompt them to talk about what they were trying to achieve, what obstacles were in the way. I watched and talked with their staff, I looked at unfavourable audit reports, I phoned or visited subsidiary companies. While I was doing all of that I bought myself time by throwing difficult questions at my client that gave them days or weeks of work to answer.

Then I sat down one Friday afternoon and with minimal sleep coded up a largely functional system with holes in it based on what I thought they might useful, rather than what they had said they wanted. On the Monday, disheveled, hyped on coffee and desperate for sleep I presented a walk through to the Financial Director and his key reports, much to the bemusement of my commissioning client in corporate IT. I say bemusement, a better way of describing it might be panic. I could see him working out how to say he had fired me and the company I worked for to protect his own career. But luckily I’d called it right. The next two hours composed of excited conversation about how the next month end consolidation would be run with requests for minor enhancements and changes. In effect, the fact I lived in both communities had given me (to use more modern language) a non-linear approach to understanding and delivery. I had built a system which did things they didn’t know they needed. From that a small contract became a highly profitable service relationship, I got promoted and eventually was GM of the business involved. There were a few other serious risks along the way, including walking out on a management meeting that had been organised in a pub one lunch time. I’d sat down expecting a business discussion in what was a fairly insalubrious area of south London and discovered that my boss had decided he whole (male) management team would really like to spend the time in a strip joint. I was so indigent that I lacked discretion on my return to the office which made the relationship sticky thereafter. And yes, there are more stories like that.

Tomorrow I will pick this up and talk more about the importance and start to outline some more structured, and less risky approaches to the subject.

Recent Posts

About the Cynefin Company

The Cynefin Company (formerly known as Cognitive Edge) was founded in 2005 by Dave Snowden. We believe in praxis and focus on building methods, tools and capability that apply the wisdom from Complex Adaptive Systems theory and other scientific disciplines in social systems. We are the world leader in developing management approaches (in society, government and industry) that empower organisations to absorb uncertainty, detect weak signals to enable sense-making in complex systems, act on the rich data, create resilience and, ultimately, thrive in a complex world.
ABOUT USSUBSCRIBE TO NEWSLETTER

Cognitive Edge Ltd. & Cognitive Edge Pte. trading as The Cynefin Company and The Cynefin Centre.

© COPYRIGHT 2024

< Prev

Social innovation labs, initial thoughts

For one reason or another I’ve ended up talking about various social innovation labs in ...

More posts

Next >

Unarticulated needs: deep issues

My post of yesterday made the point that it is difficult to get anyone to ...

More posts

linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram