The third part in my series on being a Startup CTO.
A common question I see from startup CTOs is “how do I compensate my engineers?”. This question often arises from a place of wanting to establish some rigour and fairness to the system rather than rewarding someone for being a great negotiator (or great at threatening to leave). Typically, this happens when the engineering team gets above 10 people. Attempting to put a structure to it too soon can be an exercise in spending more effort than the gains justify.
Getting compensation right is essential. In my experience, money isn’t a great motivator for many engineers. However, if done poorly it can be an incredibly powerful demotivator and push people away from your company.
In this post, I talk about how I create a compensation system. This post does not deal with on-call compensation as that is typically a separate concern.
Whenever I think about designing a compensation system, I like to figure out what the objectives of the system are. For me, this usually boils down to the following:
A notable absence from this list is making it work for everyone. Whatever system you develop will likely not work for everyone. It is better to be aware of the limitations of your system and ensure you hire to fit them. For example, you might have a very customer-centric culture and reward engineers for being ‘good with people’. This system means that anyone that wants to avoid customer contact will likely not do well in your system. Knowing this enables you to make smarter hiring decisions and keep growing the culture you want.
All of this combined contributes towards a healthy engineering culture with high retention and growth.
Most companies loosely agree on what makes a great engineer. There is some variance though and understanding what is important to your organisation will help ensure that you’re rewarding the behaviour you want to see more of. For example, early in Conversocial’s life we needed engineers with a good sense of product and we specifically hired and compensated for this.
Attempting to do a quantitative analysis of an engineer’s performance is hard. Being a great engineer is a combination of soft skills and technical skills - the exact definition of great varies between companies depending on their needs.
I favour using qualitative assessment with a structure to what I’m qualitative around. Typically this results in a grading system where engineers are given a grade according to a variety of qualitative metrics. Building a grading system from scratch is an arduous task and starting with an existing one can be a great shortcut. I often turn to Camille Fournier’s excellent ladder.
Broadly, my guidance on junior vs mid vs senior engineers is as follows:
I don’t mean that senior engineers are off doing their own thing and being mavericks. Senior engineers have the ability to do so - but still seek the opinions of their co-workers to ensure they’re doing the best they can.
As your team grows you will find that you will likely want to evolve the system by adding more grades or different tracks for different skill sets, e.g. a leadership track.
I always make this guidance visible to the team so that they can see what they need to be doing and what we value.
In combination with a grading system, I like to include uplifts in salaries for engineers with particularly desirable technical skills or knowledge. Uplifts are a fixed amount of additional salary. Uplifts help the system cope with market dynamics around particular roles. For example, at the time of writing React engineers are in particular demand and consequently expensive. Making this transparent with the grading system helps engineers understand what technical skills they might want to learn in future.
Giving each grade a single salary (e.g. £50,000) rather than a range keeps things simple. Each grade also has a large gap (~10%) between salaries. This combination keeps decision making easy - you’re not trying to justify why one person gets paid £500 more than someone else. It also makes it easier to evaluate against as you’re looking for step changes and not trying to find small differences in performance.
Don’t be frightened to give individual contributors larger salaries than team leads. They’re different skill sets, and it’s entirely possible for an individual contributor to be more valuable to the company than a junior team lead.
I typically don’t include raw output in my annual compensation systems. Doing so can lead to people getting rewarded for the wrong things. For example, someone might never help out with code review so that they look like they’re creating lots of great code. Someone else might shy away from the big hairy (but valuable) refactorings in favour of churning out lots of greenfield code. Rewarding an engineer for raw output can lead to burnout as they work harder and harder to try and chase the cash. Instead, I like to try and motivate people to work for the long term and remind them that this is a marathon and not a sprint.
In the rare event that someone has done something beyond the call of duty (e.g. they pulled all the stops out to help deal with an unexpected and unplanned urgent requirement) then I try and do ad-hoc bonuses to say thank you. At the minimum, this is some additional time off to make up for any lost sleep. I try to keep these bonuses as unique non-cash treats of relatively low value (sub £1,000). For example, I had one engineer stick around to help diagnose a particularly tricky deployment that had gone wrong, and we gave him a day off as well as treating him and his partner to a fancy Michelin star dinner on us. I like bonuses to be a unique and enjoyable experience tailored to the individual that they might not otherwise have spent their own money on.
After creating a compensation system, you need to move everyone over to it. I like to quietly phase it in for a year to iron out discrepancies and ensure it is working. I use it for evaluations and salary changes, but, not actively talk about the structure with the team.
On day 1 some engineers are underpaid according to the system, and some are overpaid.
The engineers that are underpaid are easy to deal with - increase their salary over the 12 months and give them some great news.
The engineers that are overpaid are trickier. Particularly if it’s a large gap. My first reaction when this happens is to take another look at the compensation system and see if there is a reason this person is getting paid more than they should (perhaps there was a skill that was valued and is no longer required). Overpaid engineers are also the reason for a quiet introduction of the new system. Market salaries are generally increasing each year, and this gives you a chance to give the overpaid engineers slower increases and get them in line with the new system. I have never lowered someone’s salary as this is almost certainly going to lead to resentment and them leaving (and possibly legal implications).
As with any complex system there are a lot of details and questions that arise.
Initial grading of an engineer is done during the hiring process by the hiring committee. There is an understanding that if it becomes evident that it’s way off, then the grade is corrected as soon as reasonably possible (within 3 months). Typically we see engineers underperform in interviews and need accelerating through grades rather than overperforming in interviews.
I often turn to team leads to help with grading. I ask team leads to be advocates for the engineers and come with evidence as to why their team members should go up grades.
I’m a big fan of doing grade evaluations every 6 months. If someone doesn’t quite make a grade jump for whatever reason then waiting 12 months for a bump can be a long time and lead to disgruntled employees. I’m also open to engineers going up grades at every evaluation if they’re genuinely progressing that fast (I most commonly see this with fresh university graduates that are doing lots of additional learning and putting in vast amounts of effort).
I usually go fully transparent with my teams. Specifically, every engineer can see the salaries of the other engineers (and my salary too). There is a vast amount of literature out there on why this is great and here are my top reasons:
I’ve found having a well-structured compensation system has helped me with making offers. Offers are usually framed as
“we have a compensation system to ensure people are getting fairly paid and not being rewarded for shouting the loudest. We have evaluated you as what we would call a Junior 3rd grade, and the salary for that is £X. We realise that we might have got this wrong and we do re-evaluate after 3 months to ensure that people are on the right grade. We also continue to evaluate everyone on the team every 6 months. As well as salary we offer several other great benefits…”
In roughly 95% of offers I’ve made, this has taken money off the table as something to discuss and has moved the offer discussion to more interesting things: who will I get to learn from? What team would I be on? how do I progress?
In the other 5% I’ve encountered a massive mismatch (e.g. we’ve offered £45,000, and they want £65,000). Mismatches usually happen when the candidate has a skill that the market values and we don’t (e.g. they’re a mobile engineer, and we do not need them to be a mobile engineer). I find that discussing salary early in the hiring process alleviates a lot of this.
This is particularly powerful when combined with full transparency as the candidate can be more confident that you will actually do what you say and aren’t doing some underhanded tactics.
Creating a compensation system is hard. Getting it right will make compensation decisions easier and give people guidance on how they should be developing. Often a great compensation system will be mostly painless and result in very little internal discussion around salary. You’ll have more positive conversations around how people can grow. A bad compensation system can result in engineers being unhappy and moving on to other roles.