Behavior so easy to adopt but extremely hard to get rid of – handoffs are today’s corporate reality. Since it is so easy to describe in a process, easy to implement using popular tools and easy to point to in the factory floors and assembly lines, such behavior is considered to be corporate standard and the behavior that should be promoted.
However, personalizing work (as in “my task” or “your task”) makes teamwork almost impossible wherever knowledge work is involved. Today we more and more realize how different and incomparable are “grey muscle” and “pink muscle” work. Grey muscle work, or knowledge work, is almost impossible to properly sequence and specialize. It is in all its parts a product of intensive brainstorming and continuous experimentation. Its highest effect is in mutual exchange and constant collaboration, which creates result larger than sum of individual parts in contribution. In such circumstances, it is next to impossible to effectively hand the results of such work over to another individual – such action loses context and all the hard work and learning done in the previous phase. Only the subset of those is handed over and everything that is missing is, more likely than not, going to be reexamined and learnt all over again in the attempt to reconstruct the context lost in the handoff. Recipient in the handoff is often cornered with insufficient time to relearn all the necessary stuff and a lot is left to assumption and guessing, further leading to missed opportunities, rework and thus are considered to be waste.
Sequencing and personalizing work is part of most company cultures, and it seem to be a heresy to even start considering doing things otherwise.
Every handoff denotes a point of junction of two parts of the system. To put it in tech words – an API. In any system, number of API-related bugs (e.g. calls to other systems, other components, other methods) greatly outnumber other types of bugs (e.g. algorithmic or logical bugs). The same is with human systems.
However, in pursuit for profits and control, people are measured for individual performance and encouraged to work in isolation as much as possible. Often times such decisions are disguised as “teamwork” in “teams of specialists” who are naturally going to hand their work over and work in isolation, since there are no overlaps in skills and domain knowledge between them.
By doing so, the work is further dehumanized and collaboration opportunities are minimized.
Consider these wedding photographs:
(Photos from Chris Chambers – Wedding Photographer)
We are presented with the final results which are lifetime memories for the married couples. However, we see the pictures and possibly imagine fairytale-like settings there. On the other hand, those couples and photographers were there. They know the context of the pictures and all the impossible stances photographer took to take those photos. They have the whole story to tell about the pictures, but we are handed the result – the photo itself – to do something with it. And we will fill it with all sorts of assumptions and prejudices – we will simply invent the context, since we need context and we don’t know the original one.
I call this effect “wedding photos”. Others have different names for the same thing (e.g. Jeff Patton, in his “User Story Mapping” book calls it “vacation photos”).
Now, think about the work you do in context of software development team and what sort of info you lose and what you invent when taking the work over. Business analyst to Development team. Backend to Frontend. Development to QA. Everyone loses something.
Handoffs over time transform to buck passing and dysfunctional organizations where everyone protects himself against others – effectively protecting what he considers to be “his work”. Especially if the performance management or individual KPIs are involved. You simply get what you measure, and collaboration and teamwork is hard to measure.
If you want to nourish highly effective product development team culture, try to avoid building a culture of handoffs. People thrive in collaboration. Provide all the necessary means for the team to reach shared understanding, to have shared contexts. Beware the pitfall though – shared information is not the same as shared understanding. Write down the decisions, of course – to remember, but don’t use them for communication. Whenever passing an information around, do whatever needed to pass the context around as well and verify that the understanding is also shared. This will lead you to the team that cares and has the same shared goal.
Title photo by tableatny (Creative Commons license)