We think we want to employ the "Rockstar" developer. We want the superstar. We actively recruit for it - we even put it into the job adverts. But is the "Rockstar" good for ROI? In this episode, I discuss why I believe they are actually the reverse - they are "Bad for ROI".
Or listen at:
Published: Wed, 18 Nov 2020 16:53:24 GMT
Transcript
[00:00:36] Hello and welcome.
[00:00:39] In this episode, I'm going to continue my Bad for ROI miniseries. This little miniseries looking at subjects that, on the face of it, are great for ROI. They look like things that you want to have. But when you dig a little deeper, you find that actually, no, they're actually counterproductive. They aren't producing the results that you want or desire for the longer term.
[00:01:01] In this episode, we're going to look at the rock star developer.
[00:01:06] Let's define our rock star developer. It could be called a rock star, a ninja, hero or even 10x developer. These are individuals that are perceived to have so much skill that they stand out well above their peers. They're almost legendary in their capabilities.
[00:01:26] Last year, we also then got the concept of the 10 x developer, something off the back of a tweet where someone was saying basically that there was this rare breed that basically was 10 times your average developer. They were that good and that they were critical for you if you were in a start up position. They increase the odds of your Start-Up success significantly, they say.
[00:01:52] The tweet actually went on to list 11 characteristics on how to spot a 10x developer. Now, unfortunately, this tweet was actually largely lampooned and ridiculed by the software development community in general. A lot of the things that were suggest weren't actually appropriate for a good developer, and some of them are anecdotal, some of them are actually dangerous.
[00:02:16] So I personally take the idea of a 10x developer and how to spot one somewhat with a pinch of salt.
[00:02:24] But whatever you call them, they're seen as a valued commodity. They're seen as potentially holding your entire organisation together. They seem to do the work of an entire team. They are the person you go to to get stuff done. They're meant to fully understand the system. And they have full control over it.
[00:02:45] The idea that potentially there is this individual that is almost godlike status within the software development team.
[00:02:55] I'd like to take a little bit of time to talk a little bit about my own personal career. I would have said there were times during my career where I probably met the ideals of that rock star, that ninja, that hero, maybe even that 10x developer. In terms of how I worked, I was very much, and have been and continue to be, someone that can do many things across software development - probably more than most in terms of the breadth of my technical capabilities.
[00:03:25] Am I the best software developer? No.
[00:03:29] Can I do things that other software developers can't? Generally, yes, because I've got a breadth of experience across multiple disciplines.
[00:03:37] Does that make me the person you want to just go to and say "Mark, do this for me" and rely wholly on me? No, really not.
[00:03:46] It's not the best way doing it.
[00:03:47] But I would say that my personal career has greatly benefited before, and getting to me to the stage where I am now, from having held similar types of roles in the past.
[00:04:02] So let's talk about the perceived benefits.
[00:04:05] For the business, this seems like a really good thing; surely we're getting more bang for our buck. Surely this rockstar developer, if they're so much better than everyone else, then if we're paying them the same, we're getting a lot more output. That's an easy one to understand.
[00:04:22] And at the individual level, having that hero status, can feel very appealing. It can feel very gratifying to be held in such high regard by the business. To be treated in that almost, as I say, rock star status.
[00:04:41] And again, I talk previously, I've been in that position. And it is very, very addictive.
[00:04:47] It's very addictive to both the business and the individual.
[00:04:52] And you then see it creeping into recruitment, some recruitment. You actually see adverts going out for "We're looking for a rock star developer", "We're looking for a hero developer", "We're looking got a ninja".
[00:05:05] These are all terms that are seeing the way through, which don't really mean anything.
[00:05:11] So let's talk about the downsides.
[00:05:14] Obviously, I've talked about the perceived benefits and you may be thinking, hang on, this sounds good, both from the individual developer and from the business perspective. So what's wrong with it?
[00:05:27] Well, in short, no man is an island, nor should they be.
[00:05:34] We should really be thinking about teams. We should really be thinking about the capability spread across more than just a single individual.
[00:05:42] And that's the danger that thinking about a rockstar developer, ninja, hero, 10x developers brings. You were saying that this person is so much greater than a team, they can do all the work.
[00:05:57] And with that, you then bring a huge level of risk
[00:06:00] You'll bring in the level of risk that that individual is the right person in terms of their capabilities. As working as an individual, largely because they're rock star status, how do we know that they're doing things correctly?
[00:06:14] They haven't got the shared experience, knowledge and just the ability to question and review as a team. You have to think about whether you're going to get the right level of quality? Whether they're going to think about all the security things? You've got to think about, are they really looking at everything they need to? That a team is so much more able to do than just that individual developer?
[00:06:39] Plus, of course, you're down to having that single individual, which is obviously a huge risk in its in its own right. If that individual leaves for any reason, or is sick, or is unable to attend work. Suddenly there's so much knowledge and capability locked up in that single individual that you could be in a position where effectively your business stops because nobody else knows how to do what they do.
[00:07:05] It also doesn't scale. Having a rock star developer does not scale.
[00:07:10] Normally if you get multiple rock star developers, yeah, they can work on separate things out their own way, but they don't scale whereas you can scale a team.
[00:07:19] And if I'm honest, a team will always be better than an individual rock star developer. I will take an individual team every single time.
[00:07:32] And there also has to be a level here thinking about your obligations as a business to that individual. You've got to think about their individual health, the danger of burnout, the danger of them over-committing and actually making themselves ill by virtue of this. Rock star status. Of being a central point of everything coming to them.
[00:07:58] So as a business, you actually also have that moral obligation not to put everything on that single individual.
[00:08:07] Are there any benefits from it? Obviously it perceives to looks good, but I've talked about how there's a lot of downsides there and how personally I really wouldn't recommend it.
[00:08:16] So are there benefits? Yes.
[00:08:21] It was possibly easier for me here to actually say no, but it wouldn't be true.
[00:08:26] There are times where you could benefit from having that rockstar developer in place. Now, for me, normally these are things that have very short term goals, very short lived pieces of work.
[00:08:40] Such as maybe prototyping a system, something that they can prototype out very quickly, maybe at most, maybe a couple of months work something that effectively you don't see as having a long term life in its current form.
[00:08:54] It's just a let's get it, see what it looks like.
[00:08:58] Sun-setting is another possibility. Actually, it's a role I'm involved in now, where due to my level of knowledge across many multiple disciplines, I'm actually doing the work of maybe a team in sun-settings some critical systems for for a client. Because I have that level of experience, I can do what otherwise they probably need the team to do, which, given sun-setting, is hardly the most exciting or sexy piece of work to do, they struggle to retain that team - thus have someone in.
[00:09:33] However, in both those examples, both the prototyping and the sun-setting, you're running a gamble, you're very much assuming that there is a finite end to that piece of work.
[00:09:44] What happens if that prototype looks really good and we want to take it forward to an extend? What happens if our sun-setting for some reason has to continue? We're back to that thing of over-reliance on a single individual.
[00:09:57] So I'd be very cautious of knowing that if you do go into it, you're taking a level of risk and you have to balance that risk with the trade offs that you could potentially get as rewards.
[00:10:09] If I'm being honest, I certainly recommend you don't go down that route. I'd recommend using a team structure rather than actually looking for this rock star developer.
[00:10:20] The problem is it is a trap. The rock star developer can seem very attractive to a business. It's a great way of potentially getting more for your money. It feels as if it's a great revenue piece. It's great for our ROI. It's also attractive to the individual. It's that high level of status that benefits that go with a higher level of status.
[00:10:42] So for me, it is a trap and something you have to be very careful in avoiding.
[00:10:49] In this episode, I've talked about why I think the rockstar developer while can seem to provide a lot of benefits, those benefits are greatly outweighed by the risk.
[00:11:01] Personally, I would always favour a team over an individual because of those risks. It doesn't give you a lot of options if something goes wrong with that individual, unfortunately.
[00:11:13] That concludes this podcast. Thanks very much for listening. I look forward to speaking to you again next week.