Them And Us

Them And Us

Ingroups

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

2 comments
  1. OK, second attempt (probably a bit lazier too in that this is probably shorter as a result)…

    Having also sat in both the developer and manager chair, it seems most work systems in use at organizations emphasize I-shaped managers with control mechanisms (financial, risk, schedule, etc.) as their fundamental tenet. We need T-shaped managers, just as we want T-shaped team members. To fundamentally ‘control’ things outside of what one is doing directly requires more understanding and empathy with other members of the organization; this should come as no surprise then that one of the directions for generalizing could be understanding more about IT. It’s a shame our work systems continue to emphasize even greater specialization around certain management aspects the higher one goes.

    Cheers!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: