Beyond Code: the Real Value of a Software Developer

"Andy is about four times more profitable than Eric," my friend said. That felt like a bombshell. Having worked with both developers, I really preferred Eric. Given the choice, I’d take one Eric over ten Andy's any day.

My friend ran an agency providing software development services to small and medium-sized businesses. He employed both developers. I had worked with them in the past, on occasion.

It was in such a situation that I first met Andy
I was the client's freelance CTO, managing the project. Andy was one of the developers. I instantly liked him. He was a fun, charismatic guy who could brighten the room and make everyone feel good about themselves. His social skills were excellent.

After several weeks though, I got a feeling he wasn't really pulling his weight. When reviewing his contributions, there was no doubt that this was a waste of my client's money. And as this was the kind of situation my client counted on my expertise for, there was only one thing I could do.

I asked for Andy to be removed from the team
And that didn't go well. My friend was p*ssed, as he was the one who had introduced me to the client in the first place. But I had upset everyone else too, and there were even rumours that I was jealous because I wasn't as popular as Andy, etc.

I was afraid I'd killed the team spirit and the project with it, but instead, I learned how powerful a common enemy can be. I just hadn't ever expected myself to be that common enemy.

But, after the initial anger wore off, I talked things out with my friend, and we even got into the habit of meeting up for beers or lunch a few times a year.

It was during one of these lunches I learned that Andy was still employed with my friend
I was shocked. I assumed that after 'exposing' Andy a few years earlier, he probably got fired because that's what I would have done.

It was even more surprising to hear that Andy was his most profitable developer.

"About four times more profitable than Eric", his most skilled developer
I had worked with Eric, a competent guy, one of the best I have ever worked with.

For a moment, I thought my hearing or his judgement was clouded by the strong Susumaniello wine we had with our lunch, but he went on to explain.

"First, you have to understand that Andy and Eric are on the extremes of the spectrum. The rest of my people fall between these two, but comparing Andy to Eric will clarify my point. So, you know I pay Eric more because he's a very skilled senior, which means he also has a high day rate. I don't have to tell you that."

"But a client, without an understanding of software development, tends to focus on the day rate. They often think they're doing a deal by paying less for a junior instead of a senior. "

I nodded, "that's a classic."

He continued: "I know the 'return on developer' for each one of my people. It's hard to evaluate individual efforts in a team, but it becomes more evident when I send someone solo for smaller jobs or maintenance tasks.".

 He sipped his wine.

"For the same workload, Andy might take four to five times longer, often including the need to revisit his work afterwards. Still, somehow, customers tend to be more satisfied with Andy's results, charmed by his confidence and demeanour. They feel that he's one of them, he's on their team."

"In contrast, Eric is a far more efficient developer. And you like him because you guys talk on the same level and you respect each other.  But customers often just don't understand what he's saying and think he's rather dry and distant... he doesn't really make them enthusiastic". We both laughed.

He leaned forward and whispered. "And all of that wouldn't make much difference if I had an unlimited amount of incoming work, but since that's not the case, I have to optimize the conversion of incoming work into profit. That's why I'd rather have more Andy's on team instead of Erics: it takes him longer, I make more profit."

BOOM. Somehow, I'd been totally oblivious to this. I guess that's what they call a paradigm shift. Or just plain naive.

"And yes, sometimes a customer gets upset because Andy takes too long and can't make things work, and then Eric takes over. Eric will probably do a rewrite, but that's OK since he works far more efficiently, the customer doesn't need to know, and of course, his time will be billed as well."

He continued: "And you know, I'd like to find more people like Andy. But people with such social skills and confidence are snapped up by the larger consulting firms. And I can compete with those guys when hiring an Eric, but an Andy? Much harder, they prefer the glamour of one of the Big Four instead of a small unknown agency."

BOOM again.

What developers do you need, Erics or Andy's? 
Is there a healthy balance within your team?