Tuesday, July 18, 2006

Boy Scout Capabilities

I was having a conversation with a co-worker today whose first name prominently features the letter "Z". Our topic: how does a company like ThoughtWorks, which hires lots of experienced developers, determine at what level that person should be hired. Some candidates are cut and dried: you can tell when you interview them. But what about the developers who fall through cracks? Maybe they are an ace developer in 4 languages, but they've never done agile. Or, a great militant Agilist, but they have never done test-driven development. As a company, we need 2 things: how to categorize these folks upon hiring and, more importantly, how to fill in knowledge gaps after they arrive. After all, the ultimate goal is to create well rounded ThoughtWorkers, who are good at all the things we value highly.

In talking about this subject, I came up with the idea I called the Merit Badge approach. Just like in the Boy Scouts, when a scout moved from one troop to another, you knew their rank instantly because of the acquired merit badges. Each merit badge had deterministic acceptance criteria, and you knew that the scout in question had mastered the badge criteria before moving to the next one. A certain number of badges, covering a certain set of areas, lead to increased rank. If a company like ThoughtWorks wants all Eagle scouts, we must invest in our rookie scouts to enable them to get to that level. We should have technology merit badges. If we get a good candidate that knows everything but TDD, we should send them to a TDD training class or similar until they have mastered that skill. Advancements in the technical ranks becomes an exercise is acquiring useful skills. That keeps the process more objective and allows for clear ascension paths through the technical ranks. The People People can track the merit badges and recommend training and mentoring for the next milestone.

And, we'd all get to wear those cool sashes!


anonymous z said...


~ anonymous z

Gayle said...

Merit Badges sound like a great idea. But how would you determine a person's competence in a particular area in the corporate world? This may be what certification exams are "supposed" to determine. But we all know that some people are better at memorization than others, and that doesn't necessarily show competence. :)

I still struggle with how to go about interviewing potential candidates for a company, especially in IT. Some people are smoother talkers than others. With that comes people who can talk the talk but can't walk the walk. With that also comes a few people who can walk the walk but not talk the talk. So how can you really tell how competent someone is until after you hire them and work with them for a few months?

If we all could wear our sashes to interviews that would be sweet!

Buster Billy said...

Aside from individual topic recognition, how is this any more beneficial than certification programs?

Is this part of your current culture? Are your cubes decorated with conference name badges?

Neal Ford said...

Most of the certification programs I've seen are not very good. I had a smart friend who studied for 2 weeks and passed the J2EE certification test after having never used Java before. Conferences won't do it either.

Like the Boy Scouts, you need real testing, not just a multiple-choice test. Tie a knot, don't choose the correct answer on how to tie a knot. Actually, PowerBuilder used to have a really good certification program, where you had to pass a test and defend an application you wrote. Alas, no one wants to put that much effort into it these days.

This is a future-state thing I'd like to see here at ThoughtWorks. We have a really rigorous hiring process; I'd like to see more formality around earning merit.