A-Players, B-Players, and Avoiding Technical Debt

By On February 11, 2013 At 4:16 pm


I recently read a blog post by Cynthia Maxwell, about how important it is to hire A-players to avoid Technical Debt. She’s seen plenty of cases where founders of start-ups have recruited average and inconsistent B-players (as opposed to self-sufficient A-players) to work on their IT systems. Most of the time it results in months of re-writing and re-factoring spaghetti code – a bundle of Technical Debt that is built up and becomes hard to fix. The solution is pretty simple: make sure you get on-board the best software developer(s) you can, as they are the only ones who can provide quality code that is reliable and maintainable, and will ultimately help survive against competitors.

I understand where this is coming from – we all want to hire the best person possible to do the job, that ‘rock-star’ developer that can do the work of 20 mediocre developers. But let’s be honest… just how realistic is this? There are always going to be some B-players on the team, and yes, management’s job is to hire the right people, but I also think that they have a bigger role to play. Part of management’s job is to be able to support their employees; measuring what their employees are doing and giving them the adequate training can help them improve and will certainly help get the best out of the B-players.

Another point to bring up is: are there enough A-players to go around? This question reminds me of another blog post I read  few months ago, For Whom The Bell Curve Tolls.


This post shows an interesting bell curve graph of a population’s IQ score. The majority of the population will find themselves in the middle of the graph. The best, and worst, minority of people will find themselves on the extreme edges of the graph. The people we are most likely to recruit are the ones in the big, blue section, which are most likely not the rock-star developers that I was talking about.

So, if we know that the software developers we bring into our company are the ones that are directly dealing with Technical Debt, then management should play a role in training their teams, and be capable of measuring the IT systems these developers are working on.

7 Steps to Pay Down the Interest on Your IT Technical Debt
Learn how to handle “Technical Debt”

In 2011, there were more IT system failures, outages and data breaches occurred than any previous year since the dawn of the age of technology. And while some of these issues could be traced to intentional and malicious undermining of systems, many, if not most, had some measure of application software failure or weakness at their root.

Your Information will be kept private and secure.

Add your comment

XHTML : You may use these tags : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This is a Gravatar-enabled website. To get your own globally-recognized avatar, please register at Gravatar.com


  1. I agree. Only companies in Lake Wobegon (where all the children are above average) and those with real cachet can hope to find enough A-players. I’m interested in a more practical solution based on understanding the differences between them, so that we can figure out the best possible training for the B-players to raise their game.

     — Reply
  2. A week later, Google upped the ante. The company put a free Android software developer’s kit on its Web site and announced the Developer Challenge, with $10 million in prize money to be parceled out to the creators of the best applications for the new system — a great social networking tool, say, or a handwriting recognition program. The Challenge was an open call; anyone was invited to take a shot.

     — Reply