Building a Balanced Team

Fred George, noted Agile Developer and thought leader, had a great post where he described his ideal ratios of developer skill levels when building an Agile development team.

One of the foundations of his theory is that the number of Apprentice or Junior level developers should remain small on any given team.

…bring on apprentices only at the rate they can be productive to the team; otherwise, be courageous and defer the staffing, ignoring what your spreadsheets are telling you.

I can certainly identify with Fred’s warnings here as I’ve had the unfortunate experience of working in a shop which built upside down teams with one skilled senior developer managing 5-7 fresh college graduates underneath them.  The net effect was a very buggy system, poor productivity, and continuous death marches between releases.

As many others have said before, programming is a skilled craft, and thus must be treated as one.  While it’s true that almost anyone can learn to hack together some working code, true mastery of the craft requires learning under existing masters.  And for a master, training even one apprentice requires a significant time investment that can often come at the cost of productivity.

In my current role at Telligent, I’ve had the good fortune of working with a very talented Junior Developer and I’ve enjoyed helping him go from being a good programmer to being a great developer.  However, it’s been quite clear to me that having more Juniors on my team would quickly overwhelm me and begin to adversely affect my team’s productivity. I would probably be spending more time on mentoring them and less time on knocking things out of my own task list.

Even the brightest Juniors will not be aware of all the tools, resources, and practices that are at their disposal as compared to a more experienced developer.  In summary, Fred George said it best:

…start your projects with few, if any, Apprentices, and stage them into the project at the rate you can productively absorb them.

I highly advise that you read the rest of Fred George’s posts in his series on Masters, Journeymen, and Apprentices.

Are you an Overpaid Payable?

I spoke with a friend the other day who came to the startling realization that they had become overpaid.  Most people would define being overpaid as receiving a salary above the current market standard for your responsibilities and skill set.  Taking a moniker from a company which shares an office in my building, I have decided to call such an individual an Overpaid Payable.

An Overpaid Payable is a resource whose cost to an organization exceeds the value that the resource provides back to the organization.  In the current market for software developers, the danger of becoming an Overpaid Payable has become greater than ever.

There are many signs that you are being overpaid.  Here are some:

• You have been in the same company with no increased responsibility for 3 years or more despite receiving regular salary increases.
• Your job very often requires long, inefficient and wasteful hours but you are paid handsomely to compensate for the poor planning that keeps you at work late nights and weekends.
• You see high turnover in your company and often see across-the-board increases handed out soon after a few indispensable resources decide to leave the company.

So what’s wrong with being an Overpaid Payable?  Being overpaid leaves you vulnerable.  It can give you a false sense of security as you build up your lifestyle around your current salary.  If you can’t guarantee this same salary in another, very similar job, then you will have difficulty planning for the future.  Nothing is certain, and if your company is bought out or goes through cost cutting layoffs, it is the overpaid employees who are usually the first to go.  Additionally if you ever really dislike your job, your choices are more limited.

If you’re reading this and thinking that you are overpaid and are now stuck, all is not lost.  There are many ways to fix this situation.  The most obvious one is to just leave your current job to take whatever you can get on the open market.  However, this may not be realistic depending on your financial responsibilities, so I would advise finding a way to increase your value while staying in your current organization.  Here are a few ways that I have seen work.

Learn more about the industry you support to gain new responsibilities.  If you write financial software, take the existing financial knowledge you’ve acquired and improve upon it.  You may find yourself managing a team of new hires with lots of technical knowledge but no industry knowledge.

Build and market your expertise around a product or technology through peer groups.  Being recognized as an expert in your field bestows many benefits, including competitive and repeatable salaries.

Use your existing knowledge to add value to other functions of your business including sales, services, and support.  Your existing knowledge can provide a lot to these other areas in many surprising ways.

In summary, the best way to avoid becoming an Overpaid Payable is to constantly grow your responsibilities and skills to match your salary.  Always monitor your yearly salary increases to see if they come with increased responsibilities and skills.  Undoubtedly, you will have slower years and faster years, but if you monitor your career diligently, you’ll never need to worry about becoming overpaid.