What is a developer worth?

ORIGINALLY WRITTEN JUNE 2016 — Found this in my drafts, had written this when I was working as the Head of People, Engagement, and Training at Prismatik. Not sure why I never finished it. I’ve left it as I wrote it then, and I’ve added commentary from present Jack in italics.

The software industry is booming, and we have an ever increasing gap emerging between the supply and the demand. It’s not enough to have a developer that works on your one system anymore. Today even small companies have multiple systems, each using a particular kind of technology, and they need to work on multiple platforms. These days a basic software solution requires an iOS Developer, an Android developer, a web developer that knows your particular front-end stack, and finally another web developer that knows about the programming language of choice on the backend, and your array of build tools, deployment tools, and databases. If you’re lucky, you might find one of the unicorns that can do two, if you’re even luckier, three of those things.

The endless list of questions

Just finding a developer that can do the commercially valuable work you need them to is just the first problem you need to solve. Once you have found someone with the skills you’re looking for you then need to work out more things about them:

• Will they help or hinder future hiring
• Will they work efficiently in different sized teams
• Will the work well with other roles within the company
• Will they work well with potentially future roles within the company
• Are they responsive to change
• Can they learn quick enough for the pace of change you expect

Present Jack: I look back at those first three points and I will never be able to stress enough the damaging effect and the direct results someone has on the bottom line if they can’t pass those first few tests. It seems to get more and more true as the years go on. Sometimes you will need to compromise but in those cases don’t make a long term commitment to people that can’t meet those.

These are just a few of the things you need to consider, then once you’ve worked out the answers, you then need to take any of those potential risks and weigh them up against the primary goal of delivering revenue generating work and how they fare against other candidates (if there even is any). All that needs to happen before you even ask the tough question of how much you should pay them!

Long story short, hiring is hard. In a developers market where they hold much of the power, how do you make rational decisions about what to pay them?

Paying by delivery

In a perfect world, you could gauge how fast a developer can work on features of your app, this method would work better for raises and salary renegotiation. Each feature has a reasonably estimable value associated with it. This makes it an easy thing to measure then. You only have to add the value to each part of your product roadmap, estimate what percentage of that roadmap the developer can deliver each month. People have been doing this for decades, speed to producing revenue-producing work has long been a measure of repetitive work, and that’s what developing software is right?

The most glaring issue with this approach is the oversimplification of how much time it takes to deliver value. It assumes that all items on a product roadmap are created equal. It’s not uncommon for a small task to delivery 100x or more value than some of the complicated items on your list.

Present Jack: I’m surprised I didn’t mention this when I originally wrote it but “takes time to deliver value” isn’t just about the immediate work, we all know codebases are an ever evolving beast, the value of someone’s work can pay off again and again and again in some cases, and can become your worst nightmare for the longevity of your codebase in others. Value isn’t realised at delivery.

That’s not the only issue. Some developers will be able to come up with fast, creative solutions to complex problems. Because this is statistically a random occurrence, there is no way to estimate that in your roadmap. The inverse of this is also possible, it’s entirely possible that choosing the wrong developer for an individual problem will result in it blowing out to a ridiculous timeframe. In this situation, it can effectively make a developer, technically, worth a negative amount. You can’t accurately take those two randomly occurring conditions into account when trying to measure a developer’s value.

It also completely ignores many fundamental values of being a developer.

A developer is a sum of its parts

When you’re a developer your life isn’t about how many lines of code you can write, it’s made up of many more parts. Lots of developers spend a significant portion of their personal time creating value in many other ways.

• Upskilling — In a fast-paced industry like software development, all it takes is the release of one new thing to make a set of skills functionally obsolete so we have to be constantly on the cutting edge
• Sharing — Like chefs, a common path to fame is not through keeping secrets but by sharing everything you do, so we talk at meetups, write blog posts, make screencasts, and write code that is available to everyone
• Problem-solving — After becoming a developer, you see the world in a new light, everything is a problem that can be solved, something that can be automated or codified, so we tackle the ones we see a lot in ways we can reuse so it’s solved and doesn’t have to be solved again

When a developer becomes aligned to your goals, your strategy, they become a huge asset. Not only will they now become focused on improving their skills on what is best for you, but just by mentioning what you’re trying to achieve you’ve put their brains to work coming up with creative technology based solutions. The intimate knowledge they already have about all the wonderful things computers can do can be combined with intimate knowledge of your business if you give it to them.

Present Jack: Looks like I finished off here, and I didn’t really talk about how to measure these things. Developers have a core skill, building software, but their performance in that is honestly easily reflected by everything else they do. If you’re doing quantitive reviews of your devs (which I suggest you do to keep it fair, and to review that system constantly for biases) you can use qualitative data from their community efforts, curiosity and explorative nature, and by working with them to solve the abstract problems we face.

Present Jack comes up with an ending

Well this is 2018 Jack now, it was interesting reading back through this half-finished article I wrote back in mid-2016. I remember why I was writing it though. Internally we were discussing how to measure the value of developers and generally all staff where I was working. Finding a way to fairly decide on raises was the biggest thing we were trying to work out. I still don’t think including all this is enough, whether we like it or not, the salary we provide to someone is an easy measurement of how we value them within a company and raises are a direct reflection of how we are saying they’ve progressed since the last one. You should always be working on the way you measure your staff. Looking for new ways people are adding value, looking for biases that make it unfair for some people, weighting parts on the companies situation, do you need to put more weight on the short term or long term value your staff are creating. It’s a difficult thing, but that’s not an excuse to avoid making it brilliant.

If you like my way of thinking and want some help working out your system get in touch. Also consider following me on Twitter and here on Medium.