JournalJun 2015

Here’s why our team now chooses their own salaries

Update: for the latest look at how we’re managing self-set salaries, take a look at our Playbook page.

9 months ago, I wrote about how we were switching to a transparent salary formula within the team. That change, in which everyone could see how much everyone else was being paid, and the way that this pay was calculated, was a big step forwards for us, and a big win for transparency and fairness.

But now, as we tend to do quite frequently here at Hanno, we think we’ve found an even better way to tackle this tricky problem. It’s time to throw the old way out of the window and embark on another big pivot to the way we tackle building the ‘product’ of Hanno itself.

But first, let’s take a look at how the salary formula worked

In my last post about salaries, I didn’t actually set out the precise details of how the formula worked. There were actually 4 different elements which made up our salaries:

  • Role: this was intended to allow us to compensate “coaches” in our team higher, and formed the base figure for all salaries. A little like a tech team lead, they’d play a role in boosting the abilities of the whole team, and so I felt they should be rewarded a little higher. There’d be only 2 titles on our team, and each shipmate would be either a Coach or a Designer.
  • Expertise: this would multiply the base figure, so it had quite a big impact. There were 6 expertise bands, running from Beginner (x1 multiplier) to Master (x6 multiplier).
  • Location: since we’re a distributed team, people can potentially work from many different locations. It costs more to live in London than it does elsewhere in the UK, for example. We wanted our formula to scale as we grew, so we came up with 3 different location groupings from A (+£11,000) to C (+£0) which would add to the shipmate’s salary, depending on their location. We used Numbeo’s cost of living tool for most of our stats here.
  • Founder Component: rather than drawing arbitrary sums from the business as a founder, I wanted to try and fit my own pay into the same system, and have a measured, justifiable basis to it. The founder component was my attempt to do so, and added a lump sum onto the top of any ‘founder’ salary.

You can see all of these metrics in the salary formula spreadsheet that we came up with, which was based on a modified version of the one Buffer was using at the time, too:

While we were figuring out the formula, we tested it against the salaries we knew our peers were receiving. Zsolt also did a lot of research into market salaries for UX designers around the world. The aim was to give ourselves enough data that we could test to measure whether the figures generated by our formula would be good enough to allow us to compete with other companies for all of the roles we might need to hire for.

Here’s a set of example figures spat out by the formula. They weren’t perfect (there were some areas that we didn’t think were quite right), but I thought that they struck a good balance between keeping us competitive when hiring, and also being financially within reach.

In theory, all looked good!

We had a set of figures being produced, and we were happy enough that we were more or less competitive. We knew the formula wouldn’t be perfect forever, but it seemed decent enough to put in place and stick with for now.

So we launched it internally, giving everyone 6 months of advance warning so that they could work towards ‘levelling up’ their expertise if needed. Some people would stand to receive a slight salary reduction under the formula, so we wanted to give everyone a fair chance to avoid this. The plan was for the salary to kick in on 1st July this year.

But as we’ve been living with the implications, and our team and business has continued to evolve in the last 6 months, we’ve begun to identify lots of frustrating little weaknesses in the formula as it stood:

  • Expertise didn’t seem fair and transparent. Our 6 different expertise levels had a huge impact on the final salaries, and were designed to push people to grow in a certain direction for the benefit of the team. To level up from ‘Beginner’ to ‘Intermediate’, you’d need to be getting more involved in pitches, increasing your productivity and performance, and taking the lead on projects where you’d be managing your responsibilities and talking to clients.But even though we tried to come up with clear expertise levels and criteria, our system still missed certain things. What about the shipmate in London who had put his progress on client work on hold while he focused on networking and building business? Under this formula, his critical role would feel undervalued and he’d even be punished financially for doing what was right for the business.On top of that, the decision about which expertise level a shipmate was at, would be totally determined by me. That felt very awkward, and not really fair.
  • It’s tough to be fair about different locations. What if the statistical cost of living doesn’t accurately represent our personal circumstances, especially if someone has moved to a more expensive European country, to an Asian country like Malaysia where things they take for granted at home (bread, beer) are proportionately far more expensive? Even with less significant moves, fairly compensating for cost of living in different countries is something that many remote teams have struggled with.
  • What if someone wants to work in a slightly different way? Perhaps I’d like to take a little more holiday than most people, in exchange for a lower salary. This formula was very rigid and didn’t account for this, which felt like a weakness.
  • Dependents. Under the formula, pay would increase as you gained more experience, and most likely age, even though age wasn’t being specifically addressed. But what if someone is junior, but has a dependent, such as a disabled parent? Or when they have children. Our formula didn’t take this into account at all, meaning that for many, it would seem either unfair, or completely block certain people from joining the team because we would be unwilling to budge on our salary expectations.
  • Coaching was hard to qualify and quantify. Since it formed the base salary component, the distinction between being a Coach or a Designer had a big impact on salary. We were trying to compensate skilled shipmates who’d potentially join us from former tech team lead positions, but the way we were doing so was messy. It also failed to reflect the fact that in a really effective team, everyone is responsible for coaching other people. Not just the ones who had the title of “Coach”.
  • And anyway, why do we even need titles? We’d worked hard to remove titles from our team, but all of a sudden, Coaches would become first class citizens. That didn’t feel like a step forwards.
  • We were unhappy about salary ranges. We all feel quite strongly that salary range between the highest and the lowest paid shipmates shouldn’t be huge. But it’s very hard to build a formula which fairly captures this, while also maintaining financial competitiveness. It’s said that the effect of income on happiness is minimal once you’re earning more than $75,000–we discussed as a team how we should be looking to get people to this regional equivalent as quickly as possible, rather than having a large salary range.
  • Everyone fit inside the formula, except for me as a founder. Technically, I was inside the formula, but with a ‘Founder Component’ of £25,000, it was obvious to everyone that I wasn’t truly affected by changes to the base salaries and other components of the formula, which dictated 100% of everyone else’s pay. It didn’t seem fair that I wasn’t forced to play by the same rules, as well as being the one who had power over the salary formula itself.

Above all, there were enough little issues that the formula just didn’t feel totally fair and balanced. Our top priority in all of this was to come up with a fair and transparent system–but if the whole team isn’t happy with it, it can’t be truly considered fair. And that’s a problem.

So we tried to iterate towards a better formula

After agreeing to launch the formula as version 1, we continued to tinker around:

  • We tried tweaking the numbers and metrics, and even tried very different maths, such as removing all of the ‘multiplying’ factors, so that there was less of a salary range from top to bottom.
  • We adjusted our ‘expertise’ banding to include many factors that the team identified, such as networking and pitching.
  • We talked about how we could integrate a team voting system for appraisals, a bit like the one Stack Exchange use, so that judgement wasn’t being made entirely by me, as the founder.

But we quickly realised that there will always be edge cases. We’re not talking about abstract data–we’re talking about the people we work with. And people just don’t fit neatly into formulas. Our problem was that while we had noble intentions, we were trying to approach the problem from the top down, defining a formula and trying to squeeze everyone into it.

What we really needed to do was to take the opposite approach, and try to figure out how to approach things from the bottom up, in a way that’d satisfy each member of our team. As Ricardo Semler once said:

“Conventional salary systems after all, strive for standardisation. The System we were contemplating would be individualistic.”

I started to look for a better way to do things

I’ve been reading and thinking a great deal in the last few months about how we can take steps towards becoming a self-managing teal organisation. We’ve been making tons of progress on many fronts, and this top-down approach to salaries seemed to go totally against everything we were looking to achieve with our transition.

The real question was how could we retain the strengths of the formula (the transparency and attempted fairness) while avoiding all the weaknesses it held?

I thought about the system we’d used in the past: when a new shipmate joined the team, we sat down and had a conversation about how much they were currently earning, what they felt they wanted/needed to earn in order to be able to work with us, and how much Hanno could afford to pay them. After a pretty relaxed discussion, a little thinking time, and perhaps a follow-up call or two, we usually agreed on a figure that was high enough for them, while also being affordable for the company. On an individual level, that new employee was usually pretty happy. It was a flawed system in that it perhaps depended a little on the person’s negotiating skill, and the rest of the team didn’t have a totally clear picture of how much they were earning, but it certainly had its strengths.

I figured that there were 3 critical components of a solid salary:

  • The employee thinks it’s a fair salary
  • The team thinks it’s fair salary
  • The company can afford to pay it

I mentioned Ricardo Semler a minute ago–that’s not a chance reference. His fantastic book, Maverick, was hugely informative while I was trying to figure out a better way to handle our salary formula. It describes the way his company, Semco, implemented a self-management system which included self-chosen salaries, several decades ago. And it worked, even though this is a large industrial manufacturing firm with a blue-collar workforce who were traditionally deeply distrusted by management.

Semco figured that there were 4 pieces of information that an employee needed to know in order to come up with a fair salary:

  • What they thought they could make elsewhere
  • What others with similar responsibilities and skills made at Semco
  • What friends with similar backgrounds made
  • How much money they needed to live

Semler also gave a great TED talk about Semco and self-management which is well worth a watch, and helps you to understand the principles behind this quite unusual system:

The idea here is that as long as we have total financial transparency, respect for the individual, peer review and self-discipline in our process of setting salaries, employees can be trusted to set a salary which works for them and also their team. It’s an unusual attitude, but I’d say has been soundly backed up by Semco’s success since they switched to self-management.

And we’re not the only ones who seem to be struggling with fitting salary formulas into the emerging concept of teal management. The team at Buffer, whose salary formula inspired us when we first came up with our own, have also been talking a little about changes behind the scenes that are taking them in the same direction towards self-managed salaries.

So, here’s how our self-managed salaries now work

We’ve done the research, analysed lots of examples about how self-managed salaries have been done successfully in the past, and we think we’ve come up with a fairly robust way of doing them.

Here’s the system we’re using for now. It might seem a little bit complex at first, but in reality it’s far simpler than either a perfect formula which encompasses all possible variables, or an opaque, politicised negotiation and secret list of team salaries:

  1. Along with my regular state-of-play update to the team, which I put together every 3 to 6 months, I’m also including a financial advisory on the current company financial status, with a general opinion and recommendation for the salary direction that the team should be thinking about for this upcoming review, based on our financial status. That’s not an instruction, but rather, an informed opinion–under the principles of self-management that we’re moving towards, people are free to make their own decision, taking my opinion into account (and disregarding it if they choose)
  2. The team react to this guidance with a round of feedback and opinions. Some might even disagree with my assessment, and call me out on that. Some might request more information or clarifications, and I’ll do my best to provide that.
  3. Shipmates takes time to think about the finances and their own salary needs. They can ask for advice or opinions from others while they’re putting together this proposal, and we’re suggested taking the following factors into consideration when working out a figure:
    1. How much do I need to earn, in order to live and to be satisfied with my pay?
    2. How do the next 3-6 months look for me? Thinking about longer periods should help to discourage big swings in compensation, which will make it hard to budget.
    3. How much can Hanno afford to pay? The whole team has access to our financial dashboard and budgeting dashboard hosted by Float, which uses the live financial data from our Xero account. So there’s total transparency to how much money the company is making and spending, which is critical for this whole process to work.
    4. How much do my fellow shipmates earn? We have a spreadsheet which lists how much everyone in the team has been paid each month, this year.
    5. How much do other people in my city/country earn?
    6. How much do people with my skills and responsibilities earn elsewhere?
  4. The shipmate puts together a proposal, in whatever format they choose, for how much they want to receive in the next few months. It’s recommended that they explain their thought process in sufficient detail, especially if it’s an increase since the last salary review, because this will make it easier for their shipmates to understand their thinking and motivations.
  5. Just as the team reacted to my proposal, now we have a reaction round from the team, to this individual shipmate’s salary proposal. This isn’t a battle: it’s a conversation, and the shipmate is obliged to listen to the feedback from the team.
  6. Shipmates are free to modify their salary proposal based on that feedback, but they don’t have to do so, if they disagree with the advice. That’s the power which comes along with self-management! This idea of listening to opinions, but not being obliged to follow them if you strongly believe otherwise, is part of what we call our Advisory Process, which we’re documenting at the moment and trialling as we shift to become a teal thinking organisation. I’ll be writing about how we’ve come up with this system in another blogpost in the next couple of weeks.
  7. Under the Advisory Process, there is just 1 ground for a salary proposal being declined: if there is a genuine risk that the salary being proposed would cause irreparable harm, or move Hanno backwards.
  8. Pay for every member of the team is documented in a spreadsheet for everyone to see and refer to, along with the forecasted upcoming payments to the whole team, so that we can accurately plan our outgoing costs for the next 3 months.

Simple, perhaps… but won’t people abuse it?

Well, this is the immediate reaction from many people, who are a little sceptical. When I’ve explained the way the system works, they triumphantly ask me “What happens when I say that I want my salary to be £200,000/year?”

First up, if you try and compensate yourself with a crazy figure, there’ll be a high risk that that salary will get blocked by the team at step #7, on the grounds that it’ll cause us serious financial issues unless you’re delivering that level of value.

But there are deeper subtleties. Sure, if you tried to drop this system into a faceless big corporation, where people don’t feel strong ties to the company, you’re going to have issues. But you have to keep in mind that at Hanno, there’s a strong sense of loyalty to the team, a lot of peer pressure, and everybody knows how much everybody else is earning. Here’s where the nuance comes into play and stops the whole thing turning into a free-for-all cash grab:

“Cynics thought a few [people] might take advantage and award themselves undeserved or even outlandish sums, but that didn’t happen. I like to think that it is because everyone at Semco is reasonable and honest. Maybe, but I’m sure that transparency had a lot to do with it – public salaries are a strong disincentive to be conspicuously greedy.” Ricardo Semler, Maverick

When you work with a bunch of people you respect, you don’t walk into the party and eat the whole cake before anyone else can have a slice. Plus, when the rest of your team has the ability to dictate who is being hired and fired, and can shape the budget within the company, you have a far stronger incentive to be decent and reasonable about the way you approach the decision as to what you’ll be paid. As Semler explained in Maverick:

“There are three reasons why reasonableness prevailed. First, everyone knew what everyone else was paid. Second, the top people are all modest about their pay. The third reason our people tended to be modest about salaries has to do with self-preservation… Our people know salaries account for most of our operating costs, and they think about our six-month budgets when they set them. It’s easy to solve a budget problem by eliminating a salary that seems too high, and no-one wants to stick out.”

But there’s only one way to find out whether this works for us. Stay tuned, and our next post in a few months will explain exactly what happened on July 1st, 2015!

Featured image: “Tax Credits” on Flickr

Posted by
Jon Lay

Jon is a Partner at Hanno. He wears many hats, but his primary focus is on leading our engineering and technical operations.