Growing Octopus Part III: Compensation and career progression

Published on: 26 Feb 2015 by: Paul Stovell

This is part three in a series of posts about how we're growing as a company. In this post I'll talk about our plans for compensation and career progression.

  1. Developer career paths
  2. How we work
  3. Compensation and career progression
  4. Interview process
  5. Laptop program
  6. Anti-harassment policy
  7. Local or remote?

Salary expectations and fairness

At places I've worked in the past, pay discussions typically start with "how much do you want?", and then negotiated downwards to how much you'll accept. Good negotiators get more, bad negotiators get less. Women and minorities tend to be at a disadvantage in this kind of system. Two people doing the same job, equally well, can often be getting paid very different amounts.

My goal is to have a fair system, whereby any two people doing the same role, with the same kind of experience, should be earning the same. Simon Galbraith helped define the acceptance criteria for this: if I accidentally printed a spreadsheet of everyone's salaries and left it on my desk, no one should be outraged to see what anyone else was earning. A few people have written about such structures, including at Fog Creek. We're still starting out (our first full time employee hasn't been with us for even 12 months yet) but here are my thoughts so far.

In my post about Developer Career Paths I outlined the different developer roles I imagine us having down the track. So our goal is that any two people in the same role (e.g., senior developer) should be on the same salary. To achieve this fairness, this means that the level of compensation for a given role is based on:

  • The role, and the market rate for that role (based on location). We'd always aim to meet the market.
  • Level of experience in the role - some people might only just make the cut for a given role, while others could be very close to moving into the next role

Pay rises work similarly; each year in July we'll review the market rates for a the different kinds of roles, adjust for inflation, and assess where people fit in. We'll then adjust across the board.

(Of course one downside of this approach is we can't advertise that a given role pays $X, since you'll then know how much everyone here is earning :-))

Coaching over performance reviews

My second goal is to decouple performance reviews from salary negotiations. We hire smart, professional people, and we expect them to perform well simply because doing a good job - building great software, making customers happy - is an essential part of being human. My father-in-law was a trained carpenter, and when he builds a chair or a table, he does his best not because someone else is watching him, but because he takes pride in what he creates. Intrinsic motivation is incredibly powerful.

Rather than quarterly/yearly performance reviews, we do regular one-on-ones. It's not a review, it's a coaching and feedback exercise: what can we do help you to be more autonomous? To contribute more?

Could all this mean that we miss out on good people because they can negotiate for slightly more elsewhere? Perhaps. In Brisbane, a large chunk of the software developer market is in contracting to government, so it's certainly possible to earn very high rates that we can't compete with (of course, I think we can compete by offering much more enjoyable work). But overall, my goal is to build a rockstar team, not hire a bunch of individual rockstars, so ensuring fair pay across the team is an important part of making that work.