Who’s Chunking Up Your Project?

I was at a conference recently, following a project manager’s presentation about the project he was leading. The show was very professional, though skewed to provide a good image of both the presenter and the company he is working for. After just a few minutes into it, I felt lost in his words. I went mentally through the first part of presentation again, re-picturing the slides in my head and… I realised what he said until then was… more or less nothing!

Paying more attention to the next few sentences I got the explanation: he was chunking up his concepts!

Chunking is a concept well known in psychology and very much put into practice in NLP. It’s about how a certain subject is presented: either in very generic terms (chunked high) or with richness of details (chunked low).

An example: talking about a car you could call it:
1. A vehicle, a means of transportation, an object
2. a Toyota Prius blue metallic built in March 2009.

In both cases we’ve described the car, but while the first descriptions were very generic, i.e. “chunked high” or in “big chunks”, the second was more detailed, i.e. “chunked low” or in “small chunks”.

The chunking level is a basic characteristics of the way each of us communicate. Unless we pay attention to it, we fall into the same pattern over and over again.

Chunking high is also a very well know technique in sales to reach agreement: when the subject matter is washed out in a sea of very generic terms, what type of disagreement can there really be? Would you disagree on the fact we all want the best product at the lowest price? Does that tell you anything special about the product or the price?
Now back to projects, be they agile or not: what has all this to do with the daily life in development? Well, a lot: two people talking to each other using two different chunking levels will have a hard time really agreeing on something.

Think about the typical meeting where the marketing guy talks at a very high level about the features needed in the product – i.e. chunking high – while the engineer reasons in terms of details of the technical implementation of the very same feature – i.e. chunking low -. Despite having a common subject to talk about, they will definitely not understand each other. Sure, it has obviously to do with the competencies of each of the two, BUT when they will try to agree on what exactly gets implemented and how it will be done you can be sure there will either be no agreement or an agreement full of misunderstanding.

Same happens when the development team (typically chunking low) talk to upper management (typically chunking high): the misunderstanding I saw in these scenarios are explaining why some companies are now bankrupt!

So what could you do?

First of all, noticing: just becoming aware of the different chunking level of a conversation will help you to drive the discussion better.

Second, be the bridge between the two worlds: request somebody who chunks high to qualify her statements and help her doing that: it’s just the way she works. Same for who chunks low: bring her to see the forest instead of a tree (or a leaf, or just a small part of a leaf!). Again, it’s just the way she works.

Third, when something gets agreed, make sure it means the same to everybody no matter what the chunking level is. Provide a description of the decision both as an overall statement and as a concrete set of detailed information. In particular, watch out for agreements based on chucked-high concepts, as they will hurt you later: who could ever disagree to want products that are cheap, have a good quality and delight the customer, but what do we exactly mean with those words? In particular be aware of people artificially chunking up your project as they are often using this technique (sometimes voluntarily, but often enough also involuntarily) as a mean to hide from responsibility.

It takes discipline and patience to tame the chunking level in your projects, as you will get some resistance from your interlocutors because they do not see/feel/hear the need of describing the situation in different terms than they just did, but you’ll be definitely bringing the team into safer waters!