Five years ago, Lenz (one of our co-founders) wrote:
At iwantmyname everyone earns the same. This sounds strange to many and I get asked a lot of questions how this may work once we grow bigger and the honest answer is: “I don’t know, but so far it works” and I give that same answer since we started 5 years ago.
The underlying idea has two main roots. First, we really think that everyone is as important to the success of our team as anyone else in the team. We don’t believe in a hierarchy or in more important people. If we hire you, we think you are valuable and want you to be part of our team as a level peer, not an underlying that does the stuff no one else wants to do.
Soon after, it hit the Hacker News front page, and the top comment went as follows (from a person called fishtoaster):
That’s a cool experiment. It’s always neat to see people trying new, weird ways to run a company.
That said, I would predict the following:
- As the company grows, they have trouble hiring specialists or more senior people, since they’re competing with other companies for those people, but without the flexibility to offer a comparable salary. They could solve this by paying their highest-paid person what they’re worth, and everyone else the same, but that could be prohibitively expensive.
- The need will develop for people who, though valuable, are plentiful (e.g., a janitor, but fill in any role here that’s generally near the bottom of the pay scale). The decision will be “We’d really like a janitor, but not enough to pay $X”, where X is their everyone-salary (which has to be high enough to attract their most valuable people). As such, they’ll be hard-pressed to hire roles that aren’t really worth that much to them.
- Of course, you can solve either of those by having more money than you know what to do with. So, if they’re wildly profitable, it’s a system that’ll keep working.
That’s just my prediction, though. I’d love to see a followup blog post in a few years describing how it went.
Well, fishtoaster… this one’s for you.
Market rate
One thing that happened over the last 5-10 years is that people’s idea of what “market rate” is for a remote developer job seems to be shifting to the market rate of San Francisco. And that’s a tough place to play if you A. don’t have beaucoup VC money, B. aren’t sitting on a pile of disposable cash.
For instance, according to PayScale, the average software developer in Wellington NZ makes NZ$64k. We pay more than that, but when you become a remote company, people start looking for the $134k USD salary people are making in the top 10% of SF (which seems a bit low to me, but I’ll take their word for it). In one beautiful locale we pay in the top 10%, and in the other, we’re pretty meh.
So when fishtoaster says,
The decision will be “We’d really like a janitor, but not enough to pay $X”, where X is their everyone-salary (which has to be high enough to attract their most valuable people).
… I feel that. It’s a legitimate concern. Basically, we’re playing a game where the success of the company hinges on our ability to hire good developers, but we can’t offer top SF rates without shrinking our staff because our operating costs would be too high due to our flat structure. Fortunately for us, we’re competing not only on salary, but freedom, and that shouldn’t be taken lightly.
For as much as we hear about greed and people doing anything for money, the truth is that the world is large and full of people with different motivations. We’ve had people in emerging economies mention top-10% SF rates, but we’ve also had people in the more expensive parts of EU work for less because of the lifestyle we can somewhat uniquely offer. For example, I could probably make more in a management role elsewhere, but at iwantmyname, I get to pick my kids up from school every day without fail. To me, that’s worth a whole lot, but to someone else, it might mean very little. We’re all motivated by very different things.
I’m sure certain individuals are paid somewhat below market value while others are paid handsomely for their role. This can hurt when hiring employees in the former category. The flat hierarchy, general job benefits, and culture need to make up for the market pay-cut.
(Random quotes are from a team poll I did about our one-salary structure. You’ll see them sprinkled throughout.)
For us, everything has mostly worked out — we offer a certain amount, have had little trouble filling job openings, and our turnover is low (and to my knowledge, no one who has ever left did it primarily because of our pay structure). That said, I do feel the pressure of getting us closer to SF-senior-dev competitive wages because recruitment will inevitably get harder if the pay gap becomes too wide. We’ll never be able to pay the top-end salary of a Fortune 500 company under our current structure unless we stumble our way into a mind-blowing new market segment, but we can pull ourselves closer without making non-dev positions unreasonably expensive.
To be able to hire and retain good staff, the amount also needs to be focused on the high end of what’s needed to be competitive. What may be a good salary for support or marketing or whatever elsewhere may be quite low for good development talent, for example, and people are rarely, or only to a very limited degree, willing to accept a pay cut because they like a company’s culture or the projects they’ll be doing, etc.
Motivation and turnover
Turnover is a tricky thing to talk about because it feels like weakness, but it’s impossible to avoid when running a business. And it’s important to know that all companies are working from a different baseline. In a previous life, I worked at an ad agency that somewhat purposefully churned through recent college grads to maximize staff ROI (turns out, cheap labor being client-billed for ~$150/hr is a good way for owners to get rich). That world is different than this world though — clients came and went, onboarding was basically instant because each project was from scratch, and the work was more about immediate impact than retaining institutional knowledge. Turnover there was like watching the seasons change. So it went.
In a small tech shop like iwantmyname though, institutional knowledge is everything because nearly nothing is built from the ground up. And onboarding is relatively painful because we don’t have people we can just dedicate to training. Turnover sucks, so we do our best to avoid it. And I think we’ve done a pretty good job. Here’s what our “stats” look like:
- 20 total employees
- all but four are still involved with the company
- all four that left were developers
As I said before, overall retention is good… much better than at any job I’ve had in the past. But while the sample size is small, there is a relationship between market rate and turnover. While we have 100% retention for non-developers, our typical dev window is roughly three years (again, small sample size… compounded by the fact that iwantmyname basically didn’t do any hiring for the first five years).
Here’s the thing though. Even in Silicon Valley, where salaries are extremely high across the board and employees are showered in benefits, tech retention is low. I don’t think income is the primary motivator here (although I’m sure it helps with recruiting).
My general theory is that people are motivated by two things in life: pain avoidance and happiness. No matter what you do, you’re always trying to find the thing that brings the most happiness with the least amount of pain. Some people find higher peak happiness through suffering, and some people are hedonists who work to experience minimal pain, but both are operating under the same framework.
So what we’re looking at here is a dev vs non-dev marketplace of employees. Every individual is different, but most people find happiness at work through money and perks (remote work, working on stuff you like, freedom to make decisions, etc.). The tangle is that in this market, non-devs tend to experience pain while looking for jobs, while even mediocre devs routinely get contacted by recruiters offering ++ salaries and signing bonuses. There’s no friction for a developer, and without friction, there’s no pain. So as soon as things lose their shine, stats show that developers tend to move on. And it’s understandable — why stagnate when there are endless opportunities to do new and interesting things?
From a management perspective, all I can do is optimize the things I can control to reduce pain. Here are the three things I focus on:
- Freedom. The worst part of being in a traditional office is seeing how fast your calendar gets booked. Endless meetings, pointless team-building activities, random reporting reminders to make middle managers happy. Some of it is useful, but I do my very best to clear up people’s schedules so they can maximize their time not working. To me, the ideal workplace is one that lets me enjoy my own life… not one that tries to merge with it.
- Dysfunction. People tend to not like dysfunction, and dysfunction is really just a symptom of not understanding priorities. Yes, some people are just lazy, but if you can solve laziness, the best thing a manager can do is to be extraordinarily clear about the work ahead. Generally, if you can get smart people to work towards the same goals while avoiding institutional confusion, they’ll achieve great things.
- Fairness. The other thing people tend to not like is the feeling that their peers aren’t holding up their end of the bargain. And it’s especially bad when the person telling the team what to do isn’t doing anything themselves. The best way to make this a non-issue is to get dirty from the top-down. No one is above the rest — not even managers.
One-salary makes everyone feel they are an equal part of the team. Whether they’re in support, dev, or product areas, all have an equal voice. That equality helps avoid the “that’s above my pay grade, let someone else deal with it” attitude.
…
(A completely flat structure) negates the need for traditional performance reviews and salary negotiation, which are very difficult for some people and do not favour those who have not been raised/trained/educated to advocate and negotiate hard for themselves. (And can be actively penalized for it, in the cases of some demographics.)
Is there a better way?
When I talk about our flat salary, I often come at it from the angle of focusing on what alternatives would buy us. Barring a cash infusion, we have X dollars that can be allocated however we want. Right now we know precisely how much each position costs (because we all cost the same), but if we moved off our flat structure, what would that look like?
My best guess is that developer rates would go up, support rates would go down, and everyone else would be roughly the same. But it’s not like rates would change proportionally. At best it’s a wash, with support rates going down exactly the same as developer rates are going up, but that’s silly. SF rates for senior devs would cost far more than the savings we’d make on the support side, and the talent drain in support would make for a far inferior product. Plus, our support staff does a lot more than their direct tasks — they’re worth every penny they get paid.
In reality, our flat-salary has probably allowed the company to grow faster than it would’ve under a traditional structure. I don’t think that was the intention going in, but it’s essentially put a movable ceiling on rates that have increased exponentially since we started around the 2008 recession. Our salaries are tied to profit, and while they’ve gone up over time, they just don’t compare to the whims of a company tied to an out-of-control market or VC-infused debt.
To me (and to be clear, I’m part of the flat salary with no ownership stake), it’s a fair deal because everything was on the table from day one. Everyone makes X, there’s no excessive Apple-esque cash hoard that’s being syphoned to investors instead of the staff, and we’re free to leave at any time.
With that said, if we were to change, here are three models that seem acceptable (all have pros and cons):
- From an employee standpoint, the Basecamp model is a good way to maximize the retention and recruitment of “senior” talent while mostly keeping out the ugly popularity contests that come with salary negotiations. My understanding based on my recollection of the book It Doesn’t Have to Be Crazy at Work is that hey pay an upper-tier salary per position based (I think) on SF rates. They also use a junior/senior tier, which allows them to recruit raw talent without worrying about fair workloads (it’s be hard to justify paying the same salary to two devs who have vastly different levels of experience, but there’s also a lot of “grunt work” that needs to be done that might drive a senior person away).
- This one was floated by someone in the internal survey: ”A possible solution to retaining talent longer term (who may start looking to move on for financial reasons) is to add a ‘years with the company’ accelerator. Putting the fiscal focus on retaining experience and talent seems more logical to me than hiring a ‘rockstar’ candidate and offering them double their colleague’s salary so they can shoot through some work and leave in a year or two.’’ I generally like this, but it would probably have to be capped at some amount to avoid paying people too far above market rates. While retention is important, I don’t know if it’d make business sense to, say, pay someone triple what a comparable replacement would cost. And you don’t want to be in the position of laying off a tenured staffer because you mistakenly started paying them too much.
- I’m not sure how the accounting would work, but if we kept the salary the same and tied it to a quarterly bonus structure based on company profits, it could create a more direct link between short-term productivity and income. (That’s not really a fundamental change though… more like a nudge.)
Anyways, fishtoaster, here we are — getting by with a system that’s held up strong for ten years. We don’t have “more money than we know what to do with” (YET!!!), but I think everyone would agree that iwantmyname sits in the successful column of small businesses. And to me, that’s a win in the one-salary column.
I’ll make a note on my calendar to update this in 2024.
