Embracing Complexity in Your Job

But even if I were to ask the internal and external ‘customers’ of my client what their information and networking and related technology needs were, they wouldn’t know. It’s the nature of complex environments that understanding of the ‘problem’ and potential solutions co-emerge from the exploration, discovery and learning process.

Most of my writings on complexity to date have been about big-issue, save-the-world problems and the use of Open Space and other collaborative processes to invite and bring together the right people to address them collectively. But what happens if it’s your individual job to deal with a complex situation, and you don’t have the resources to convene large groups of people passionate about understanding the issues and surfacing ways of coping with them? Is there a scaled-down methodology that can be applied in such situations?

I think there is. Here’s the methodology I’m trying out on the new project:

1. Identify the Customer: Determine who the internal and external ‘customers’ are — how they can reasonably be segmented. There are usually multiple customer groups, often with conflicting interests. Don’t expect the interests or needs of management and of front-line staff to be congruent. Expect that this will create problems of irreconcilable needs, expectations and priorities for you.
2. Research & Observe: Study the status quo to understand what is really happening, what the real processes and workarounds are, not the idealized conception described in the procedure manuals or suggested by the corporate website. Don’t judge them — understand them. In the above diagram, this is called sensing and suspending.
3. Converse: Have lots of iterative discussions with different customer segments to clarify your understanding of what is happening and why. Question and challenge suppositions and implausible explanations. Between steps 2 & 3, an understanding of unmet needs and ‘problems’ (things that one or more customer segments are having difficulty with or are worried about) will start to emerge.
4. Define and Articulate the Needs & ‘Problems’: Some of the emergent needs and problems will be personal, and you may be able to solve many of these just by observing, conversing, and providing the individual with your ideas and the benefit of your experience. Other needs and problems will be shared and require (and justify) a more substantial ‘solution’ process, and these can be ranked by the customers’ assessment of their severity and urgency. Feed these back to the customers to make sure you understood. Steps 3 and 4 are pattern-recognition and inferential activities, synthesis rather than analysis.
5. Imagine Ways of Addressing These Needs and Problems: Now you have reached the real starting point: Not preconceptions and solutions looking for problems, but qualified, articulated needs and problems with no obvious solutions (if the solutions were obvious, someone would have done them already). Find the creative minds in the organization (or outside it, if necessary) and brainstorm, imagine possible ways of addressing these needs and problems. A lot of the problems and needs you identified in step 4 are likely to be competency and capacity-building needs — avoid the temptation to jump to the conclusion that ‘awareness’ and ‘training’ are the right solutions to such problems and needs (things happen for a reason, and if people aren’t aware and aren’t motivated to learn themselves, it’s unlikely that your awareness and training solutions will get traction). In the above diagram, this step is the letting come phase.
6. Create a Future State Vision If Your Imagined Solutions Were Implemented: Tell a compelling story of how things could/would happen if the solutions you imagined in step 5 were implemented. Then deconstruct how to get there and use it to budget the money, time and resources needed to implement them. The story becomes your business case: present it with the request for needed resources.In the above diagram, this is the envisioning phase.
7. Experiment and Prototype: Start small — your imagined solutions will never be perfect, and small-scale experiments and prototypes will allow you to refine the solution before spending all the resources on an imperfect solution. These experiments and prototypes will also allow pilot users to embrace and champion and virally market them to the rest of the organization, since in the piloting process they become a ‘part of the solution’, and make it theirs.
8. Scale Up: Expand the pilot to all users who share the need or share and appreciate the problem. Make adoption voluntary. Let the users own and collectively self-manage the solution. Once it’s realized, set it free.

So suppose you follow this methodology and discover (a) there are a lot of fledgling, disorganized, self-identified communities of practice and communities of interest in (and extending beyond) the organization that need some enabling knowledge-sharing, context-building, sense-making and connectivity technology and processes to self-organize and function, and (b) there are a set of significant risks, ‘costs of not knowing’, that could be addressed through a prevention and early-warning detection program.

Project (a) may be hard to sell to management because there’s nothing in it for them, and they may be concerned about corporate-sponsored networks operating under their radar. But this need not be an expensive application, and you may have so many zealots clamouring for it by virtue of following the first six steps above that management won’t have the heart to say no.

Project (b) may be hard to sell to any of the customer groups because, while the consequences of not knowing are huge, the likelihood of these risks actually arising may be low (it always happens to ‘the other guy’). But since Enron, Katrina and other low-probability, high-consequence risks have come true, management has a much greater appetite for risk prevention and detection applications. The big challenge is more likely getting the people in the field to comply with the monitoring and reporting requirements of the new system.

What you may also discover with this methodology is that a lot of existing ‘legacy’ applications, processes, programs, websites and tools actually don’t address any important needs or problems. Some of these would have been ‘pet’ projects of someone with resources or decision-making authority. Some would be simple-to-implement solutions (like automation of previously manual processes, or broadcasting of information to everyone in the organization) that were instituted as ‘quick wins’ even though they weren’t really needed or valued. These ‘solutions in search of a problem’ are major components of many large organizations’ processes and infrastructure. The secret (as long as you don’t run afoul of the person whose ‘pet’ project they were) is to get authority to get rid of these unnecessary, low value processes, programs, apps, websites and tools and see if anyone even notices their disappearance. Such ‘cleanup’ activities are thankless, but they can eliminate a lot of clutter and wasted maintenance time, and allow more valuable solutions to get more visibility and achieve more traction.

The largest challenge that this methodology presents is that it takes longer than ‘presupposed problem and imposed solution’ approaches. It’s not precise, often defies quantitative ‘success measures’, and rarely has a discrete ‘project end’. To those brought up with traditional management methodologies, this could be very troubling. Part of your job is therefore likely to be bringing management up to speed on complex, adaptive systems and the failure of prescriptive, fast-track, top-down, centrally-managed, discrete-start-and-end projects and programs to deal with them effectively.

I believe that in ten years understanding complexity will be essential learning for all business students and managers, and this task will be much easier. In the meantime, we pioneers will have both the excitement and the frustration of being ahead of the curve.

I’ll keep you informed on how it’s working on my new project.