Organizational Design and Engineering

Today I presented a paper I wrote together with Marinka Copier and Thijs Gaanderse at the International Workshop on Organizational Design and Engineering in Lisbon. My participation in this workshop brought me a lot of new insights. Not just from the reactions to my presentation, but also from listening to the other speakers and participating in the discussions that went on here these past two days.

One early comment that resonated with me was the distinction that was made between "hard" and "soft" elements of an organization: on the one hand hard artifacts that can be designed (information systems, offices, business processes, etc.) and on the other hand the parts of organizational systems that cannot be designed, such as individual behavior and social interaction. This of course lies at the heart of my own research and of my interest in game design.

I was encouraged by the reactions to my conception of a rule-set as the minimal structure that an organization is looking for. Case studies like the one described in our paper were recognized as a valuable research setting that add an important empirical element to related conceptual and theoretical work (such as that by Joao Vieira da Cunha, also present at the workshop). One insightful comment was that the term "minimal structure" does not relate so much to the number of rules, but to their elegance and their affordance for emergent behavior.

The keynote today was given by Antonio da Camara, CEO of a company called YDreams. Besides some of the very interesting projects his company is doing, he talked about how he designed his organization. What I thought was his most interesting remark was: "If I were to start another company now, it would be less emergent but more based on my experiences in the past." This points to the need for supplying design knowledge to managers and entrepreneurs. It also addresses one of the questions that was raised during this workshop: who will use the results of our work? My answer to that question is - based on the discussions here - that the results of our work on organizational design are not directly applicable by managers or entrepreneurs. As a matter of fact, it was pointed out that there have been big failures when working from the assumption that everyone can use these methods themselves. Applying organizational design knowledge requires specific training, so a manager will need an (internal or external) designer to come in and help him with this task. Much in the same way that managers will not design buildings or information systems themselves.

A presentation that got me thinking was the one by Robert Winter. He has been doing very interesting work on what he calls method engineering. I did not know this label before today, but it is actually part of what I'm doing in my research: I am constructing (or: engineering) a method for organization design. His point was that there is often too great a distance between the method and the actual problem that it is being applied to. He used the example of Davenport's BPR method. This is a very general method, being applied to a great variety of problems. Sometimes it can be better to make a method adaptable to specific design goals or context contingencies. This is definitely something to think about in my research as well: perhaps the steps we go through in our method should not be the same for all design problems.

I look back on a very worthwhile couple of days. Interesting discussions with fellow researchers, much food for thought, and a feeling of validation for the direction that my research is taking.