The Primary Concern

No matter how hard or efficiently I work, everyone’s salary and promotional schedule move at the same rate. After 7 years of “exceeds expectations” reviews I found myself no further ahead (in engineering level) of those who were getting “meets requirements” or even “needs improvement”. Since salary is tied to engineering level, I assume I was only slightly ahead of the curve if at all. It basically worked like an engineers union; everything is based on seniority and not quality of work. The higher on the engineering scale you climb, the more pronounced it becomes.

I’m operating under the assumption that most people want to advance their career in some way. I’ll call these people Group A. I know many people who don’t, and this union-like environment is not a problem for them. These people are content with having a decent job and the challenges it provides – I’ll call these people Group B. I’m not knocking the Group Bs, it’s a fine way to live – I’m just not one of them. For those of us interested in having a meaningful career filled with different challenges and opportunities, this paradigm is not acceptable.

I can’t function effectively in these environments. Invariably, what I’ve seen with people from Group A that do not move away from the large company is one of two things:

1. They put it in neutral and coast through their career OR
2. They move around within incessantly, looking for spots to move up and grind out an extra one or two engineering levels before calling it quits

My decision to leave was based on this observation. I could never be happy putting it in neutral. I enjoy and take pride in my work and if it ever gets to the point where I feel like I’m not challenged or don’t care I will change roles/careers. I’m also a firm believer that working hard, being efficient and innovating should be rewarded. Too often I found that raises and promotions are based on things that don’t have anything to do with the quality of your work. Things like filling out your timecard every day, completing the mandatory number of hours of training courses, etc were valued at the same level as your actual output.

The union mentality does not sufficiently reward the knowledge worker

The Result

After spending a couple years at a small company I can say that despite having my doubts about making this change, these problems have been addressed. In a small company it’s easy to tell who is productive and who isn’t. The health of the company depends on employees being productive, efficient and innovative. It is therefore in the company’s best interest to reward this behavior to stay healthy. There are far fewer rules about who receives what rating and raise during reviews, no quotas, no caps. The only question asked is whether investing in this employee is going to help the company. Smaller companies do have downsides that should be noted, the largest being that they are prone to instability, but having some effect on the bottom line is incredibly motivating and exciting.

A Word on Software Measurement

Every company wants to be efficient and having measurable output is incredibly valuable in determining how efficient an organization is. The challenge is to figure out how to measure output. In larger organizations, top-down one-size-fits-all initiatives to make it easy to measure output make logical sense. I seriously doubt the company I worked for had very many software developers making decisions about these initiatives. The largest measurable output we dealt with was the SLOC, or Standard Lines Of Code. After all, the more code being written, the more productive you are.

This is of course laughable to any software engineer. It was incredibly discouraging to see how many hours were wasted finding ways to count the lines of code being produced. Formulas did not account for the language the code was written in, or the quality of the code, just the lines. If a top-down initiative resulted in more lines of code, it was a success. Software is incredibly difficult to measure as an output. In a widget factory, it’s easy to measure the number of widgets produced and determine efficiency. This is a horrific mistake in software. Even if it were possible to measure software output, the field is constantly changing; new frameworks and libraries are constantly being introduced, more efficient languages and compilers, etc. Even if a way to measure software efficiently was invented for the current state of the world, it would immediately become obsolete. Please stop trying.

I also believe that the amount of possible innovation is inversely related to the amount of formal process required. We saw this happen at 3M. For some large companies, including the one I worked for, innovation is not important. It’s also incredibly boring from an engineering standpoint. Engineers like to innovate and solve problems, it’s what drives them. Engineers should not be tied down with formal process.

If you want to run efficiently, spend lots of time choosing your leadership and management teams all the way down the ladder and trust them to handle it. Using an agile development process helps tremendously. You see daily output and quickly get a grasp of who is performing. Constant communication of goals and priorities also ensures everyone is working on the right things.