If the ground doesn’t correspond to the map...
… then it’s the map that is wrong.
Last week, visit this my son went for an interview for entry into one of the top academic high schools in this state and I needed to kill a couple of hours. I therefore went into a local Borders bookshop, grabbed a book almost at random and sat down with it in the embedded Gloria Jean’s with a cup of coffee. I don’t even remember the name of the book; it was something like “30 Things You Need To Know Right Now”. What has stuck in my mind is the first of these “things”.
If the ground doesn’t correspond to the map, then it’s the map that is wrong.
Sounds simple, doesn’t it?
I must admit that I didn’t read much past that opening chapter heading, because I had one of those “Aha” moments (or more like one of thise “D’oh” moments, I guess).
Everyone today seems to have a preferred point of view about how the world works. Based on that view, plans are drawn out that attempt to map out what we will do and the outcomes that we expect. I admit to having a particular issue in mind here — the issue of “professional managers” that I have blogged about before, and I will use this issue as an example — but the observations that I am making are more generally applicable.
Let me go through a concrete example here. As I have already documented, I believe that a technical activity like software development cannot be managed by a generalist manager. But my view is not universally subscribed to – shocking, I know, but not everyone agrees with my every view, (at least not yet, although I continue to work on it).
So in a particular workplace that I am familiar with, despite my view, there has been a definite move over the past several months away from using managers with a technical background and towards employing generalist managers, people who are in fact actively TRYING to remain non-technical, and believe that major software development projects should be managed in the abstract using general project management techniques.
For a while, I have been trying to argue against this policy, and several others have voiced concerns as well. But this single statement hit me like a cricket bat over the head.
If the ground doesn’t correspond to the map, then it’s the map that is wrong.
I don’t need to argue the view on a “first principles” or “logical” basis. I simply need to look at what is happening in the real world.
In other words, I need to stop focusing on the map and look at the ground.
You see, there are a few very clear indicators about the health of a software development project, and they can be measured reasonably easily. Those indicators are not universal, as every human endeavour is a trade-off between competing requirements. But for any given project, there is a specific range of settings on the various axes that we are aiming for, and we can usually gauge how we are tracking.
So if we are aiming for high quality, then we can look at defect rates. If speed of delivery is our focus, then we can look at function points delivered per time period. If we are looking at long term project sustainability, then developer satisfaction and retention rates (or, inversely, dissatisfaction and staff turnover) can be examined. If we are concerned with customer satisfaction, we can ask the customer for subjective or objective feedback.
If we look at what data we have “before” (that is, with technical managers) and “after” (with generalist managers), we can see which set of conditions moves us closer to our desired outcomes. And if one of them is significantly closer to the way we want to be, then all the arguments and logic about which management strategy is best become irrelevant. It’s like arguing about which map is more correct without looking at the ground. The correct answer can be determined quite unambiguously by comparing the maps to the ground.
Similarly, if we look at the health of the project, using whatever parameters we want to define health, under the two management styles, we should be able to discern which of the styles is better in this context.
Now, let me be the first to admit that this metric will only look at the relative performance of the particular individuals involved, and on the project under examination, and a single set of observations like this cannot be extrapolated safely to the broader project management landscape. However, I am really interested in just this one particular set of variables, so that’s perfectly OK.
I would be interested, however, in collating more information from a number of different projects that have tried both management types to see if there is any commonality. With enough separate data points, we might well be able to draw some generally applicable conclusions.
