Software Engineer Performance Review are a Paradox

Performance reviews, which the company or managers may strongly depend on at the time of personnel work, so do the software engineer when contributing to the team, plays a big role in the operation of the organization.

The meanings behind are attention and visibility, which largely determines the direction of an organization.

As we all know, it is a critical but tricky task, and often out of order even though the criteria were totally designed according to the goals, doubtful personnel decisions and employees resentment are heard from time to time.

However, the above is not unique to software engineers but is much more serious than others, the issue is worth an in-depth discussion for us in the industry.

The "Engineering"

How is the nature of software engineering work different from others?

This might be a suitable entry point to explore the malfunction of performance review, and a remarkable fact is, the degree to which software engineers work together, or more precisely, affect each other, including assistance and drag, far exceeds that of most other.

Blind Spots in Performance Reviews

Surgeons take responsibility for their patients, lawyers individually assist their clients, and technicians focus on their position on the production line. Which can cut out objective boundaries on the business content of different people in most cases.

Unlike other independent contributors, software engineers are severely subject to the output of others, especially in the companies that continue to develop their own products. While in those environments, we...

• Maintain a shared codebase.Write/modify code based on a massive amount of code written by others, and must make sure not to break them.

  
  

• Use the same internal system. Integrate with many components or services maintained by others, and must make sure the interaction is as expected.

  
  

• Take over ancient heritages. Diagnose the algorithm or architecture designed by others, and must figure out root causes and come up with effective solutions.

  
  

As you can see, daily work is heavily affected by others, and vice versa. Someone who performs disappointingly could be due to the obstruction of flawed design, which might delivered by a well-performed guy just a quarter before.

Another obvious fact is software engineers clamoring all day long to ask for resources on refactoring, but we rarely heard from surgeons asking to refactor the consultation process.

That is because simple and repetitive things like number calling, picking up the drugs, and being hospitalized can be easily standardized, and the different ways of diagnosis and tool usage of different surgeons hardly affect each other.

But software engineers are not so lucky, a seemingly perfect design at the moment may become a harmful legacy due to the evolution of time, and even the coding style can lead to countless debates.

We expect a qualified engineer to be independent and efficient, thus endowing trust and decision-making authority, but also depriving standards and discipline of the entire team and shared codebase.

It could be taken as an extreme case of serious external effects from an economic point of view, the reason why it did not cause the tragedy of commons right away is because of a sense of morality and persistence in the engineering profession.

However, it is neither endurance nor reliable, a long-term solution has to be proposed from a management perspective.

Since the tasks are highly correlated to the current status of the existing system instead of the feature/bug itself, making the size or scope of them become dominated during performance review seems even more ridiculous.

Debt

Gain market share or contract with deep discounts or offers should be strictly scrutinized, right? Because it is equivalent to sacrificing future profits or increasing future costs for the immediate goals, or in a better-known term, debt.

We all expect the benefits of the debt can outweigh its negative impact during decision making, statistical references are used to be adopted on the business side. Although it may not accurate enough but still helpful.

Then how about the engineering side? We can hardly quantify metrics like development efficiency, service stability, communication cost, etc. In a culture where deadlines, overtime, and on-call policies are used as common solutions, these hard-to-measure costs are almost completely ignored.

If we are serious about the behavior of diverting next quarter's budget to improve the performance of this quarter, how can we turn a blind eye to the maintenance cost and potential risks but pay undivided attention to the feature delivery?

Assessments that overemphasize personal short-term value delivery are easier to be out of order or be hacked than we think, cost and debt can be passed on at will in the close collaboration of software engineering, to the customers, their teammates, or the employees in the future.

Imagine that everyone tends to highlight temporary and one-sided results, all the debt is hidden, deferred, or never considered, just like cooking the books.

KPI / OKR Hackers

The nature of external effects is that the profit and cost can not be returned to the perpetrator, resulting in economic losses and being out of order in advance, and the same is true for performance reviewing.

• If the KPI / OKR only focuses on releasing the feature this season, engineers have no reason to care about the side effect to others and the potential problem of flawed implementation in the future.

  
  

• If the KPI / OKR has no word about the efficiency of the whole team, engineers have no reason to deal with the legacies or automate some processes, it is not rewarding after all.

The fact above is an ideal hotbed that nourishes KPI / OKR hackers, who perform excellently on the review but actually the negative equity of the team (a.k.a 0.1x engineer).

For the sake of the overall situation, others always invest extra efforts to clean up their mess, but they rarely feedback to the team. If the company responds to the anticipation of the hackers, a negative cycle of reverse elimination was promoted.

You may think it is not that serious, or it should be discussed widely in the past. Indeed, the tragedy of commons has not flourished on a large scale before, but the rapid transformation in the software industry may cause critical changes.

Oversupply of Software Vacancies

While the bargaining power of software engineers keeps rising, the quality of the candidates is not the same. Especially in the job market of entry and intermediate level, under-qualified candidates can crack the companies' hiring process perfectly through the help of Bootcamp.

Juniors produce more side effects and flawed implementation due to less experience and capability. But the seniors tend to look for better offers instead of enduring silently and doing volunteer work, asking them to work overtime or be on-call can lead to job-hopping easily.

Job Hopping at a Faster Pace

For the newcomers who plan to resign about a year later, they do not really need to do long-term planning or take full responsibility for their work. Just make it usable in a short term, since the future bugs, risks, and inconveniences will not be borne by themselves.

Society Increasingly Promotes a Successful Career

In my opinion, the first two points are originally driven by this.

While searching about "software engineer" on the browser, instead of the discussion of skills and knowledge, results are full of transferring, interviews, and promotions.

Due to the hype of media, more and more people take the glamorous software engineer as their career goal.

In this culture, most people put performance reviews first and ask for a promotion, nobody cares about the sense of morality and persistence in the engineering profession which is out of the scope of the evaluation.

However, it is not the employees' fault, to follow the rule and fighting for their careers are totally acceptable, abstract and consensus-lacking ethics should not be applied to a formal assessment. What needs to be revamped is the management.

Directions

Not the solutions, but some directions worth a try.

Take into Account the System-wide impacts and Long-term effects concretely

The sad fact is that hard-working team players tend to contribute silently, while KPI / OKR hackers keep harvesting and strive for visibility.

A well-established approach is to empower first-line managers to score, leveraging their technical knowledge and observation to avoid overly skewed assessments. It takes effects sometimes.

As far as the engineers were concerned, some specific items on the performance review are highly anticipated, better than verbal affirmation, or an overall rating in which the team-wide contribution is only one of the factors.

It is a good time to make the system-wide impact and long-term effects become independent metrics, rather than an additional note under feature development. After all, no one wants their own software system can never grow again.

Risk Disclosure

The root cause of the negligence to non-immediate engineering issues is not the low importance, it might be the lack of quantification and visualization.

The attention can be rebalanced if solid numbers are provided, and a vast amount of chronics turn over to be practical and predictable disasters. Including but not limited to...

• The unscalable design can not carry 20% more users than the current volume, the tipping point is expected to be hit next quarter.

  
  

• The fragile implementation can cause fatal errors if the user operates too fast, which can lead to 5% of users deleting our app.

Of course, it is almost impossible to give these statements, but the idea of presenting information is the same.

Risk disclosure is not so out of reach, many widely adopted engineering methods have similar effects, such as...

Code Review

An artificial version of "early detection and treatment". The commits can be reviewed and challenged even without any observable bugs (if no CI pipeline is integrated).

Authors have to answer the concerns of others in order to get approved, which makes them take full responsibility for the content. Make sure there are no obvious flaws, consider future maintenance or their image will be damaged.

Write Tests

Various tests give us intuitional feedback on the commits, hardly anyone can bear to release a buggy app before fixing it.

All the things test cases do for you is let everyone witness the predictable disaster and not be willing to make it come true by hand.

For those who get used to not writing tests or feel repulsive about it, communication surely needs time. Even so, wider negative impacts should still be guarded against, techniques like test coverage checking within the CI pipeline helps.

Although exposing the flaws in the work of others sometimes makes them feel uncomfortable, the team has to face the music eventually. It takes time.

Try to shape it as treasure hunting instead of a witch-hunting, replacing shame with accomplishment, this can encourage the author to benchmark or write tests for their outputs.

Epilogue

Some of the stuff above may look like complaints about a bad career, but I believe these are the annoyance of many frontline contributors.

In fact, I've also tried putting more effort into reaping the results and striving for exposure, the effect is naturally significant, but it does not mean I'm really that prominent.

Wish the experience sharing contributes to the industry and has a chance to inspire the careers of some readers like you.

Also published here:https://softengineer.ghost.io/paradoxes-of-perf-review/