Buffer’s Salary Formula

Introducing the New Buffer Salary Formula, Calculate-Your-Salary App and The Whole Team’s New Salaries

Let’s address the elephant in the room first: the most notable aspect of Buffer’s salary policy is that it’s 100% transparent. Anybody can go into the spreadsheet linked from the post and see what each Buffer employee is making.

This post is not about salary transparency.

It’s a contentious topic that will earn its own separate post in due time, when I can better formulate my thinking on this particular aspect.

But whether you agree or disagree with their full-transparency policy has little to do with the real learning opportunity here: looking at a very bold attempt to formulaically model “soft” aspects of the Buffer culture into the way Buffer employees are compensated. That is worth studying and celebrating. Let’s begin.

The current version of Buffer’s salary formula consists of 5 core components:

  • Role – talent markets matter. Software developers have a higher (talent) market valuation than accountants, for example. This component accounts for that. (more below)
  • Experience – how good you are at what you do matters. Note that this is not “tenure” (x years of experience doing y), but an assessment of the level of skills based on discussions. Buffer currently uses 4 ties with a multiplier varying between 1x and 1.3x 
  • Dependents – the social dynamic that you live in matters. For every family member that depends on your income you get an extra $3K/year
  • Loyalty – loyalty matters. You get a 5% increase for every year with the company
  • Choice – your risk tolerance matters. Employees have a choice between an extra $10K or 30% more equity

Here’s a representative example:


The role component is worth further exploration as it’s the most complex one. It’s impacted by the following elements:

  • Overall base (35%) – standard US data for a particular role
  • Location base (65%) – accounting for variations in cost of living across multiple locations
  • Role value – Buffer may disagree with the way the market values a certain role (for example, if they think that customer support reps are undervalued by the market). This multiplier allows it to adjust for that.
  • “The Good Life Curve” – (cost of living correction) a $0-$8K adjustment that takes into account the market rate for a certain role in a certain location. This is perhaps the most thoughtful and interesting piece of the equation. The folks at Buffer argue that taking the market rate at face value is unfair. For example, while there may be a 4x cost-of-living difference between SF and Capetown (CPI of 113 vs. 30) there may be a 5x salary difference ($124K vs $25K) leaving the person working out of Capetown worse-off compared to his peer in SF. This component introduces a multiplier that’s meant to address that.

In future iterations the Buffer team plans to take a deeper look at two existing components that have become stale/outdated: the way experience and risk tolerance (“choice”) factors in, as well as two add’l external/environmental factors: taxes and exchange rates.

I’m excited to see where the Buffer team takes this experiment and particularly looking forward to see the next rev of the experience component, being the most “qualitative” component in the equation. Personally, I think their approach already leads to a better outcome than the standard “choose the percentile of market rate you want to be in”.  The biggest challenge the team will have to tackle has to do with complexity. Figuring out a way to keep the formula simple enough to understand while factoring additional drivers and addressing the interplay between them. Otherwise, “actual fairness” and “perceived fairness” will start to diverge.

Buffer’s Salary Formula

O-Rings and The Myth of The 10x Engineer

Another wonderful post by Adrian Colyer (of The Universal Scalability Law for Organizations) covering another topic that is near and dear to my heart:

The O-Ring Theory of DevOps

In this post, Adrian applies Michael Kramer’s O-Ring Theory of Economic Development to the realm of DevOps. but in my mind, the most interesting applicability of this theory is at a context somewhere between the massive scale of economic development and the targeted scale of DevOps: the context of organizational operations and talent management in particular.

In a nutshell the O-ring theory, inspired by the 1986 Challenger disaster where a single failure of an O-ring lead to catastrophic results, shows how small changes in quality lead to massive changes in output/productivity.

The theory applies in scenarios that meet the following three conditions:

  1. Production depends on completing a series of tasks
  2. Failure or quality reduction of any one task reduces the value of the entire product
  3. You can’t substitute quantity for quality (Adrian’s example: two mediocre chefs can’t replace a great chef in making an amazing meal)

In Adrian’s example, quality of each step/person is measured by a coefficient (q) between 0 and  1, and the process has 10 steps. Improving the quality in each step from 0.5 to 0.75, a 50% improvement, yields a 600% improvement in output.

I’d argue that the entire process of software development and delivery meets the three conditions for the O-ring theory to apply. You can probably generalize this more broadly to the entire organization/company, but satisfying the 2nd condition may be more challenging.

Adrian’s implications, applied to talent will look something like the following:

  1. A single “weak link” overall output dramatically. It’s not enough to hire top talent for some roles. You need to be good across the board.
  2. Small differences in quality quickly compound to make very large differences between the performance of the best-in-class and the rest
  3. The better you already are, the more value you get from improving your weaknesses. Conversely, if you’re fairly poor across the board, you won’t get as high a return on investment on an improvement in one specific area as a company with a higher overall level would. These forces tend to lead to ‘skill-matching’ – fairly uniform levels of performance across the talent pool of a given organisation

A different way to articulate #3 is that the more great workers a company already has, the more incremental value another great worker adds. This, to some degree, rationalizes some of the behaviors we’re seeing in the market where top performing companies are willing to pay more for top talent – it’s not just because they can, it’s because they should…

But it also calls into question another practice that’s becoming more common in these top performing companies. Some of them, like Google, use the growing proof that talent is not distributed normally (which I covered here) to justify paying their employees “unfairly” and legitimizing substantial (3x-5x and sometime even more)  pay differences for employees at the same level. But if the 10x difference in output can be explained, not by the existence of a single 10x engineer, but by the existence of 10 engineers that are only 10% better than average, does that still make sense?


O-Rings and The Myth of The 10x Engineer

A Counterintuitive System for Startup Compensation

This First Round Review article  is one of the better articles on compensation I’ve read in a while, showcasing Molly Graham‘s comp framework.

A Counterintuitive System for Startup Compensation

The gist: a few key principles (no one is ever happy with comp, and comp never made anyone happy; salary opacity is a myth; etc.) yield a fairly simple, transparent and straight-forward comp system.

If you acknowledge the limited (but still critical) role that comp plays in attracting and retaining the best talent, and that fairly quickly, group effects (like fairness) become much more important than individual effects (attracting/retaining a specific person) – a very strong case can be made for a system that’s as formulaic as possible, and intentionally trying to keep discretion to the bare minimum.

Graham proposes a straw man in which a set of levels are applied cross-functionally, and base comp and equity are set only according to them. The only functional exception is sales, but comp for those roles is being addressed with the same formulaic rigor. There are no exceptions and no negotiations. The only discretion that a hiring manager may have is around slotting a candidate/employee into a certain level.

My favorite part in the article is its end, where an outline for scaling the plan as the company grows is discussed. This is an often overlooked aspect of such systems and I was delighted to see that it wasn’t ignored in this piece.

On a slightly more philosophical/abstract level, it’s interesting to think about the role equity typically plays in this plan and others. I think most startups view equity as a necessity for keeping cash burn rates under control, as well as a self-selection mechanism for attracting talent with high risk-tolerance w/r/t their personal comp (which is viewed as a desirable trait). A scenario in which one or more of these constraints/assumptions is relaxed, or a scenario in which they are supplemented with add’l assumptions about the purpose of equity, may suggest a different role for equity in such system.


A Counterintuitive System for Startup Compensation