One tenant of digitalization is that complexity is rising. However, that does not mean that all work units are complex or that every part of work unit is complex. For you as a leader it is paramount that you understand the nature of your work units to decide how to organize work.
Let us take two examples of software feature requests.
Request A: Implement support for an existing standard.
Request B: Implement a new GUI that decreases the cost of configuring your device by a factor of two.
Request A could indeed be very complicated to implement needing experts in the field, but the work is very unambiguous since you are implementing an existing standard. The logical and efficient way to organize the implementation of such a feature is as a number of individual tasks which when all completed signify the end of the work. For example, one person could write the requirements, a second could to the high-level design, a third could to the implementation and a fourth could do the verification.
Request B on the other hand could be very easy to implement technically but the complexity is much higher. To be able to understand what to do, you need to do extensive usage research and you need to do many iterations with lots of feedback from the users. The logical way to do this work is to collaborate extensively as a team.
What would happen if we forced the people working on Request A to collaborate extensively? We would get endless workshops with many of the participants not bringing any extra value. The result would be largely inefficient work. If it is a team full of fun people, it might be fun, but team work should not (only) be fun, it must be efficient. Otherwise it is waste.
On the other hand, what would happen if the development of Request B would work like individuals without any ongoing coordination? The result would most likely be delays because of extensive handovers, misunderstandings and unexpected results that is not effective in reaching the goal.
The conclusion here is that you must identify the complexity of a work task to be able to work in the most efficient way and to produce the wanted outcome. There are of course many other factors that affect if you should work collaboratively or not such as the time available, the cost of failure, the feedback cycle length, the need for knowledge sharing and the size of the development organization, but those are all factors we leave for another article.
But the basic premise sounds easy enough! Right?
It is really not.
Setting your organization up for success
First of all, you need to ask yourself if the groups in your organization has the capacity to do teamwork at all. In our work as consultants, too many times we see groups of people just doing individual work even in the face of complex problems. And when they do try collaborative work, they don’t have the capacity to reap the benefits if doing it. If you want to learn more about building that capacity, you need to read a colleague’s, Daniel Thysell’s, guide on how to create awesome teams.
Secondly, no work unit is 100% unambiguous or 100% complex. Thus, you cannot organize any one task as only individual work or collaboration. You need to be able to dance back and forth between the two different modes of operation with short notice.
There are three different ways to do this called schedules, checks and triggers and you need to set these up to match your organization and the work you do. To learn more about these tools, continue reading the second part of this article, called Dancing with complexity.
If you learn this, and do this right, you set your organization up for both efficiency and effectiveness.
Above article is partially based on theories on Dynamic Work Design by Nelson Repenning, MIT.
This article was also published on Transforming Embedded here.
