I’ve been on both sides of this morbid practice with several different organizations at this point. The similarities are striking everywhere I’ve been. The process usually goes something like this:
- Set “goals” starting at the top of the organization
- Make those goals more specific as you move down the org chart
- For each individual
- Make sure that there’s awareness that financial incentives rest on meeting this
- Ostensibly allow for modifications to goals throughout the year
- At the end of the year (and sometimes throughout the year)
- “Calibrate” performance across all disciplines and parts of the organization
- Use the goals starting at the leaf nodes and working up to the top of the org as the baseline
- Individual managers rate their employees, but are held to the calibration done by the larger management team. And the calibration is typically used to formulate a stack rank – a bell curve of performance that must be fit
As I noted above – there has been remarkable consistency in the different organizations I’ve been a part of with regards to the thinking about and implementation of this process. I have to assume that there’s a common source of knowledge that leads to this – simply because the coincidence is a bit too stark. Though, I am unaware of what the source is.
There are a lot of similarities, both in the form and the results of the practice between this system and the software development approach commonly known as Waterfall. And as with Waterfall, I would concede that on the surface, it’s intuitively very appealing. And I can imagine a lot of scenarios where it may be a very helpful technique.
Software Development is not one of these scenarios.
It cannot be, due to its nature. I will do my best here to spell this out specifically for software development, though I imagine that the arguments apply equally to any information work.
Software development is a learning activity. It tends to get conflated in the popular mind with the act of typing in a computer program (“coding”). The act of actually entering the code is the least time consuming, least important part of developing software to meet a human need.
Understanding the problem space and the logical bounds that must be worked within, and how one might put the two together and model the specific solution is the bulk of the work. Because of our cognitive limitations, that will always involve entering some code, seeing how well it serves the problem, and how clearly it reflects a model of the problem, fixing whatever we weren’t able to get right the first time and trying again.
That is, software development is always experimental, and the real value that is created as a part of that experimentation is learning; learning that is reflected in the individual, and in the organization, and also in the software code itself.
The appeal of the system laid out above is two-fold. And it is based on some undoubtedly real needs.
Appeal #1: Organizational Leaders want to be able to set direction. That is – at every level the management team has a real desire to be able to feel comfortable that they’re driving the people working for them in a direction that is consistent with the direction that has been laid out for them. The filtering down, with further specification of goals is a neat, clean way to do this, that almost seems to remove the messy human stuff from the system.
Appeal #2: Organizational Leaders want to have the sense that the organization that is accountable to them is moving with urgency and with an appropriate amount of energy. The financial awards system is seen as the carrot that can be consistently applied, again in a neat and clean way that removes as much controversy as possible.
Again, both of these appeals come from genuinely important functions of authentic leadership – to provide direction, and to generate the collective energy to get there.
Seeing the set of problems here requires some Systems Thinking. I’d recommend (re-)reading Senge’s seminal work on the topic “The 5th Discipline“.
Problem #1: The Impossibility of Planning Software – Anyone who has worked in software for more than a day has come to realize with the rest of the industry, that predicting precisely what software we will be working on even as little as a couple of weeks out into the future is close to impossible. Unless there is an extensive artificial structure in place to prevent it – the software you build today (again, because software development is primarily learning) informs the software you build tomorrow; tomorrow’s software affects that of the next day, etc. The uncertainty multiplies the further you get into the future. This is why Agile has emerged from the software development world. The only way to build software that really meets needs is to try something and adjust.
If as a software developer I predicted what software I would be working on just 6 months into the future, even in the broadest terms, I would need to adjust many times over. That adjustment would need to be fed back into the goals that had come down, potentially adjusting those with the learning that has occurred, disrupting a ton of work that was done by a ton of folks to figure out what those goals were in the first place. And almost precisely like the Waterfall methodology – the force of this inertia makes this a practical impossibility.
Practically what happens is that the goals that an individual software developer writes has nothing to do with the actual software they’re writing, so that any changes won’t be disruptive to the larger system. Which, in case it’s not obvious, completely blows away the usefulness of this tool as a mechanism for setting direction.
Problem #2: Individual Focus – the goals for a specific individual are always, almost as a logical extension of the system, formulated only between the individual and their immediate supervisor. This means that teams aren’t being built around the things that their members are ostensibly working toward; because one team member is fully unaware of what any other team member is most interested in accomplishing. And because of this it is almost impossible to not send the message that how someone performs as an individual is the key expectation from the leadership team. This was heartbreaking as a software development manager, because no matter how hard I would focus on building a team, the system wouldn’t have it.
Problem #3: Motivation – One of the primary appeals of this system is that it gives a nice, clean way “to motivate people”. Attach money to whatever it is you want people to do, and voila, problem solved – people will produce whatever you want. This betrays a couple deep misunderstandings of human nature. Firstly, money is not a real motivator – people will be anxious to make more money until they feel they are being paid fairly (to which, accomplishing more things is only one solution – leaving is another). Secondly, it presumes the organization to take on the initiative to motivate someone. People can be demotivated by others, but naturally we want to accomplish – we want to make a difference. Ironically, attempting to bribe someone into doing more is really introducing a significant demotivating factor.
This is multiplied when the things that are being incentivized by financial pressure are unrelated to the work that they are primarily interested in doing (an unfortunate outcome of Problem #1).
Problem #4: Manager Bottleneck – Unlike in prior times or in other types of work, in information work, the doers possess the specific knowledge required to make something happen. There is no way that a single individual would be able to possess a team’s worth of knowledge about a particular piece of software that is to be delivered. Yet if the manager is expected to drive the team in a particular direction using the goals as his steering wheel, it requires that he know exactly what every single job requires, and how to execute it. And further, if he or she is not actively directing the work, because their goals will be tied to the execution of the goals of those under them, they will have a powerful pressure on them to review the output of their reports.
This is absolutely antithetical to a strong software delivery team, where the full team shares the knowledge and responsibility necessary to deliver software. And it makes the software development manager a bottleneck to delivery. Which, in addition to being a major limitation on all but the most junior teams, means that there will be wide variance from team to team based solely on the manager’s skill level. (And none of this accounts for the burnout that will be the manager’s lot for being put in this kind of a situation)
Further, any technological innovation, process improvements, or other enhancements that the team is interested in doing to the way it works all require up-front planning with the manager, since it will have to fit in as a part of goals. Which means, that instead of being group exercises, they are necessarily top-down driven initiatives that will rise or fall on the manager’s say rather than on the collective voice of those doing the work.
Problem #4 is probably the most dire. But like Problem #1, the vent that usually lets the pressure off is that the actual goals are placed on things that are less relevant and less important than the actual software that is being delivered. And since there is more and more pressure adding up to this end, less and less value gets placed on the usefulness of the tool. And ultimately ….
The Ultimate Outcome
Because the upper levels of management create a system that actively necessitates avoidance, reduces its own value in the eyes of those using it, while creating an illusion of control and motivation, the resulting cynicism should be unsurprising.
I’m a firm believer that you shouldn’t whine about a problem without pointing to the solution.
The solution here is to – and I steal from Jim Collins here – recognize that there are no silver bullets in leading an organization. Directing people toward a common goal is a messy, human situation that requires a deep commitment to communicating unceasingly, to really understanding your business and the way the people fit into it. And most importantly it requires a deep understanding of how software delivery (and really information work) differs from the old style of work that didn’t fall apart as readily under a heavy top-down hand.
- Fully eliminate this idea (Performance Review) from any part of your organization that engages in software delivery.
- To meet the direction needs, re-evaluate the role of the software development leader. Make it their role to work on the system – to formulate a delivery practice based on agile principles.
- Re-evaluate the manager to staff ratio. The software development manager should have almost nothing to do with the specific software and everything to do with creating a healthy system. Because of this the number of staff reporting to a single manager can be far higher.
- With this decreased need for management, flatten your organization – eliminate as many intermediate layers of management as possible, so that top leaders can be more readily in contact with doers. So that feedback can REALLY flow back up to the leaders making the strategic decisions.
- Take all that money you’re saving – and really pay the doers what they are worth.
None of this is particularly exciting – especially because it involves a lot of communication. Something, that if we asked people how they really feel, they might opine that it is not productive – know that it is.
It also eliminates a lot of positions of authority. Authority is a thing that can attract some people. Though, I would argue that it attracts the wrong kind of people.
Organizing like this will do nothing but lead to better software, happier people, and much more value being delivered to the world we serve.