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

By Alexandra Szynkarski 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.

FREE Report: How to Monetize Application Technical Debt — Gartner & CAST
A Data-Driven Approach to Balance Delivery & Agility with Business Risk

Technical Debt has been growing exponentially as maintenance is starved and development teams are forced to cut corners to meet increasingly unrealistic delivery schedules. CAST clearly defines Technical Debt so it can be measured and then juxtaposed with the business value of applications to inform critical tradeoff between delivery agility and business risk.

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