Linear is Not Always Best

Our society has made a fetish of linear thinking. We’ve been trained to expect that A will lead to B, which in turn will lead to C. We breathe a sigh of relief whenever we experience what Webster’s New Millennium Dictionary of English describes as a “step-by-step progression where a response to a step must be elicited before another step is taken.”  All of this is deeply comforting — even when it is not entirely appropriate.

In the June 2009 issue of KMWorld Magazine, Dave Snowden recounts an experience from the beginning of his career in which he elected to design a new system in a manner that didn’t fit well within established design methods.  He was creating something that had never existed before and decided early on that IT’s usual linear approach wasn’t going to work.  In fairness, it sounds like he initially did try to conform.  However, once he set about to gather requirements he quickly discovered that

…few if any of the users had any idea of the capabilities of software.  As a result, if you asked them what they wanted, they told you what they currently did, or asked for automation of existing processes.  To use an adage of that time, `Users say they know what they want until they get it, and then they want something different.

Instead of IT’s traditional linear approach, he adopted an iterative method whereby he and his clients engaged in a more curvaceous  “co-evolutionary process” to develop the new system.  Drawing on his own substantive experience of the work his clients were trying to do, he approached the design effort in the following way:

…I could talk with the users in their own language; go away and develop a module with real data; and create reports, monitoring screens and other processes based on a synthesis of my knowledge, the stated needs of the client and my knowledge of the technology.  The application would work in novel ways, users would find new ways of working, and modifications would be agreed upon.  Over the course of a year, a powerful application emerged that was very different from anything that either the user or I could have defined.

In many ways, this is a textbook description of how to implement social media tools within the enterprise.  Work iteratively with your users, create opportunities to learn from each other and from the tool using a series of “safe-fail” experiments, stay in beta for as long as it takes to reflect user reality in your tool, and don’t be afraid to step off the straight and narrow path of linear thinking.  To be clear, this is not a recommendation that you abandon all logic in your design and implementation.  Rather, it is a reminder that there can be great beauty and greater rewards in following a more circuitous route.

[Photo Credit:  Headsqueeze]

Share

13 thoughts on “Linear is Not Always Best

  • May 28, 2009 at 2:02 am
    Permalink

    Liked reading this post. And believe in what it advocates too! Of course, we need to learn to handle folks who cannot work without clear and concise plans before we begin our 'projects'. Like I was musing the other day on Twitter…we need to learn to live with ambiguity and not demand a conclusion on each and everything.

  • May 28, 2009 at 9:10 am
    Permalink

    Thanks, Nimmy. As the world becomes increasingly complex, it will be harder
    to find linear plans that allow us to operate effectively, That's when it
    really helps to be comfortable with the ambiguity of working iteratively.

    – Mary

  • May 28, 2009 at 9:17 am
    Permalink

    Ain't it the truth! Designing or developing anything new needs to be an iterative process, not linear. Iteration is key to the Agile software development methodology which is being adopted widely because the resulting software is more likely to meet the users needs (and for other reasons as well.) Admit it, it's impossible to make perfect decisions and assumptions along the way and using an interactive approach affords us the opportunity to refine those decisions.

  • May 28, 2009 at 9:28 am
    Permalink

    That's so true, Janet. The key to this, however, is bringing some of the
    perceived discipline of linear thinking to the more free-form iterative
    approach. Otherwise, how on earth would we ever deliver projects on time?

    – Mary

  • May 28, 2009 at 9:57 am
    Permalink

    I have to say, I'm having trouble getting this–perhaps because I'm attempting to understand a non-linear process with linear thinking. Do you have to think non-linearly to understand non-linearity? How is Dave's design process non-linear? Working iteratively sounds fairly linear to me. What is non-linearity, anyway?

  • May 28, 2009 at 2:10 pm
    Permalink

    At the risk of putting words in Dave Snowden's mouth, my sense is that in
    its simplest terms a true linear process would suggest that we gather
    requirements, set our goal and then march through the plan step by dependent
    step until we've provided the deliverables necessary for the goal. My take
    on the process Dave used is that he started with the realization that
    neither he nor the clients truly understood what the right goal was, so
    coming up with a detailed linear process was going to be difficult.
    Instead, he listened to them, went off and designed something, brought it
    back for them to try, and then went off again to implement the improvements
    they requested as they learned to work with the tool. It sounds like this
    more circular process was repeated several times, producing incremental
    improvements, until they ended up with a tool that did more and better than
    they could have conceived at the beginning.

    – Mary

  • May 30, 2009 at 1:30 pm
    Permalink

    This is just a repetative linear process understanding that the first attempt, second and maybe many more do not accomplish the best way of resolving a problem. Many IT types do not understand the needs of the client (who doesn't understand IT) and most clients are handcuffed by their lack of knowledge of what IT and programs can really do. Some clients believe that there are limitations to IT that, in fact, do not exist. It is only their limited knowledge of IT and their arrogance that their knowledge is substantial that restricts them from asking for what they really could use in the first place.

  • June 2, 2009 at 1:52 pm
    Permalink

    I just ran across (via @cubistscarboro) a blog post (http://tr.im/nbQE) by Dave Cormier (@davecormier) of Edtechtalk regarding the difference between straight (i.e. linear) and curvy knowledge – and its impact (as well as the use of open educational resources) on education. The discussion on the differences – keeping planes in the air vs. a group of 12 year olds trying to connect to history – also shows there are times when you need don't need to be straight.

  • June 2, 2009 at 11:39 pm
    Permalink

    Riong –

    I'm willing to admit that there's plenty of ignorance on both sides of the IT/client discussion, but that doesn't let us off the hook. If a lay person came to me with a legal problem and a desired outcome (i.e., success), I wouldn't condemn the client for failing to understand and propose all the appropriate legal theories that might advance their position. That's my job – just as it's my job to ensure the client understands what I'm talking about. (It's a form of informed consent.) Similarly, the burden still lies on IT to find more creative ways of interacting with their clients so that they actually deliver what the client needs rather than just what the linear plan dictates.

    – Mary

  • June 2, 2009 at 11:43 pm
    Permalink

    Thanks for this link, Theron. It's an interesting piece.

    I'm not sure I entirely buy the straight vs curvy types of knowledge, but I do think there are straight and curvy ways of conveying and acquiring knowledge. And, each should be deployed as most appropriate to serve the interests of the student. Could we implement a similarly flexible approach to IT projects?

    – Mary

  • June 3, 2009 at 3:39 am
    Permalink

    Riong –

    I'm willing to admit that there's plenty of ignorance on both sides of the IT/client discussion, but that doesn't let us off the hook. If a lay person came to me with a legal problem and a desired outcome (i.e., success), I wouldn't condemn the client for failing to understand and propose all the appropriate legal theories that might advance their position. That's my job – just as it's my job to ensure the client understands what I'm talking about. (It's a form of informed consent.) Similarly, the burden still lies on IT to find more creative ways of interacting with their clients so that they actually deliver what the client needs rather than just what the linear plan dictates.

    – Mary

  • June 3, 2009 at 3:43 am
    Permalink

    Thanks for this link, Theron. It's an interesting piece.

    I'm not sure I entirely buy the straight vs curvy types of knowledge, but I do think there are straight and curvy ways of conveying and acquiring knowledge. And, each should be deployed as most appropriate to serve the interests of the student. Could we implement a similarly flexible approach to IT projects?

    – Mary

  • Pingback: How to Ruin an IT Project | Above and Beyond KM

Comments are closed.