Technology and Organizations

Bruce Nussbaum recently asked via Twitter whether design thinking was the new liberal arts. He describes design thinking as “the integrative solvent that brings together the programs through a powerful methodology that solves a myriad of problems.” He says we should be moving away from the MBA and on to the MBD (Masters of Business Design). I agree with the importance of “design thinking,” but will focus my thoughts here on systems design. Systems design more clearly, for me, includes all of technical, organizational, and people systems than does the term “design thinking.” I’d also push ahead and say not just “liberal arts,” but “general education.” Basically, I think Mr. Nussbaum and I are both saying that systems savvy and design skills are critical for all of us, and need to be included in broad-based educational offerings.

Universities are getting on-board (and I hope high schools are as well — do you have any links to share?). Atwater, Kannan, & Stephens published a 2008 study of the extent that Business Schools teach “systemic thinking.” While the definitions varied, the majority of the top 63 graduate schools of business were teaching aspects systemic thinking, and 74% of the respondents agreed that the topic was essential in graduate education.

How do we teach systems design skills to people without a technical systems design background?

A simple translation of the basics of systems analysis provides a start. I’ve translated Hoffer, George, and Valacich’s information systems analysis concepts to a more general work systems form with the acronym: BUILDER. The idea is that the first skill you need is how to map where you hope to go with your systems design, and the context that you must deal with to get there.

• Business objectives: These are the basic motivations for what you’re trying to do. You may not think of them as “business objectives,” but it will certainly help you get organizational support if you do. For more personal systems design, just ask, what do I hope to gain from this new tool (e.g., iPhone upgrade) or practice (e.g., telecommuting)?
• Universe: Context and history are valuable both so you can learn from past efforts, and to help you begin to understand the other stakeholders’ interests. Understanding these interests are critical to any future “negotiated implementation.”
• Information needs: Who needs what information, and in what form? For example, in team performance, Transactive memory: Knowing who knows what, who needs what information, and how to coordinate given that knowledge is a key predictor of success.
• Laws: Policies, required procedures, regulations, and the like are an important backdrop to any design. Perhaps you don’t want these to limit your initial thinking, but they ultimately have to be considered, even if just to attempt to change them. For example, financial firms may have federal regulations regarding the archiving of communication. In those settings you must conform to regulations even in the use of social media.
• Dynamics: The time frame and sequencing of stakeholder interactions and build order (Do I have to delete an existing application before I can install the new one?) are the basics of this aspect of the mapping. For any major information technology design it should have “full backup” as a first step.
• Events: By what milestones should the design and implementation be judged? How will you know if you are progressing in the way you hoped? What metrics can you use to track the process.  Tracking is critical as otherwise you can’t know if you need to make adjustments.
• Reach: What is the magnitude of this project in terms of people, money, number of other systems touched? Reach also helps you consider the ROI. How much investment in the process is wise or supported given the reach?

I see BUILDER as providing a set of mapping topics to prepare for the design process. I look forward to taking the next steps: What is design thinking in the context of work systems design? What do all of us need to know? How do we evaluate our TOP (Technology – Organization – People) design skills?  Do we need everyone on the team to have these skills, or is it enough if just one of us does?

Tweet This Post

The more I think about “All of Us as Accidental System Designers,” the more I wonder about how to teach the skills.  Yesterday I spent the afternoon on a field trip to IDEO with a group of visitors from Syngenta and Purdue University.  My guess is that everyone at IDEO has the systems conductivity capabilities I’ve talked about.  They are able to consider the broad range of both technical and behavioral options, and they have high intrinsic motivation for “having a positive impact” (be that more environmentally sustainable products, or impact on your firm’s bottom line) in a way that thinks about meshing technology and practice together.
I heard the phrase “design thinking” a lot during the presentations and tour. Tim Brown’s (of IDEO) blog has an interesting discussion around the definition of design thinking. It opens with “Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”

IDEO has a strong connection to Stanford’s “d-school,” the Stanford Institute of Design. The d-school page has the following to say about  “design thinking”:

Having worked with hundreds of organizations to design products, services, and environments, we believe true innovation happens when strong multidisciplinary groups come together, build a collaborative culture, and explore the intersection of their different points of view.

Many talk about multi-disciplinary collaboration, but few are actually successful at sustaining attempts to see what will happen. Even strong partners often lose interest because they cannot get along well enough or long enough to see the fruits of the collaboration.

We believe having designers in the mix is key to success in multidisciplinary collaboration and critical to uncovering unexplored areas of innovation. Designers provide a methodology that all parties can embrace and a design environment conducive to innovation. In our experience, design thinking is the glue that holds these kinds of communities together and makes them successful.

Their Tranformative Design Class looks wonderful: (Bill Moggridge of IDEO is one of the instructors)

Transformative Design examines the implications of design decisions: the ways in which your designs change the world, and also the ways in which the world changes your designs. In this project-based course you will learn how to employ interactive technologies to create designs to expressly encourage behavioral transformation. Class sessions will be structured around project work and interdisciplinary discussion of topics such as self-efficacy, social support, and mechanism of cultural change; accompanying lab sessions will familiarize students with basic hardware and software tools for interaction prototyping.

I don’t see a strong information technology focus at the d-school, beyond that mentioned in this course, but I may just be missing it.  Modern information technologies often have an abstraction that makes their deep understanding — a prelude to understanding how to include them in systems design — more difficult than more concrete products.  I’ve subscribed to the d-school blog and look forward to learning more about their programs.

Tweet This Post

Look for people with tolerance for ambiguity and intrinsic motivation for engaging technical and organizational systems, and I think you find people who are likely to try new technology tools at work. I’m still playing with the ideas of All of Us as Accidental Systems Designers and trying to understand why some people take to this role easily, and others do not.

Hoffer, George, & Valacich describe one of the characteristics of successful systems design teams (they focus on teams as it is so rare that true systems design can be done individually) as: “Tolerance of diversity, uncertainty, ambiguity.” Tolerance of ambiguity is “… ‘the tendency to perceive ambiguous situations as desirable,’ whereas the intolerance of ambiguity refers to ‘the tendency to perceive (i.e., interpret) ambiguous situations as sources of threat’ (p. 29).” (Judge et al., 1999, based on Budner (1962), full pdf)

Think about how people approach new technology tools. My classic example is how different people react to the suggestion to use a wiki to manage a team project. Tolerance for ambiguity, as described above, describes the response I see from some of my colleagues: they are willing to give it a shot — they may roll their eyes at yet another of my suggestions, but they are game to try. Intolerance of ambiguity describes another (luckily, much smaller) portion of my colleagues: they see a wiki-like tool as something that will lose their data, lose their rights to their data, or add one more thing to their already long list of things to do.

Another response is more extreme: a colleague hears my suggestion and proposes we take it to the next level. Something like, “Wiki sounds great, but let’s also try using a group Twitter tool so we can stay up-to-date on the progress of the project. I’ve never done it, but this would be a great time to try.”

I think this is someone who has both tolerance for ambiguity and intrinsic motivation for engaging technical and organizational systems. The trait — tolerance for ambiguity — reduces the perceived hurdle of trying something new, and the task-specific state — intrinsic motivation around organizational and technical engagement — combines with tolerance to push us in a new direction. This kind of person is well situated to be an accidental, but elated, systems designer — They are getting to do what they enjoy, and have the internal capability to put up with the challenges.

Intrinsic Motivation: (from Hennessey & Amabile, 2005):

Intrinsic motivation is the motivation to do something for its own sake, for the sheer enjoyment of the task itself…. Theorists have emphasized the role of certain psychological states in the experience of intrinsic motivation, including a sense of self-determination or perceived control over task engagement (Deci and Ryan, 1985) and a sense of optimal challenge (Csikszentmihalyi, 1997) that enhances self-perceptions of competence (Deci and Ryan, 1985). The highest level of intrinsic motivation state has been labeled “optimal experience” or “flow” (Csikszentmihalyi, 1997).

Who are these people who actually enjoy engaging technical and organizational systems? Maybe in the old days they were time and motion study experts (the kind with a passion for improving the organization, not the kind focused on driving the worker out). The Gilbreth’s would be in this group. Their family life was the source of the book (1948) ) and movie (1950) “Cheaper by the Dozen.” Modern versions could include your colleague who’s always pestering you to try a slightly better way to do things in your team, or professors of management, at least the ones with a technical bent.

I’m going to call the combination of tolerance for ambiguity and intrinsic motivation for engaging technical and organizational systems: System Conductivity — both as it relates to the ability to direct technical and organizational systems toward new designs (cf. symphony conductor); and the ability to carry the necessary energy for new design (cf. electrical conduction). I expect people in the category of having both high tolerance for ambiguity and high positive intrinsic motivation for engaging technical and organizational systems to be perhaps even be proactive, rather than accidental, designers — people who look for opportunities to improve, or at least try to improve, the performance of their systems.

The best designers will have also have an underlying systems sense that helps them understand the costs, benefits, opportunities, and hurdles related to attempts to use technologies that are not quite stable, practices that may or may not be better than what we are currently using, and on-going revisions to work practices built on such systems. By thinking about system conductivity, we can better understand our own motivations and attitudes, as well as those of our colleagues — and how these motivations and attitudes are likely to influence willingness to try new technology tools and organizational practices.

And here’s to all those tech support folks who must put up with those who lack system conductivity:

Tweet This Post

Another tidbit from my astute colleague at JPL, Dr. Lynne Cooper, Knowledge Strategist (such a great title):

To continue the dialogue about meetings, I think it’s almost a useless word, because every time a group of people come together to collaborate it gets labeled a “meeting” even though there are many shades of meaning. When I schedule “meetings” I intentionally differentiate between work sessions, get-in-synch sessions, peer review sessions, reporting, etc. – each with different expectations for behavior. Would love to get into a debate on this because I feel it’s important and a lot of the “wisdom” about how to conduct meetings is based on an antiquated, management-centric view of meetings rather than a work-centric view of collaboration.

She’s not going to get much of a debate from me as I agree, wholeheartedly. Expectations about behavior are crucial to meeting preparation, and to the ultimate dynamic of the meeting.

That said, why is it that it’s so hard to have people prepare for a meeting (i.e., send out an agenda, block time in advance to gather needed materials and read background information)? My theory is that it is difficult to see the return on investment of planning our work process (we have little visualization). We don’t have hard evidence or numbers (PayScale’s Meeting Miser provides a basic (very basic) calculator of meeting cost.) around the importance of preparation; left in the abstract, we are unlikely to have a trigger that says this must be done.

Lynne’s perspective drives home the point that there should be no meeting without a true goal. If you can’t describe what’s to be done (work session, get-in-synch, etc.), then you’re not yet ready for the session. If you don’t know the goal, then you can’t provide the description and/or an agenda, and the participants have no way of coming prepared. You are doomed.

As per my prior post, we are all systems designers — a “meeting” is part of that system. Effective systems designers start with the definition of requirements (even if it is to just say “Generate new ideas for proposal”). Systems muddlers begin unprepared and end-up costing the organization rather than providing benefits.

Prior thoughts on meeting management: Better conf calls, Notetaking in face to face meetings.

Tweet This Post