Seniority vs. Experience

An interesting point I recently came up against in our hiring; we have a reasonably healthy balance in the team at the moment but, if anything, it’s a little light at the top end.  We thought we should be looking for more senior engineers but actually it turns out we’re really looking for more experienced engineers.

The difference?  A senior engineer is able to build very large, highly complex applications but an experienced one realises that this is a bad idea…

SCRUM Master Job Description

As we become more agile I’ve been going over job descriptions in the engineering organization, making sure all the duties are optimized as we change how we deliver software – one of the key roles being SCRUM master.  There are a whole lot of basics that go into this specification; such as facilitating the daily stand-ups and maintaining the burn down chart – easy – but how do you capture the essence of the role?  I took a look around to see what other people are hiring and came across this on Agile in Action:

“A SCRUM Master is like a conductor coordinating the efforts of musicians, helping them to play together. Some teams are like jazz bands, so they need a leader who encourages improvisation. Some teams are like symphony orchestras, so they need a leader who keeps everyone on the same sheet of music. Conductors have to be deeply familiar with each instrument and with the music, yet they don’t play in the band or tell the musicians what to do. They let the music provide detailed guidance; their job is to bring out the best in the musicians, both individually and as a group.”

We currently share this kind of flexible, adaptive leadership between SCRUM masters and the team’s manager (loaded to the management) but it does make sense to push more of this closer to the people that make our product happen.

Around the World in 80 Releases

Recently I struck out across the globe to set up an offshore development center for my company.  It was a whirlwind of travel and expense accounts (those who have done this know it isn’t as glamorous as it sounds) but I think I did it well under the benchmark set by our friend Phileas Fogg.  Who’d have thought a jumbo jet would be quicker than a hot air balloon?  Our [carefully selected] final resting place was Romania and lately a lot of people have been asking me why…

To properly answer this question it is necessary to understand the business problem that called us to action in the first place; delivery bandwidth.  Our product people were having to delay (or worse still not do!) good projects with qualified revenue streams because we simply had more ideas than we could deliver – we needed to cost effectively scale our engineering organization to match this appetite.

People often equate ‘cost effective’ with ‘cheap’ but this isn’t really what it means to me – cost effectiveness is a measure of value for money.  You need to consider the quality of what’s being delivered compared with the investment you’re putting in and quality was where it was at for us.  You see, we have some hard problems to solve in our system:

• over a million users spread around the globe (scale)
• processing more transactions per day than all European stock exchanges combined (TPS)
• serving over 3 billion page requests per week (performance)
• continuous product innovation with tight time-to-market (feature velocity)
• 24x7x365 demand with a 1-second transaction SLA (quality)

We couldn’t meet challenges like these using the tried and tested corporate approach [insert favorite offshore location here] as these high-churn environments don’t tend to foster the kind of creative talent we need or give us the foundation of domain expertise only experience can yield.  That said, the old school works extremely well for building good quality commodity software – our problem is we’re anything but off-the-shelf!

Romania provides an excellent pool of talent with favorable economics, it isn’t the cheapest place but it does have the best balance of cost vs quality.  Developers (even recent graduates) have a base of solid skill to build on, show ingenuity, potential and a strong desire to learn.  They tend to be passionate about technology and unafraid to challenge themselves; not just wanting to deliver systems and functionality but to do so by employing new technology and practices – this last one is particularly important for technology companies as it gives you the edge.

So far our theory is sound and we have some impressive results to look back on but, as they say, watch this space.

Assessing Developers

When hiring software engineers there are always two primary things to look for; skill and quality.  Skill being a measure of practical ability, here and now and quality being one of potential.

Skill is easy to pick, it’s quite an objective property and the world is full of tools to help you judge it.  You can apply all sorts of tests and peer reviews, study examples of previous work and of course there are many standard industry qualifications.  Being quite tangible and largely merit-based it’s also easy to benchmark and rank – conversely it’s much harder to say with certainty one individual is more imaginative than another.

Quality is harder to spot but of more long term importance.  Quality engineers are imaginative, passionate about technology, creative, active in the technical community and hungry for knowledge.  They’ll push you for training, challenge ‘how things are’ and go the extra mile.  They’re valuable employees no matter what level of skill they have when you take them on – as long as you can provide the framework for their personal development.  High quality people will always end up highly skilled people.

A good practice is to arrange your recruiting process so that you’re only ever selecting from people with, or close to, the skill level needed for the role.  If you’ve got efficient filters early in the process (and you trust the results!) that leaves you free to make a strategic hiring decision while still getting what you need today.

So are you better off with skill or quality?  Hopefully you won’t have to make that tradeoff but real life being what it is, my money’s always on quality.