How to Shampoo Your Employees

I joined the Israeli Defense Force in 1997 and served the mandatory three year period as a software developer. Army service usually consists of three* phases: first year - you learn the ropes, second year - you get things done, third year - you teach the new guys.

The Hebrew term for this period where the veterans teach the newcomers is called "the overlap", which, incidentally, is exactly the same Hebrew word for "shampooing". Don't ask me why. It's weird. So the veterans shampoo the newcomers and thus the wheels keep rolling from year to year.

Something similar happens in software companies. The term "training period" doesn't really capture the essence of what really goes on. Newcomers are often extremely well trained at their job already and all they really have to go though is a getting-to-know phase. Getting to know the product, the team, how things usually work. You know, shampooing... English speakers, I suggest you adopt this term.

One problem that plagues many software teams is knowledge hoarding. You all know someone like that. Someone who really loves being the most informed. Some veteran to whom everyone comes with questions. I guess some people think that makes them more valuable. I think they should be fired as quickly as possible because I've yet to see someone like that actually mend his ways. 

The perfect team player, on the other hand, is someone who's powerful, effective, but also completely replaceable. Like a CPU core. Your machine has four of them. They're expensive and they get things done. But lose one of them and your computer will keep on going, just a little slower. There's nothing it won't be able to do with just three cores, and when you plug in a new one things will go back to normal. 

Now here's the secret for ultimate shampooing. 
Ready?
Take the third year and the first year and squish them together. In other words, when a newcomer arrives on the scene his first order of business is to write the shampooing plan for his replacement. If one was already written, he can improve and augment it as he picks things up. 

That's a great general principle, and it applies not only to newcomers, because in our line of work we constantly learn new things. Keep nothing solely in your head. Be mindful of what you learn, and document it in a discover-able, public way. Not only the idiosyncratic quirks of your project, but also tricks of the trade, theoretical knowledge of the problem domain, mapping out who knows what and where to find stuff. Everything. 

Gigantt has recently recruited a QA manager. Until now the QA team had to deal without one. His first job is to write our QA Manager Handbook, which ought to include 100% of what his successor would have to read in order to get going. Being completely replaceable as a team member almost makes you irreplaceable, because so few of us are actually that minded towards knowledge sharing.

_________________________________________________________

* Actually everything in the army consists of three parts. It's... exhausting.