When I was introduced by the management by objectives during my first working day in one of the companies I worked as the project manager I was impressed – I was so keen on measuring and controlling everything. “It was something I read about in management books and now I will see how it works in the real life!” – that is how I was thinking. Guys told me that they successfully used MBO for all the departments, so I expected the great results in the next quarter…But smth went wrong. We tried to adjust and redefine the objectives next quarter, but it seemed impossible to win this game – each time we redefined the objectives the system and people somehow could hack it and we just could not keep up with that speed of “hacking” – our suggestions were not good enough each time.
Real life example
Let me give you some example first. As the manager in this outsourcing software development company I had the following measurement of my multiple projects success: the average level of the hour profitability – the relation of the hourly rate paid by client and the cost of that hour for the company. Yes, it was an outsourcing company and we sold development hours to our clients (let’s be honest, outsourcing companies sell you hours, development services, not “great working software”). Great measurement, which intended to make the whole thing more profitable.
But what was the result? As the manager I could not influence the hourly rate we billed to the client, but I could influence the second number – the costs. As the major part of it was the developer’s salary, the most effective strategy was to reduce the average salary in my teams. Your current developers probably won’t like if you reduce their salary, so managers try to hire the new developers as cheap as possible.
“Skills? Never heard of that! Does he have the words “Java Script” in the CV? Hire him!” Of course, tech interview with the client made the whole thing more difficult. So managers had to balance the salary level and the “client technical acceptance”. But is you could push a Junior as the Senior you could be a hero. Here is the great joke which was popular some time ago:
Of course, things were not so bad) But we liked jokes.
I remember how we didn’t hire some cool developers because their salary could drop the manager’s numbers that quarter. We also faced one more issue – recruiters had the goal that made a great conflict with the manager’s – hire more people. It was their objective. But managers tried to set so low salaries for the positions that it was not possible to find the candidates for that positions. Also managers rejected some candidates with the salary which was “a bit higher than average”, even if they were a perfect match. So managers were in a great fight with recruiters.
The other was to cut the costs is was to reduce any activities which required financing from the company. So managers did that too.
In the end of the quarter it was obvious for everyone that goals or measurements are not correct. We tell our client’s that we develop the high quality products for them but there is nothing about that in our objectives. Also developers are not very happy with the cutting costs. But there is nothing in our objectives about that too. So what the management did? Yes, they added measurements. One for the number of the gone developers (as we had more developers going from us that quarter) and one for client’s satisfaction.
For me it looked like having the control panel with the parameters that are completely opposite – when you increase one the other drops down. We even counted with managers that for us it is not good to make the teams bigger – when team becomes bigger the parameter “profitability drops” (the dividing line was somewhere about 20 people and it was connected to the specific conditions of our contracts with clients).
And these issues continued and continued to emerge, not better how fast they were fixed in the “objectives” system.
Of course, managers were not just blind robots and we quickly understood that, for example, hiring only cheap developers will kill our teams, so we started pointing less attention to that numbers – it was just impossible to fit all the criteria.
My thoughts on that
I think the main reason why the management of objective fails is that the world is much more complex than the several parameters you are going to measure. When you start measuring some parameter – you give it the max priority and all others start to suffer. It seems that you never can find the perfect balance. You want to be rich and healthy at the same time.
Ideally the progress toward each of the objectives should mean the progress toward the overall company goals, like growth and profitability. So the simple combination of this objectives for each department or even position sums up in the company success. But the issue is that the system to which we apply these objectives is not stable, it is not “static” with only these parameters to change – it is highly dynamic. You need something stable to base your objectives target on.
The objective itself is a very primitive approximation of the very complex system. So when we try to increase measurement A other parameters (measured or not, but important for the business) can drop. The simplest example of it can be that we can start developing “faster” but with the lover quality and with much more bugs. It seems obvious, and looks like just the bad implementation of the management by objectives. But I think that even if you start adding/changing/tweaking/adjusting the objectives – you get the completely “frozen” system, where “everything” what can be changed is regulated and this system just can’t move or still have some drop-outs.
May be my experience with MBO just was not very successful, but I think that nevertheless how smart you are – you can’t describe an infinitely complex system with the countable number of parameters.
6 thoughts on “What Is Wrong With Management By Objectives?”
Isn’t it a problem of defining what’s an “objective”? To me, in your example it sounds like a parameter has been mistaken for an objective. You’re totally right with the fact that it’s extremely difficult to balance quality, speed, and costs. And if you set two out of the 3, then the third one won’t be able to change much. Probably that the right objectives would more resemble “Let’s increase our revenues by 30% on next quarter”, within acceptable boundaries of (X,Y,Z) on (quality, speed, costs). Then you can play around with X,Y,Z at each quarter and see how it contributes to reaching your objective.
Now MBO is probably not enough, as it’s only looking at part of the problem, and as you mentioned, rarely applies cross-departments in your company. Ever heard of G.O.S.P.A.? I just did actually, but it seems pretty interesting, and I’ll definitely dig into it.
You are 100% right that the problem is in defining “objective”. Apart from quality, speed and cost we also have a “team health” and smth like “staff turnover”, as for the outsourcing business the team is the thing that we sell (their working hours).
Never heard of G.O.S.P.A. before, thank you for pointing that out to me! Will study the topic now. Seems that it is a great planning tool and includes “objectives” into it.
I am not the experienced non-project manager, as all my time I worked with projects only, where it was simple to define “success”) So I described how it looked like for the team of project managers. For me it is a terra incognita.
I’m sure there’s a positive way to apply MBO. Yes, most systems are complex, but it just means that solutions must be complex too.
Let’s imagine that your goal as a company owner is stable or growing net profit. You can choose an easy way and link everybody’s bonuses on net profit. It will make your developers frustrated if they work hard while getting lower bonuses because of some factors they can’t influence on.
Or you can split your goal into the list of sub-goals. And if sub-goals are yet complex – split them again. In this case your developers might get objectives like “Learn about new platform and create a working example using it”, “Share knowledge with at least 5 colleagues”, or even “Walk 10 000 steps a day”.
I agree that in my example the objectives were too general, but management tried hard to adjust the objectives system and align them with the overall company goals (profit). The case is that when you create smth like “Learn about new platform and create a working example using it” you think that it will push your goal “profit” up, but the backward connection can be not so easy to see. So it’s just your prediction and you have to prove it. To prove it you have to frozen the system and vary just this parameter (or the cause and effect become not obvious). But you can’t frozen the system and when you see the overal goal “profit” fall – can you predict what was the reason? How can you guarantee the sum of the objectives you created (the small ones, like “Share knowledge with at least 5 colleagues”) will sum up in the “profit” growth? You start tweaking here and there, but for me it seems the endless battle.
There should be some other way…
Galina, great article, and thanks for inspiring me to write about MBO over at my blog. I think I agree with you the more I think about it. It is only a part of being successful, and a small part at that.
I tend to disagree that profit is the goal however, as it is just one measure of success. Amazon for example makes almost no profit, as it is still concentrating on growing its customer base. As a side-effect, it is destroying its competitors who were more intent on draining more and more value away from their customers and growing profits for their shareholders. If your objectives are not maximising value for your customers, then someone will find a way to serve them better.
MBO is just a tool to implement the right strategy. If the strategy is weak, then all MBO will do is make you fail more quickly.