February 7, 2010 § 3 Comments
Seth Godin is one of my favorite bloggers, and his latest book “Linchpin” is on my list of books to read. I almost always agree with what he writes and walk away inspired. Yesterday he posted this on his blog:
The relentless search for “tell me what to do”
If you’ve ever hired or managed or taught, you know the feeling.
People are just begging to be told what to do. There are a lot of reasons for this, but I think the biggest one is: “If you tell me what to do, the responsibility for the outcome is yours, not mine. I’m safe.”
When asked, resist.
The following morning (today), it had been retweeted 440 times and my Google reader tells me that 60 people actually liked it.
There are many people who actually need to be told what to do and not because they are trying to shift responsibility. Thankfully, Seth acknowledges that there are other reasons why people need to be told what to do, and I will not go into those here (ok, maybe one reason). I disagree with Seth in that I don’t think this is the biggest reason.
I’m not a manager, and I haven’t hired anyone. I have done some mentoring and have been a lead developer on a couple of projects. Drawing on that experience, people programmers need to be told what to do for a few different reasons:
- They lack experience.
- There are so many choices in terms of tools in what to use in developing a solution. “Telling a programmer what to do” helps create consistency in a project making it more maintainable.
- Programmers often get overly excited about learning new technologies that they will use the new technology even when it isn’t appropriate to the solution.
- Development efforts, especially in large organizations, need to adhere to an architectural vision and a set of tools and frameworks. Without this “telling what to do” you have skills, software, and programmers running amok creating technical chaos that results in a hemorrhaging of cash with little of quality to show for it.
Knowledgeable technical leadership is invaluable. Self-motivated people like me crave it because it better enables me to create quality software that matters, that won’t be scrapped in six months. Organizations benefit because it saves money, minimizes frustration, reduces time spent on throw-away code, and technically enables the marrying of multiple systems to be done more easily and efficiently.