Tag: design patterns

  • Design Methods as Performative Objects

    Brown and Duguid’s (2001) concept of a “network of practice” has been niggling away at my consciousness. The idea is that a collection of people are enabled to understand each others’ work because of commonalities in practice, but not to the extent that a Community of Practice creates shared ways of framing and performing work:

    “we include under the rubric … groups whose members, to the extent that they have common practices, are able to read and understand one another’s work. Disciplinary networks of practice cut across heterogeneous organizations, including, for example, universities, think tanks, or research labs. Professions make up yet other such networks of practice, where again similar practitioners, by virtue of their practice, are able to share professional knowledge through conferences, workshops, newsletters, listservs, Web pages and the like. … different networks of practice cut horizontally across vertically integrated organizations and extend far beyond the boundaries of the latter. Along these networks, knowledge can flow.” (Brown and Duguid 2001, p. 206)

    So create closer bonds than organizational membership, spanning organizational boundaries. If the type of intersubjectivity that derives from shared practice (i.e. what Polanyi calls tacit knowledge) does not underpin a network of practice, what does? This rings true, given the observation that IT professionals identify more with the interests of their profession than with their organization (Chou and Pearson 2012). Which brings me to the second property of networks of practice:

    “it is important to note that networks of practice may also inhibit the flow of knowledge. As Lynn et al (1996) show, professional networks will occasionally work to resist the spread of ideas felt to be inimical to the interests of the network’s members.” (Brown and Duguid 2001, p. 207).

    So how do networks of practice share knowledge? Brown and Duguid have an explanation:

    “We have used the notion of networks of practice to explain leakiness. This is not, we have suggested, simply an inherent property of some kinds of knowledge. It does not result from making knowledge explicit and so tradable. It is, rather, a function of the common underlying practice, which creates social-epistemic bonds. Where practice doesn’t prepare the ground, knowledge is unlikely to flow.” (Brown and Duguid 2001, p. 207)

    But this is not very satisfying when members of the network are not co-located. Surely, “common underlying practice” includes some form of shared framing as the basis of those social-epistemic bonds? I thought back to the work of Howard Rosenbrock (1981), who explains that IT professionals’ paradigm of system design with the aim of making users interchangeable results in deskilled, repetitive, and unfulfilling jobs for those who use these systems. He explains:

    “The paradigm is transmitted from one generation to another, not by explicit teaching but by shared problem-solving. Young engineers take part in design exercises, and later in real design projects as members of a team. In doing so, they learn to see the world in a special way: the way in fact which makes it amenable to the professional techniques which they have available.” Rosenbrock (1981, p.6),

    So we have design methods as a form of performativity, embedding ways of framing job design, as well as creating a shared design practice that ignores users’ psychological and motivation needs. But surely, IT professionals are continually learning, acquiring new skills and approaches to system design? It would appear not:

    “The fact that most IS professionals learn the bulk of their technical skills during college or immediately afterward encourages recruiters to focus on technical skills for new hires. IS professionals generally learn non-technical skills in the workplace.” (Lee et al. 2001, p.28).

    All is not lost. Lee et al. (2001) go on to observe

    “IS professionals generally learn non-technical skills in the workplace. And because these non-technical skills are so valuable in the long term, new hires need to possess the aptitude to learn these skills. This may help explain why recruiters prefer graduates who took more MIS classes than those who concentrated strictly on computer science courses.” (Lee et al. 2001, p.28).

    How can we remedy the perspective that leads to such impoverished outcomes? As Rosenbrock observes, IT systems can be seen as a replacement for human ingenuity and skill, or as a way of supporting these. We have a choice to automate or to informate work (Zuboff 1988). We also have two chances to undermine the automation-on-rails approach taught in so many methods classes. Back to the network of practice idea. IT professionals have a network of practice with really strong bonds. We can teach IS methods more thoughtfully to those who return – for ongoing education in Masters degrees, etc.  Finally, we can mobilize the network of practice, on LinkedIn and elsewhere, to ensure that IT professionals are aware of the types of skill and knowledge-preserving approaches to organizational system design that we would want to see used in our own organizations.

    References

    Brown, J.S. and Duguid, P. 2001. “Knowledge and Organization: A Social-Practice Perspective,” Organization Science (12:2), pp. 198-213.

    Chou, S.Y. and Pearson, J.M. 2012. “Organizational Citizenship Behaviour in It Professionals: An Expectancy Theory Approach,” Management Research Review (35:12), pp. 1170-1186.

    Lee, S., Yen, D., Havelka, D., and Koh, S. 2001. “Evolution of Is Professionals’ Competency: An Exploratory Study,” The Journal of Computer Information Systems (41:4), pp. 21-30.

    Rosenbrock, H.H. 1981. “Engineers and the Work That People Do,” IEEE Control Systems Magazine (1:3), pp. 4-8.

    Zuboff, S. 1988. In the Age of the Smart Machine. New York NY: Basic Books.

  • Design as Bricolage.

    When attending a boundary-spanning design meeting the other day, I was reminded of how important pattern sensitization is to design. When we explore a new problem-situation, we structure it according to the patterns that we perceive in that situation. This is why experienced designers are so much better at design than novices. It is not that experienced professionals are sharper, or better at design — but just that they have a wider repertoire of patterns to call upon. As they recognize familiar elements of the situation, they fit partial solutions to those elements. Problem decomposition is not hierarchical, in the sense proposed by Alexander (1964), but convergent. The problem-space and the solution-space co-evolve, as designers explore these in tandem (Maher and Poon, 1996; Maher and Tang, 2003).

    Back to the meeting.
    A group of strategic managers (including the systems people and the business process change manager) were examining how to revise business process support for a routine workflow. The problem that they faced was that this had been adapted by several workgroups (whose representatives were present) over time. So each of these managers had a different perspective of the problem, depending on what each group was trying to achieve. The customer support group were frustrated that they could not access all of the customer information in the system, but had to call another group to obtain missing information. The order-processing group were frustrated that they could not track the progress of an order without having to run three separate IT applications. The sales and marketing group were incensed that not all of the latest products and services were publicized on the website. None of these people – including the IT group managers – could see that these were related problems. They spent hours debating the fields to be displayed on the screens and the detailed reports needed, without realizing that the workflows were related.
    The breakthrough came by accident, when the Process Improvement Manager was mapping the “requirements” on a whiteboard. He started to link two of the requirements, stood back and then said “So this step is also related to this one, isn’t it?” Then the Marketing Manager said “That comes just before the promotions stage.” As the Process Improvement Manager drew a process diagram, each individual kept adding in pieces of the puzzle, with how they were related.

    Design as bricolage.
    Bricolage involves repeated “trying out” and experimentation until a pattern is discerned that is useful. (The word derives from Bricoleur, a French term meaning “handy-man” or “jack- of-all-trades.”) Claudio Ciborra described bricolage as “the constant re-ordering of people and resources that is the true hallmark of organizational change.” But Bricolage is not random experimentation. It is based on leveraging the world “as defined by the situation” (Ciborra, 2002). Pattern sensitization adds another dimension to bricolage. It can now be seen as an ordering of situation elements until they make sense according to previously encountered patterns. So design is like a jigsaw. Each person carries around a partially-completed set of jigsaw pictures in their heads. The core problem of design is to use a problem-representation that can allow people to communicate the structures in their “mental jigsaw picture” to others.

    References
    Alexander, C. Notes On The Synthesis Of Form. McGraw Hill, New York NY, 1964.
    Ciborra, C.U. The Labyrinths of Information: Challenging the Wisdom of Systems Oxford University Press, Oxford UK, 2002
    Maher, M.L., and Poon, J. “Modelling design exploration as co-evolution,” Microcomputers in Civil Engineering (11:3) 1996, pp 195-210.
    Maher, M.L., and Tang, H.-H. “Co-evolution as a computational and cognitive model of design ” Research in Engineering Design (14:1) 2003, pp 47-64.