Them And Us

The formation of ingroups (and, thus, outgroups) is a natural human phenomenon. In the world of organisations, ingroups and outgroups abound.

One particular partitioning I see regularly is the division between “management” and “workers”. Members of each group self-identify, and in even the smallest organisations, members of the management ingroup can hold views widely at variance with the views of those who see themselves as “workers”.

Kent Beck is reported to have stated at Snowbird in 2001 that one goal of the Agile Manifesto was

“…to heal the divide between development and business.”

Presumably, then, this divide has some more or less pernicious consequences. Fundamentally, I suspect the most significant consequence is the impact of such division on the levels of trust between members of these two groups. And, absent trust, the working relationships between members of these two groups are bound to be fraught, to say the least.

The Management Viewpoint

Here’s the default management viewpoint (I feel qualified to express this, having self-identified with this group from time to time).

• I’ve got far more important things to worry about, and on which to spend my limited time and attention, than matters relating to software development.
• Software development is always borked, so no one’s going to complain – and threaten my future career prospects – if it continues to be borked on my watch.
• Development is “technical” and my peers will ridicule me – and thus put my future career prospects under threat – if I appear to know too much about it (cf. threat to ingroup solidarity),
• Having someone being seen to be in charge is more important – both to me and to the success of the organisation – than any “mere details” regarding efficacy, value, customer satisfaction, etc.
• Customers do matter, but the quality of our software, its ergonomics, etc. is a minuscule component of our overall customer satisfaction ratings, Net Promoter Scores, etc..
• As managers, we have so much to do that we find it hard to give anything the undivided attention it might require.

The Development Viewpoint

Here’s the default development viewpoint (I feel qualified to express this, too, having self-identified with this group from time to time).

• There’s nothing more important to the survival of this business than the software we produce, and the way we go about that. Why can’t managers see that?
• Software development has always been borked. But we’re smart people and we can fix it. It drives me insane to have to continue working in borked ways.
• Development is “technical” and managers can’t or won’t get down and dirty to understand key things that they need to understand to make good decisions. And they don’t trust us to make or even provide input on any key business decisions.
• Managers seem to think that having someone “in charge” is more important than making good decisions.
• Our software is a crucial element in the customers’ experience of our products, service, brands and business.
• As developers, we have so much to do that we find it hard to divert our attention from the one thing we agree is most crucial at any given moment.

I guess there’s a whole passle of other aspects to these groups’ respective viewpoints, too.

It’s not been my intent with this post to judge which group has the more useful viewpoint. Rather, to illuminate the often diametrically opposed aspects of these two groups’ ways of seeing the world of work. And the beliefs held by, and a part of the self-identity of, each respective ingroup.

Maybe such illumination can help in some small way to bridge the ingroup/outgroup boundary (a.k.a. divide, rift, gulf) between them.

– Bob

Further Reading

The Five Dysfunctions of a Team ~ Patrick Lencioni
Great Boss, Dead Boss ~ Ray Immelman