There was a tweet about how tech companies measure people by the impact they make. I replied in the common terse Twitter way, and I want to expand on that here. I think that there are few different ways in which someone can add value in a software development team, and they’re not all equally easy to spot, which can be a problem.
I’ll start with a couple of obvious ones, and then move onto two that are less obvious. I expect that there are many others that I haven’t thought of. I’ve done Belbin team analyses in the past and found them useful, but I won’t be going down that route in this article. There’s probably some overlap with Belbin, but hopefully enough that’s not to be potentially interesting and useful.
Obvious way 1: The builder
This is the sine qua non of software development – creating things that didn’t exist before. A programmer creates or changes software, which results in the user being able to do things they previously couldn’t. It can generate passing automated tests that light up green, extra revenue for the company and other nice things.
It’s not just programmers who build things – a tester could create a test strategy, a manager could create a new recruitment policy, a product manager could write a user story etc. Something exists today that either didn’t exist at all yesterday, or was different yesterday.
Success here is in the thing being created, and so is obvious and at least some of its value can be judged immediately.
Obvious way 2: The firefighter
There’s a problem (a fire) and the firefighter fixes it. Production is down, a major customer is unhappy, the build is broken etc. The firefighter fixes the problem. The problem is big, obvious, immediate and painful.
Success here is getting back to at least how things were before (possibly better, but that’s a bonus), as quickly as possible. We’re not creating new stuff, just getting rid of a problem with existing stuff.
The problem with firefighting is when it’s expected. A fire that needs putting out shouldn’t be normal, and so too many fires should be a sign of deeper problems elsewhere. This is where gardeners and goalkeepers might come in.
Less obvious way 1: The gardener
There are two aspects to draw out here: one is creating a good thing, and the other is dealing with a bad thing.
The first aspect is gradually growing things. Each one act doesn’t have an immediate enormous difference, but over time they accumulate. Also a small act now can yield a greater return in the future. This is things like each respectful interaction with team members, that builds a healthy team spirit. Or gradually working through a code base that has no unit tests, adding unit tests as you open a file to change it. Or mentoring someone, so that they can do more in the future.
The second aspect is weeding – snuffing out problems when they’re small and so not painful, before they grow worse. There are a few different versions of this. One is things like code review comments, that stop bugs making their way into production. Another is the quiet word to say “What you just said is out of order”.
The problem with both of these is that, while the eventual impact can be large, each act is small. Plus, in the case of weeding, the impact is in the size of the bigger problem that never happens.
Testers are, among other things, the spotters of weeds. (They don’t get rid of them – that’s the programmers’ job. They don’t declare that there are too many weeds – that’s management’s job.) If you always know where weeds will grow, what they will look like and so on, then maybe code can take the place of people in the looking for weeds. But code won’t catch weeds that grow where you’re not looking, and by the time they’re spotted they could be big. Also people can spot where things are missing – an unexpectedly bare patch in the garden – which is something that’s hard to get code to do in general.
Less obvious way 2: The goalkeeper
This is similar to the weeding aspect of gardening, and to firefighting, but different enough to be its own thing. There is a clear, big, painful potential problem, and the goalkeeper stops it from becoming an actual problem. It’s like firefighting in that it’s clear and (hopefully) uncommon. It’s like gardening in that the big actual problem hasn’t happened yet, and hopefully won’t happen.
This is someone who has remembered to make and test back-ups of key systems, so that when the system crashes or is corrupted, it turns into an inconvenience rather than a disaster. More generally, it’s thinking of a Plan B (restoring from a backup) rather than assuming Plan A (the system will run OK forever) will be fine.
It’s also the big end of review comments, such as “If we put this into production, the system will crash. I think you need to do X instead.”
There are several dimensions to someone’s impact, such as:
- Are they creating a good thing or avoiding a bad thing?
- Is the value now or in the future?
- Is the value directly from them, or via their impact on other people?
- Does it affect something in the physical world (including things like code, policies etc.), or stuff inside people’s heads?
- Is the value concentrated into one activity or thing, or spread over many activities or things?
Not all combinations of these are equally visible, which means that people assessing someone’s impact might have to work hard to have a true measurement.
Also, code isn’t always a good substitute for people. Reviews for trivial code changes are probably a waste of time and so relying on e.g. unit tests makes sense, but in general reviews can be a way for people (the reviewers) to contribute their value. Similarly, testers who are allowed to be people rather than robots (they’re not limited to following detailed test cases) can contribute value too.