Sad!
I worked for a company that tried to do a good thing for people's careers and promotion prospects, but it back-fired horribly and ended up hurting more than it helped. I'm going to tell you the story and draw some lessons from it. Of course, I've changed and obscured some details to protect the guilty.
(Sometimes doing the right thing badly can turn even placid software developers into a mob. Image source: Wikimedia Commons, License: Public Domain.) The company
The company was a large corporation with several hundred software developers working in different divisions on different projects. There was a formal grade level for developers: a developer fresh out of college might be level 20 and an experienced and senior developer might be level 30. Each level had a pay band with a rigid cap; once you reached the cap, you could only get more money by promotion. The pay bands overlapped and people knew them. Everyone was keenly aware of their level and there was open discussion of who was on what level.
The problem was, the standards and levels were inconsistent across and within departments. Some departments and managers were known to be 'generous' and others were known to be 'mean'. Some developers moved departments as the only way to get promoted, but there were problems with this approach too. Some departments had one set of rules for pay and levels, while others had different rules. In some cases, developers tried to move to other groups to get a promotion, but they were offered jobs at the bottom of the pay band at that level, which unfortunately was less money than they were currently on. Managerial inconsistencies had bad consequences for individuals too. In one case, a person got a big promotion and their manager left not long after. Their new manager felt they were underperforming and that they had been over-promoted. Some managers promoted based on performance alone, but others insisted on time served on a level.
The bottom line was, there were substantial inconsistencies and inequities and the software engineers were unhappy.
The learned organization
Fortunately, there was an active learned organization that helped software companies. One of the things this very learned organization did was produce career guidance, specifically, it produced a career hierarchy showing what software developers would be expected to do at different levels of seniority. As with all management solutions, it was a matrix. There were different skills in different areas and some areas were only applicable to more senior positions. To put it simply, they'd mapped out a grading structure and the skills and responsibilities of each grade.
On the face of it, this sounded like a perfect solution for my employer: why not roll out this grading structure and use it to decide people's levels?
The roll-out
My employer took the skills/grades matrix from the learned society and mapped it to the internal levels 20-30. The idea was, you could see what was expected of you at your level and what skills you needed to develop and the responsibilities you needed to take on to get a promotion. Sounds great!
They published this guidance to all developers.
Light the blue touch paper...
The fall-out
Here's what happened.
The people on high grades (around 30) knew they weren't going to be demoted and their salary wasn't going to go down. Most of them noticed that they weren't doing many of the things the skills/grades matrix said they should be doing. They found the whole thing hilarious. They openly joked about the grade/skills matrix and freely talked about all the things they weren't doing that the matrix said they should be.
The majority of people were on middling grades (23-27) and this was incendiary to them. Many of the people were doing more than what was expected of them at their grade level. In many cases, they were meeting the requirements two levels above their current level. The net results were urgent discussions with their managers about immediate promotions.
The middling grades people were furious, while the high-grade people were laughing about it. It wasn't a happy mix and management had to step in to stifle debate to calm people down.
Senior management soon realized this was explosive, so they backpedaled quickly. The roll-out program was canceled due to unexplained 'deficiencies in the process' and it 'not meeting business needs'. A review was promised, which as you might expect, never happened. The subject became taboo and senior management didn't attempt any further reform.
Of course, this had its impact. The middling grades realized they had to leave to get career advancement and the senior people realized further advancement was unlikely. The people with get up and go got up and left.
What about the people on the lower grades? When the roll-out happened, they were very happy. For the first time, they had clear goals for promotion, and consistency meant they wouldn't have to leave their group to get promoted. They were upset when it was canceled because it was back to the old opaque system. When the review never happened, it dawned on many of them that the company wasn't serious about their futures.
Instead of being a positive change for the future, it set the company back several years.
Why did it go so badly wrong?
Solving the wrong problem
What problem was senior management trying to solve? There were two broad problems we faced as a company:
- Current inequities and inconsistencies
- Future inequities and inconsistencies
The skill/grade matrix was a solution to the second problem, but not the first. The first problem was the most serious and the skills/grade matrix just made it more visible. The senior management team had no plan to address the first problem.
The leadership applied the right solution to the wrong problem.
Overnight fix to a long-standing problem
Inconsistencies had built up over the course of about a decade, and there were reasons why things developed the way they did. Partly, it was company culture.
As a general rule of thumb, entrenched problems take time to solve. Senior leadership plainly expected a magic wand, but that was never going to happen. They didn't put in enough effort post-launch to make the project successful.
Didn't listen/lack of inclusion
This was the main problem. Senior leadership should have talked to software developers to understand what their concerns really were. In short order, listening would have brought to the surface the issues with current inequities and it would have shown senior leadership that the plan wasn't going to work. The fact that developers weren't involved in discussions about their own future was telling.
Pretend it never happened
You can't put the genie back in the lamp. Senior management tried to brush the whole thing under the rug very quickly when it was apparent it was going wrong, which was the worst response they could have made.
How should they have dealt with it?
Hindsight is a wonderful thing, but knowing what I know now, here's how I would have dealt with this situation differently.
- Understand what the problem really is by talking to people. By people, I mean the people directly affected. I've learned never to rely on intermediaries who may be incentivized to mislead or tell you what you want to hear.
- Deal with the worst cases up-front and as one-offs. A one-size fits all process can flounder when dealing with outliers, so it's better to deal with the most extreme cases individually. In this case, people who should be on much higher levels.
- Trial the solution with a small group. Trying it on a group of about 20-30 software developers would have flushed out most of the problems.
- Stick with it. Put the effort in to make it work, but have clear criteria for exiting if it doesn't work.
More specifically, I might have followed these policies.
- Assuming no or very little money for promotions, I would have extended the pay bands at the bottom end. This would allow me to promote people without incurring extra costs. In the ideal world, you promote everyone who deserves it and give them the appropriate pay rise, but the ideal world doesn't exist.
- I might reform the whole 20-30 levels, for example, I might call the levels something else, and then I would map people to new levels, including mapping some people to higher levels. An exercise like this allows you to correct all kinds of oddities, but of course, some people will be upset.
- For people who were on higher levels than they should be, I would leave them there for a while. It's too damaging for an organization to make corrections on this scale - there were just too many people who were over-promoted. But I wouldn't promote these people further until their performance warranted it.
