Lots of interesting quotes in Dreaming in Code. This one is the story of three stonecutters. Each is asked what he is doing. The first answers that he is, "making a living wage." The second says, "I am doing the best job of cutting stones in the entire country." The third, "I am building a cathedral." Each of the three represent employees you are likely to run across in your days as a manager.
The first represents the employee that's merely putting in his time. He's the person who works 9-5. He'll do what is asked, but when the job calls for that extra effort, he'll probably stop short. There is a place for these employees in an organization. As long as you can lay out achievable goals and set their direction, they'll serve you well. Don't give them the highly critical piece though. They might not come through if it takes a lot of extra effort or extra thought to deliver.
The second often represents a problem. It's good that they care about the quality of their work, but they have their perspective wrong. As a manager, you have a particular task at hand. That task requires certain elements to be created. Each of those elements needs to be of at least a particular quality. However, being highly above that quality doesn't really help. Take the example of the person building a cathedral. The foundation stones need to be cut and they need to be straight. However, being perfectly smooth is probably not required. If it takes twice as long to make a perfect stone as it does an acceptable stone, that extra time and effort is wasted. Likewise, I've had programmers deliver way more than is required. They're often quite proud of it. I once had someone deliver a test months overdue. He was excited because it delivered all of these extra options beyond what I had asked. It had been a lot of hard work getting it to all work right. Unfortunately, I didn't have a need for most of that extra functionality. It was wasted. Watch for these types. They don't have the right priorities. Programming is always done to accomplish a task. If programming is seen as the task, the project will suffer.
At least some of the problems Chandler faced come from this issue. The repository, the widget model, the UI all became issues where the perfection of the parts was seen as more important than the overall product. So much time was spent getting the small things "right" that the large things were ignored. What makes or breaks a piece of software is often the integration of the parts. This second stonecutter worries about his stone, not the stones around him.
The third stonecutter is the one you want to maximize on your team. This is the person who sees the big picture. He not only knows what has been asked of him but also why. Because he understands why, he is able to make intelligent decisions. Knowing that your stone is going into a cathedral means you know when you need to cut the stones to one level of precision over another. This is the sort of employee you just point in a direction and then stand out of the way. They'll knock down whatever walls get in their way. You won't even have to ask.
> The third stonecutter is the one you want to maximize on your teamReplyDelete
As long as you're building cathedrals and not Barratt boxes.
But all analogies break down at some point!
Ask the same person at different times and you may get get any of those answers from the same person. Depends on the context and the particular day. Most people don't fit into little checkboxes on forms.ReplyDelete
Psychological profiling can be overly simplistic and misleading at times.
I'm not sure Doug. That doesn't agree with my experience. People with the wrong perspective seem to have the wrong perspective most of the time. Those who see the bigger picture regularly see it.ReplyDelete
I'm not suggesting that you profile each of your people to see which type of stonecutter they are, but there will be those who clearly stand out as one or the other.
One more flavor of stonecutter comes into my mind, the one who says "I am the fastest stonecutter in this country".ReplyDelete
He's willing to put in some extra time, sees the big picture etc. But the problem is with all those reams of code that's written in a hurry, while they do the job now ok, you know later on, maintenance is going to be a headache.
So you'll end up assigning him pieces of the project that's large but not of prime importance...