![[TFEB]](../images/tfeb-blur-icon.gif){kind=icon}
The three errors described below originate with the same person, a manager. Two of the three originate in the same meeting. So why do they matter? Do they matter in fact? Why these three errors, rather than some other three?
It's naïve to think that management is simply a matter of getting a number of technical decisions correct - in fact it's naïve to think that almost anything is simply a matter of getting technical decisions correct. There are very many other aspects to being a good manager, or in fact to being good at almost anything.
But errors like these do matter. That there are important aspects of management which are not to do with being able to make rational decisions does not mean that the ability to make rational decisions doesn't matter: of course it does. If you can't make rational decisions then no amount of political skills will help you, or the people you manage. If you can't make rational decisions, then either you must trust others to do so for you (and how do you judge whether you can trust them?) or you're stuck with just guessing. Neither is really a very good choice.
Of course, it's impossible to understand all the details of a large organisation or project: delegation is another think that managers are meant to be good at. But without some degree of rationality, it's impossible to know whether the peopel to whom you are delegating are themselves making reasonable decisions. You just can't get away from needing to be able to make rational decisions. This shouldn't be surprising.
Why write about these three errors in particular? Well, they're quite an interesting set:
Between them, these three errors capture a good cross-section of mistakes that you don't want to find someone making.
A sunk cost is a cost that can't be recovered, or can't be recovered to any significant degree. Some examples:
The important thing about sunk costs is that there is nothing that can be done about them: whatever decisions are made in the future, the sunk cost will not change. In turn this means that the sunk cost should not affect any decisions.
This is actually fairly counterintuitive: for instance, imagine you're working for a company which has bought a large inventory of machine tools: surely it doesn't make sense to ignore all that and decide to be an ecommerce company instead? Well, probably it doesn't, no. But the reason it doesn't make sense isn't because someone thought it would be a good idea to buy all those machine tools last month, it's because it will be more profitable in the future to make use of them rather than to write them off or try and resell them. All that matters is what will happen in the future, because decisions can only alter the future.
The sunk cost fallacy, also known as the Concorde effect, is to take sunk costs into account when making decisons. The classic example is, of course, Concorde. Concorde was developed in the 1960s at great expense. Quite late in the process, it became clear that there would be far fewer orders for the aicraft than expected. It was clear that the aircraft would never make money, and that less money would be lost by cancelling the project as soon as possible, thus reducing the amount of additional money that would need to be thrown at it. This wasn't done. It's easy to put yourself in the position of the decision makers.
But we've spent all this money now, we can't just waste it! And people will laugh at us if we cancel it, won't they? Let's just carry on, that will be easier.
Well, yes: you have indeeed spent a lot of money, but nothing you can do will make that not be true. And you will waste less money by cancelling the project than by blundering on.
Or take this example. Company x has spent a large amount of money on some machines to replace its existing database servers, which are nearing capacity. This is a large amount of the money they have to spend this year, and it will take more than all the man hours they have to commission them before the deadline. Except, in fact, it turns out that the existing machines are not actually running out of performance, and certainly not before the deadline. But there are some other services which are running on unsupported and inadequate hardware, and which pose a huge risk. Given the available resource, especially the available human resource, it would be far better to fix that problem. And the same machines can be used, even if they're not ideal for the new role. But no, it turns out that `the business case has been made' and the money has been spent for the database upgrade, so that's what will be done.
This error is about three things:
It is also a depressingly common error: I think the fear of losing face is a significant reason for this.
It's slightly embarrassing to have to describe this: surely everyone has read the book? Clearly not, and perhaps many of those who have read it have not understood it fully.
A traditional approach to describing the amount of effort required to do something is in terms of man-months - the amount of work one person (obviously this is an old definition) can do in a month. The assumption is that a given task requires a certain amount of effort - a certain number of man-months - and that this effort can be supplied either by few people for many months or by more people for fewer months. This is a good approach, because man-months correspond closely to salary cost. And for a lot of things it works reasonably well: if you have three hundred houses to build, and a house takes a person a year to build, then clearly you can employ one person for three hundred years, or three hundred people for a year, for approximately the same result. And you can mix and match during the project - if you decide that you want the houses completed sooner than you previously estimated, then you can hire some more people, and things will happen sooner. The number of man-months you need is a constant of the project - in this case 3,600.
But this is only nearly true. When, part-way through the project, you decide you need to hire a lot more people to make things happen more quickly, some of the existing people will need to spend time showing the new people the ropes. So some small number of man-months will get spent on that instead of getting useful work done, with the end result that you'll need slightly more man-months overall than the original estimate. And when the number of people involved is large you'll start to need to spend time coordinating things so that supplies go to the right place, houses don't overlap, and so on. So in fact the number of man-months isn't quite a constant of the project.
Now consider a substantial programming project. Let's say you have 5 people working on it, and they're going to take 2 years. So you estimate that the project is taking about 10 man-years, or 120 man-months. But you need it done in 6 months, so you hire another 15 people - 20 people do 120 man-months worth of work in 6 months, after all.
And, of course, this doesn't work. It doesn't work for two basic reasons.
The end result is well-known: throwing people at a programming project often has catastrophic consequences. What is perhaps not so well-known is that this isn't because of anything particularly special about programming: it applies to any domain where there is a lot of project-specific knowledge (causing large training overheads) and a lot of communication (causing scaling issues). System management is such a domain, for instance.
The problem here is to do with metrics. One sense of this term is some number that measures how `hard' or how `big' something is. People suffering from physics envy like metrics because it makes them feel like they're doing proper science. Managers love metrics because they make them feel in control, and if the metric corresponds to cost then it allows them to estimate how much projects will cost.
But metrics are only useful if they are, well, metrics: if they measure something. If they don't measure anything interesting, then they're not useful. Here are a couple of `metrics' which are used for software projects.
Well, none of this should be news. What is astonishing is that there are managers who still - more than 30 years after the book which described why man-months are not a useful measure for software projects - can say that simply throwing people at a project which is late will fix things. How do these people keep their jobs?
Imagine a service organisation which is handling trouble tickets in the normal way. If all is well, then tickets will be getting handled in good time, clients will be happy, and the people working for the service organisation won't be too overworked. But all is not well: there is too much to do, there is historical chaos which no one knows how to fix, there are deadlines that can't be met and so on. Tickets aren't getting resolved promptly, or at all.
What do you do about this situation? Well, you could decide that as organisations that are working well handle tickets promptly, you will assess people on how quickly they close tickets. This will fix the problem, of course. Or perhaps it won't.
This is a simple logical error: if A implies B, then it is not the case that B implies A. what is the case is that not B implies not A. In this case, what you know is that if all is well, then tickets will get closed in good time. So what you also know is that if tickets are not getting closed in good time, then all is not well. What you don't know is whether tickets are getting closed means that all is well, and in particular you can't force all to be well by forcing people to close tickets in good time (which is what assessing people on how quickly they close tickets will do). What is much more likely is that you'll cause your staff to close tickets when the problem isn't actually fixed (because they can't fix the problem, since everything is so screwed up) thus causing clients to get upset. And you'll also cause staff to get depressed and leave, making the problem worse as the organisation leaks experience.
Another way of thinking about this is in terms of symptoms and causes: how promptly tickets are closed is a symptom, not a cause, and treating it does nothing at all about the cause, and may actually make it worse as people devote more time to closing tickets and less to fixing the underlying problem. There are times when treating symptoms is appropriate: if there is nothing that can be done about the cause for instance. When a patient has terminal cancer, then treating the symptoms will make things better for them in the time they have left. The same may be true for the service organisation - treating the symptom might make things look better in the few months before it all collapses under its own weight. Or perhaps it will make things look better for long enough for the manager to move on and stop having to care.
What is disturbing about this error is what it implies about the person making it. There are a few possibilities.
The truth is probably some combination of these three. In any case, it's very hard to think of a reason for behaviour like this which reflects well on the manager concerned, or bodes well for the organisation which they manage.
It would be easy to say `well, you're dealing with a PHB, what do you expect?'. But that's not answering the question: why are managers like this? and what can be done about the problem, if anything?
One answer to that is `they're stupid' (perhaps this another version of the PHB answer). I don't believe this, or I would like not to, anyway. A better explanation, I think, is that education is failing people: they are not being taught how to think. The typical business environment doesn't help: if you have too much to do, it's much easier to rush around feeling good about being so busy than to try and spend time thinking about what you're actually meant to be doing. Finally, being rational involves changing your mind when the information available to you changes, or perhaps just when you've had more time to think, and people don't like admitting they were wrong, because they are frightened of losing status in the pack.
None of this answers the question: what is to be done? I don't know. I think the best hope in the long term is natural selection: companies who employ people who can manage rational thought should do better than those that don't, because they will make better decisions. However I am not very optimistic.