Optimal seniority distribution in dev teams.

In the following article, http://www.lostechies.com/blogs/derickbailey/archive/2009/06/07/the-impact-of-staffing-practices-on-software-quality-and-productivity.aspx
the author propose that a senior heavy structure is desirable for an organisation.

When reading this article, I find the last line of the qoute "They found no relationship between a programmer's amount of experience and code quality or relationship" significant to the discussion, in setting the baseline of defining seniority. This should be kept in mind when reading the article. It is stated at the beginning "a person may be capable of working at a senior level in spite of a relatively short career. It is also likely that an individual in an organization may be considered senior level only by years in the industry or pay level, while that individual may not be able to work in a senior level capacity" For the purposes of discussion, a senior developer should be defined in terms of skill and competency, rather than years served. Organisations using the second definition, will likely have a huge salary bill for long-serving developers, but relatively low ouputs for those departments. Keeping those long-serving but still junior/mid developers on, is therefore an example of bad cost-benefit thinking.

I propose that having a mid level heavy distribution would be closer to ideal. This ratio better supports organisational sustainability, makes hiring easier, better supports knowledge transfer and provides a better balance between specialising and generalising.

Some mid level people can always be expected to move away from development to join management or other more business focussed roles. Such is the nature of creative people. Others will replace senior people as they move away. When that happens, they need to be replaced. Mid level developers are usually easier to replace than senior people, due to being in higher supply. It is preferable to rather replace a mid-level person than a senior person, due to the amount of organisational knowledge a replacement need to gain before being effective in their new role. When moving intermediates up, they already possess a high level of this knowledge. When consequently a new intermediate is introduced, the knowledge gain required to restore the equilibrium is spread between the two moving staff members, thereby reducing risk. Having enough juniors to be able to move one of them up, extends this benefit chain, as junior developers are even easier to replace.

Hiring senior people can be a pain. They are expensive, scarce and difficult to replace if a mistake was made. Hiring junior people can be significantly easier. There are a good supply of them (they can be sourced from grad schools) and they can be trained to fit in the organisation, or easily gotten rid of if they prove to not be up to the job. Maintaining a large pool of mid level developers can serve to help avoid the headache of hiring senior developers, provided they are of good quality and have the potential to step up. This pool, however needs to be larger, as it may take a while for the members to gain enough technical experience and emotional maturity to be elevated. If the current pool of juniors haven't got anyone ready to replace a mid level, they can still be hired from outside to replenish the pool. When hiring mid level people, recruiters have a larger pool of candidates (promoting an internal junior or hiring an external mid). Having some available for promotion will negate the need to hire senior developers, and thereby the risk of them not having a proven record and organisational knowledge.

Seniority can be thought of as a function of a developer's ability to generate and share knowledge within his organisation. The seniority of developers depend on their position on the knowledge transfer scale. Senior people will generally be able to generate and transfer knowledge down. Mid level people will absorb knowledge and add value to it, but will pass relatively less of this knowledge on. Junior people can be expected to largely absorb knowledge. Passing knowledge on is expected to carry an overhead. The overhead to transfer knowledge to midlevel people is lower than for juniors. Once the initial knowledge is transferred to the midlevel people, they can then spread it between them, and to juniors. Having more midlevel people spreads the overhead out better when transferring to juniors (who take longer to get the point.) Mid level people also seem to be more willing and able to spread and share knowledge with their peers. It also serves as an oppurtunity to identify mid level people's ability to spread knowledge, and mark them for promotion.

When referring to Scott Bellware's article on specialization vs.
generalization, http://blog.scottbellware.com/2009/03/productivity-not-bailouts.html, we can further infer that having a well-rounded balance would be the optimal position. Mid level personnel would tend to be the more general workers, while junior and senior developers tend to specialise more. Have you tried getting a senior dev to test UI interfaces lately, or a junior designing those interfaces? Mid level personnel tend to be more flexible with these kind of tasks. They may not be as productive as seniors, but certainly more willing to do the grunt work, which they can still do more effectively than juniors.

Maintaining a mid heavy development staff will therefore make it easier to "roll your own" seniors, whilst taking advantage of the relative ease of hiring juniors from outside. It better facilitates spreading knowledge, as it takes some of the pressure of seniors, while mid levels can teach each other and juniors after acquiring knowledge initially from seniors. Lastly, it gives a more versatile workforce, that prevents having a bunch of bored seniors unwilling (and financially ineffective) to clean the plumbing and can still herd juniors through uncertainty.

My first post!

For a while now, I've been nurturing the idea of starting my own blog.
Several people have influenced this decision.

Mostly, it has boiled down to outdoing some friends (you know who you are). I'll probably add them as writers for the blog, as we've been discussing setting up a blog for us to document the stuff we keep on looking for on the InterWebz (and surprisingly often seem to have to figure out ourselves.)
There has also been Joel, and his expectations of people he'd like to hire.

So now we've got the motivation covered, let's discuss the content.
This blog will mainly deal with software development. I'll probably post some solutions to problems I've encountered, small tidbits of interesting stuff I uncover, and some ideas regarding the software development process. Technical dev postings will mostly deal with C#, SQL and other Microsoft technologies.

So by now, you might have wondered about my background. I purposely keep this for last, when most people would already have clicked away, and only the very commited (or insanely completionist) is still reading this post.
I grew up in a small town, where I had some friends with a computer store. Hanging around this store fed my love for computers, and the stuff that makes them tick. After school I went on to university to do a B.sc IT, majoring in computer science and psychology (don't ask). During this time, I drank lots and had wild parties. It subsequently took a wee bit longer too finish the degree. I also held part-time positions as a sales person and later technician in a computer retail store. Geek heaven. There was a brief stint in a roadside assistance call centre, which taught me lots about dealing with Angry People. At the end of my degree, I joined a small software house, and started my career as a software developer. Which I still am, two employers later.

And so starts the chronicles of my attempts to liberate the software industry. A quest to improve the quality of our products, and a desire to share enlightenment with my fellow Code Monkeys.