I believe in the power of economics, specifically the power of positive and negative incentives. From a philosophical standpoint, people generally respond to either economic incentives or morality. If we assume that moral issues play a minimal role in the workplace, one could argue that employees predominantly respond to economic incentives. In other words, they are motivated by positive reinforcement (rewards) and negative reinforcement (consequences). However, what happens when there are no enforced incentives or consequences? In my experience, people tend to follow the path of least resistance (inaction) in the absence of incentives. Here are a couple of workplace scenarios from the past few years that illustrate when ‘doing the right thing’ is a negative incentive. I promise this is my only Amazon bash, if you can even consider it that.

Show me the incentives and I will show you the outcome. - Charlie Munger

In one instance, our team dedicated over a year of development effort to build a new feature requested by customers. However, the launch was stalled (for months) because a project manager failed to complete their necessary launch tasks (a couple of days of work). As a senior engineer, I could have stepped in and finished the PM’s work, but that would have upset the PM and management while also reflecting poorly on me for not focusing on my core responsibilities. Ultimately, the customers lost out the most by not receiving the completed feature. The busy PM tried to pressure more junior engineers to take over their duties, which seemed like an abuse of authority. Although since it was a passive-aggressive tactic, I couldn’t directly call it out and could only prevent the junior team members from taking on those tasks instead of their assigned work. The situation was frustrating, but we eventually launched the feature, which immediately became our most successful release, increasing usage by over 200% with over half of new traffic using the feature. How much more revenue would we have made if we had not delayed that launch for months? This demonstrated the high demand for the functionality we had built despite the PM’s failure to complete their minuscule portion on time.

I had the pleasure of watching a senior leader chose to divert resources and attention away from an established customer-focused program in order to pursue a side project with higher visibility. The bureaucratic nature of large organizations can enable such behavior, allowing individuals to take on high-risk high-reward endeavors or avoid responsibilities altogether, with minimal consequences. This dynamic often results in a binary split among employees: one group that resists change and delivers minimal customer value, and another that chases random “high visibility” initiatives that benefit no one. Consequently, the bulk of the actual work falls on a small subset of the workforce, reflecting the oft-cited phenomenon of 10% of people doing 90% of the work.

As a Senior Engineer, my responsibilities span coding, team-level design, and facilitating cross-team consensus to deliver features. If a team is heavy in L4s, then they are excellent at coding but struggle at the others. If a team is heavy in L5s then they are excellent at team level designs but struggle at the others. It is in the team (and companies) best interest for me to fill the gaps and do the work that others cant or struggle with. Instead, I am largely evaluated on my coding output with a minor focus on cross team collaboration. My evaluation is not in the value which the team provides, its on my personal measurable output. Ideally, my role should be to maximize the efficiency and impact of the engineers around me (a force multiplier effect), but there is no established method to quantify that impact. Instead, I am assessed based on solo metrics, despite management being aware of alternative evaluation approaches that could better align with my responsibilities.

Evaluating performance based on metrics like lines of code or number of code changes (CRs) is a flawed approach, as established by Apple in the 1980s and relearned by Microsoft in the early 2000s (I suppose its been 20 years…). Using measures such as the number of comments, CRs, or lines of code as performance indicators creates negative incentives. With solid linting practices and established coding standards in place, comments should be minimal, and infrastructure or configuration code changes should rarely require comments. Metrics like CRs and lines of code are easily manipulated, leading to two problematic outcomes: the creation of unnecessary code, which accumulates as technical debt and slows velocity, and a disincentive for code reuse. It’s not uncommon to observe engineers, particularly in languages like Java or Kotlin, writing hundreds of lines of boilerplate code merely to implement a few lines of actual functionality, solely to inflate their output metrics. The worst part? You almost cant blame those engineers.

When it comes to the type of employees one would prefer, there are two contrasting approaches: those who unquestioningly follow instructions, and those who challenge and question every decision. The preferred approach often depends on the level of accountability involved. If you are held responsible for outcomes and success is essential, you may favor those who provide critical feedback. However, if there is limited accountability and mistakes carry minimal consequences, the path of least resistance may be to surround yourself with those who follow without challenge. This dynamic extends to situations where an individual’s priorities are misaligned with the organization’s or customers’ best interests. Instead of focusing on delivering value, their efforts may be directed towards activities that garner high visibility or build rapport with influential stakeholders, even if those actions potentially undermine the company’s goals. The rationale is that cultivating trust and relationships carries more weight than serving customers effectively. There is an inherent risk aversion when it comes to disagreeing or challenging others, as confrontation is seen as riskier than advocating for initiatives that ultimately prove unsuccessful. Think about it, advocating for a well-intentioned but poorly adopted feature is more forgivable than directly challenging a team or individual for how good the feature will be. Ultimately, the risk aversion stems from the belief that maintaining trust and avoiding confrontation is the safest approach.

*maybe morality isn’t as important as I think it should be https://en.wikipedia.org/wiki/Asch_conformity_experiments https://en.wikipedia.org/wiki/Milgram_experiment

*seriously lines of code is silly https://en.wikipedia.org/wiki/Source_lines_of_code https://www.folklore.org/Negative_2000_Lines_Of_Code.html

*think about it. You run a $600M business inside Amazon, that is barely 1% of revenue. That is macro-economic noise. No one cares. Makes sense why my $6M and $60M pitches were ignored, when I hear about others $600M pitches being ignored.