Remove the promotion panel out of promotion

9 min readMar 2, 2018

A soliloquy inspired by Michael Lynch’s blog on “Why I quit Google”. Before you read this blog, i suggest you read what Michael wrote in his blog.

Promotion system is broken.

Anyone who has worked in a tech company long enough to target the next promotion successfully or not, knows this. The number of upvotes and comments received on the post “Why I quit Google” on Hacker News is a clear validation of how much people in tech industry resonate to this hypothesis.

Promotion process is typically opaque. It does not always align with engineering goals and involves a prerequisite of compiling some sort of a promo-package before the panel. Unfortunately, most of the savants of the industry have relied on such a mechanism, maybe because it just works. But change is the only constant in the universe. Therefore, what if we can rethink a system which eliminates all of this. A system which inspires trust such that a person higher up the ladder is certainly better in terms of his contributions to the company.

This blog post is aimed at exploring the possibility of an alternative framework. I have been always fascinated by Gamification and reputation system, typically one used by Stackoverflow and I believe the concepts can be applied within organization as well. Stackoverflow uses gamification to ensure high quality content and moderation on its platform. Therefore it should possible to apply the same concepts to human resource management in an offline setting. First, let us start by analyzing the article written by Michael Lynch and consolidate what is wrong with the current promotion process in companies.

1. Lack of growth metrics.

Michael shares in the post that in the first two years he loved Google, got great ratings and was assured that he would get promoted eventually. However, the first rejection came up as a surprise. This continued and he faced multiple tussles later on. This means that the process to evaluate the employee’s work each year does not correlate to how close he is to promotion. Michael “believed” that “Strongly Exceeds Expectations” rating was bringing him closer to promotion but there were no numbers to show that. This is counter intuitive. On one hand the company told him during the annual review that he is doing great work, but during the promotion cycle the same company tells him that none of his work matters. #BreakPoint1

2. High bias on business impact over engineering quality.

Michael mention in that he did several challenging engineering tasks which others in the organization were reluctant to pick up. Adding integration testing, optimizing code for better performance or scaling up a broken component should be considered as high quality engineering tasks. However the promotion panel was mostly considered about “launching new features” or in other terms, business impact. This again feels counter intuitive. Does the company expect a senior software engineer to be someone who write great code and designs complex systems or someone who has has been lucky to work on things that bring business impact? #Breakpoint2

3. Outsourcing promotion to third party

Michael talked about that the team he works with gets no vote in the promotion process. While this sounds reasonably fair, this introduces unfair advantage to the dimension of presentation which he comically calls the “promo-package”. Because the promotion case is being reviewed by an independent panel, an effort is required to polish one’s work in gold and silver to make it shine. Taking from Michael’s example, a writing in copper will look like “I fixed the data pipeline and made it work in half the time”. The same writing in gold will go as “I fixed the data pipeline which used to take X number of developer hours per week in operational tasks and now it takes Y hours which is a 90% improvement. The pipeline runs in 50% less time which increases the number of items processed per day by Z%. This increases revenue and profits by $$”. As a developer, not only this introduces unnecessary hassle but also creates a challenge every time before starting, to judge if the task can be polished enough to look appealing in the promo-package. If not, then logically the developer should reject doing such task despite of the awesome engineering Disneyland it would take him to. This also creates a conflict of interest with the manager whose responsibility is to get the task done anyhow by his team. #BreakPoint3

4. Too many external influences

Michael talks about that on several occasions the project he was working upon got cancelled or the structure of his management and team changed. For an engineer, this is completely out of his control. As a software engineer, one is expected to use logic, reasoning, mathematical thinking as the core tenets, yet the largest technology companies on earth have created growth process which are influenced so heavily by luck and randomness. #Breakpoint4

Introducing Stackgrowth

I have chosen this name as my source of inspiration is Stackoverflow. Stackgrowth is an idea to build a continuous growth framework for large organizations using gamification. The core principle is that growth is a continuous increasing graph and job level ups automatically happen after crossing a predetermined line on the graph. This means that to grow from level A to level B, a person needs to earn a certain amount of reputation points.

Designing Stackgrowth

Step 1: Define levels.
Step 2: Define the expectations from each role.
Step 3: Cluster expectations into two components; Milestones and Contributions. Milestones are the long term objectives a developer must have completed to qualify for next level. This includes demonstration of hard skills for a significant time over repetitive instances or soft skills which are hard to quantify at a daily basis. Contributions consists of the overall effort put in by the developer in different domains.
Step 4: Define milestones and contribution max score for each level.
Step 5: Using scrum like methods for story point allocation, allocate milestones and contribution points to each task the developer is assigned.

Let’s use this principle to build a simple hypothetical Stackgrowth system. We start off with an example. I will use some of my esoteric knowledge about Amazon. In Amazon, a college graduate joins engineering role as a Software Engineering Developer — 1 and the next level of promotion is to Software Engineering Developer — 2.

Let’s define a set of expected things from a SDE-2:

Good knowledge in designing large software systems.
Good coding standards. Writes high quality code.
Good contribution towards hiring and mentorship.
Deep Knowledge about the domain work and systems.
Worked towards operational excellence.
Helped team during critical times and new releases.
Good contribution towards organizational goals.
Large contribution in terms of features in existing system to support business.

So a hypothetical scenario for SG will look something like below. I have classified design, coding and mentorship as milestones while others as contribution. Stackoverflow uses badges to mark milestones, here i prefer trophy more.

Every task assigned to a developer will allocate a mix of contribution points and milestone trophies. Trophies can be earned by doing exceptional long term tasks like mentoring a six month intern or re-architect a complex system that is not scaling end to end.

The allocation of points to the tasks can still lie in the hands of the management or be done by mutual consensus of the team during scrums or operational planning. I will not go into details about this here because it is a deterministic sub-problem to be solved separately. Currently, my focus is on the framework and how it helps.

Using this system, the organization can maintain a contribution dashboard for each developer. This is similar to activity dashboard provided by github.

Let’s see how this system solves the problems addressed earlier:

Provides clear growth metrics: A person can do a line fitting and predict the day when he shall get promoted. There is complete transparency in the process and no surprises can come up at the end. This also means hard work and more hours per week is rewarded instead of being a burden. Did Stackgrowth accidentally solved work-life balance as well?
The system now gives fair weight to core engineering practices and business impact: Because the allocation of contribution points and trophy is done in advance, a developer has clear visibility if doing this tasks given him benefit him or not. This means that if the team constantly undervalues operational or engineering quality tasks, it will become hard for the management to get things done so a balance will have to be maintained.
Takes the promotion panel out of promotion: Engineering teams and the developers have complete ownership of their growth trajectory. It eliminates bad practices of polishing things in gold to make the metrics shine. It ensures people can use their time and energy on the real important problems of engineering during work.
Mitigate external risks: The system mitigates influences of external factors to some extent. If a six month project allocated 100 contribution points gets cancelled after three months, the developer should have option to claim 50 points or less for completing it half way. Though this is still an unfortunate scenario but one has to accept that if large companies like Google suffer volatility in project planning, then smaller companies suffer from this as well. Stackgrowth system does not aim to solve volatility. The goal here is to reduce risk and randomness. Similarly, if a management change occurs, a developer does not have to worry about losing his reputation with the earlier management and starting over because this system ensures reputation is now quantifiable.

Additional advantages of Stackgrowth system

Reduces favoritism and bias: One factor that deeply hurts the work culture in a team is the members believing that the management is biased towards some people. Weather true of not, the emotion itself can be responsible to deteriorate trust and happiness within a team. Having a consensus mechanism to allocate contribution points to each tasks will eliminate any such bias and remove the inordinate power from one person or group and democratize it.
Promotes proactive and high quality engineering: This system rewards a developer to identify gaps and area of improvements in existing components because a developer can get contribution points allocated to such tasks and execute them instead of shying away by labeling them promotion unfriendly. It is known by experience that tech debt should be kept to minimum yet engineering team keeps piling up on it because the existing framework does not reward developers to reduce it.

Closing Thoughts

I have strongly believed for quite some time that the top technology companies need to revise how they grow employees and move away from a model of “business relationship” to a model built around a sense of belonging. A sense of belonging is where you believe you are part of something bigger than you. You have a sense of community, a sense of commonness, synergy and a natural instinct to improve your surroundings. It is the same feeling which citizens express towards their country and countrymen or towards the universities and schools they have been part of. As humans, we get tend to get deeply attached to our surroundings but why this is not true for our companies where we end up spending 40–50% of our time each day? Maybe the growth system has got something to do with that too. I guess i am highly influenced by Simon Sinek so I will pause here and redirect you to the champion himself.