It’s been a while since I’ve posted. What percentage of my posts start out like that? It must be close to a hundred percent, at least in my mind before I start typing. Well, its March already, so too late to make that a new year’s resolution. Maybe I can make it a part of spring fever. We’ll see what happens. On to the task at hand however.
Prepare yourself, because I’m about to enter the realm of pointy haired thought and discuss something a manager would talk about. I know this isn’t my normal geeky train of thought, but I thinks its worth visiting from time to time. I’ve had this idea for some time now about the assignment of tasks and how it relates to what I like to call the Myth of the Nazarene Welder.
Whether or not you agree in principle with the religious affiliation, you are most likely at least familiar with the vocational endeavors of the most renowned personage from Nazareth. In case you are not, I’ll give it to you straight. Jesus was a carpenter. We’ll now set aside all further mention of religious figures and talk about carpentry.
When I was growing up, there was a period of several years when my father, who is a petroleum geologist, used to make yearly trips to Singapore and Malaysia for business. He would return with some fabulous local souvenirs and art pieces, which included some amazingly intricate carvings in some exotic species of hardwood. I remember thinking how much skill and time those must have taken to create. Similarly, I recently attended a display at the local university’s art museum by a local artist, Andrew Smith, and his father called “Poetic Kinetics“, which was a fascinatingly elaborate display of mechanical pieces that basically consisted of a bunch of scrap metal cleverly welded into moving sculptures. Both of these works demanded my artistic fascinations. Imagine for a moment however, that these two artists were to swap mediums. I’m sure to some extent the results would be similar in their level of detail and artistic nature, but I imagine that neither would have found its way onto my mother’s mantel or the floor of a prestigious art museum.
What is the moral of this story then? Let people do what they are good at. It seems to be fairly popular in alot of organizations to try and “let people experience different things” and “increase their skillset” or “become familiar with other parts of the system”, which I am certainly not against, but too often I think it is taken too far. It’s too much like asking a welder to build a set of stairs…out of wood. He’ll always be one step behind…like a welder building a set of stairs.
Let me provide an example of this myth in action. Let’s say your company has several developers, all hired as either UI developers or back end programmers, but now you have a real need for a Database Administrator. Instead of trying to take one of your current “welders” and have them perform DB carpentry, just go out and hire a DBA! People generally end up in careers that they have chosen and which they enjoy, and trying to get them to do other things often results in alot of spinning wheels and subpar results. While this often seems like a cheaper alternative, that’s part of the myth. In the long run carpenters usually aren’t good welders, and they will either just quit trying or turn out shoddy work indefinitely.
Here’s another, not so obvious example. Let’s say you have two groups of developers. One group has just completed a system for tackling customer orders within the company. The other, an API used by advanced customers to integrate their websites with your company’s. Management decides that parties from both sides need to be familiar with the systems from the other (this is particularly common when the groups involved are single developers) because they are worried about what will happen to the application’s knowledge base if one or more developers leaves the company. To effect a transfer of knowledge between the two sides, they decide that incoming defects will be fixed by the opposite party. What’s the result?
Well, if the systems are not very complicated (haha…that’s a hilarious thought!), the new project owners will quickly learn the ins and outs of the system and then everyone will know everything about the entire code base. That’s another part of the myth. The whole reason management worries about losing people is because the systems are sufficiently complicated that doing so would cause alot of downtime to get someone else up to speed. While alot of management’s job is to hedge its bets and cover all the bases in the event of disaster, too often in this situation, the drawbacks of this approach are ignored.
The first consequence of living the welding carpenter myth is that there is an immediate loss of productivity as people try to get familiar with their new assignments. Instead of taking the code’s original author 15 minutes to find and fix the defect, it takes the new owner 2 hours to fix it, including an hour of time they spend bothering the original author with questions about the system and possible reasons for the defect. Consequently, there is also an opportunity cost involved. The more time the new owner spends on the new system, the less they will remember about the system they authored, so in this case there is a double double whammy of productivity loss.
Another issue with this myth is that the real reasoning behind it is to try and prevent knowledge loss if personnel leave the company. This is certainly inevitable to some extent, but there is an awfully high price being paid to try and mitigate that risk. Is it worth it? I guess it depends on the company’s effectiveness at initiating attrition. Certainly they will be better at that if they try and push people to do things that frustrate them or fall outside their skill set (like throwing them into a new foreign code base or project every 6 months).
What then should be done to prevent this perversion of vocational assignment? Instead of trying to hedge the bets of attrition through reassignment that results in double sided inefficiencies, it would be much more efficient to focus all those efforts on a rigorous policy of documentation that prevents knowledge loss as development proceeds. I won’t go into detail in this post on my thoughts of how to best incite documentation (I will say that in my experience wikis are amazingly effective), but having policies in place that ensure proper systems documentation should tide the knowledge base over until other employees can come up to speed on the insights that were lost by an employee leaving. The second amazingly affective thing that can be done, is to work harder at not losing employees! No, really. Try it. Better compensation, benefits, or even something as simple as newer hardware, a company game room, or a popcorn machine will go along way towards keeping people around.