Technology heroes are always difficult subject. As an engineering manager, I remember the first time I participated in a “life boat” drill where you have to produce a stack rank of your engineers. Someone explained the process saying, “The task is to figure out if you had to throw out one person from a lifeboat, who it would be? After you figure that out, then you decide who would the next one be, etc. until you have a fully ordered list.” I chewed on that a bit and asked, “How many people are going to be left in the lifeboat?” When they asked me why, I replied “Because if there is only one person left in the lifeboat, it would be Mark but if there was more than one person left, Mark would be the first one I’d throw out.” Mark was a technical hero. Able to accomplish a great deal but at a great cost to the the organization.
I’m reminded of a story in Storming Norm Schwarzkopf’s autobiography where he was frantically trying to stand up forces in Saudi Arabia during the first Gulf War. At some point during the buildup, someone asked him where he wanted to deploy Special Forces and Norm replied something along the lines of, “keep them the F*** out of my theater!” (Norm is a colorful character.) Shocked, the person responded along the lines of, “these are the best of the best, the most capable warriors in the history of the world, what do you mean you don’t want them in theater?” Norm explained, “Look – this is all about a couple hundred thousand guys killing a couple hundred thousand other guys. If your Seal teams can kill a couple hundred thousand guys, great, I’ll send everyone else home. If they can’t do that, then keep them the F*** out of my theater.”
What clarity of that thought! What it basically comes down to is that it doesn’t matter how good you are if you are wrong for the mission. Windows (any OS really) is about a couple thousand guys writing a millions of lines of code to deliver lots of scenarios. If a few heroes could accomplish this, we would pay them a lot of money and send everyone else home. They can’t but let’s just say that they could. If you build a plan around a hero and then that hero gets hit by a beer truck, you’re screwed. Hero-centric planning is fragile and ultimately irresponsible. But superstar technical individual contributors do exist and they do occasionally change the way the game is played. So while it is folly to plan around heroes, it is also folly to ignore them. Norm understood that.
After Norm got a critical mass of forces in the Gulf and had a plan he was comfortable with, he revisited the idea of using the Special Forces and used them to great effect in the war. Navy Seal teams were some of the first to engage and served with great distinction. But let’s be clear about it. They were optional elements to a plan that would succeed without them. They enhanced the plan, in some cases dramatically but Norm needed a plan to succeed even if they didn’t exist.
In the same token, there are tasks that require a hero or small group of heroes and would be screwed up with a couple hundred thousand guys tried to do them (think hostage rescue mission). At Digital we used to say that a Consulting Engineer was someone that could solve a class of problems that other engineers could not solve no matter how many of them there were. There were times that you just had to bring in a Consulting Engineer and cope with whatever that entailed or you would not get the problem solved. The best Consulting Engineers were those that would roll up their sleeves and help while keeping their egos in check.
One of the problems with a hero-centric world is trying to get the hero’s to add up. Bill Gates used to say this all the time, he talked about how we had dialed-in the ability to hire the smartest people in the world but still hadn’t figured out how to get their IQs to add up vs. negate one another. Look, we’ve all worked with heroes before so let’s just say what we all know; they can be egotistical buttheads or prima donnas. They don’t have to be. Certainly Jim Gray wasn’t a butthead. Not only was he one of the smartest guys in the world. He was also one of the nicest, most helpful and approachable guys as well. More often than not, the characteristics that allows someone to think dramatically differently than other people and the courage and tenacity to put that idea out there and fight to make it come to fruition are the same characteristics that make them difficult to work with. (NOTE: My experience is that a senior technical IC must be a butthead at times to make things happen. The distinction is whether they are motivated by concern about the customer, the company, the technology or are they motivated by their ego and status.)
Said another way, many heroes find it hard to be followers. I’m reminded of a conversation I had with an awesome mentor at Digital, Mark Storm. Mark was a Consulting Engineer and had worked with 4 or 5 other rock star Consulting Engineers in the database team. I said something along the lines that it must have been awesome to be a team with that much talent. He shook his head saying that it would have been much better if there was only one or two of them there because they spent so much time competing with one another about what to do and how to do it. Nietzsche one said that if you had to have virtue, have only one because as soon as you have two, they start to conflict. Sometimes it is that way with heroes as well – but not always. There are plenty of heroes that will lead but are also able to follow. And not just follow but commit and execute with the same passion they would have if they were executing their own ideas.
Technical heroes can be both a blessing and a curse. An organization, needs to be super clear about what type of problem it has and whether it is one suited for a hero or an army and the have the courage to make the appropriate decisions.
I’m going to regard you as a smiling assasin from now on. 🙂
As I don’t get along with powershell, I now shall look for a new career 🙂 I suspect I won’t be alone in this..
DS
This is the third post I’ve read of yours and I got to say I am impressed. Your ability to couple great intellect with clarity of communication makes for an educational and enjoyable reading experience. Thank you and keep up the good work!
Have you given any kind of consideration at all with converting your main web page in to German? I know a few of translaters right here that might help you do it for free if you want to get in touch with me personally.
Thank you for sharing your wisdom! You’re post just helped me tackle a situation with too many heroes and too few soliders.
Thanks!
Jeffrey,
Could you please enable RSS on your blog? Would love to subscribe to your musings. Great style!
Thanks,
Alan
Hi Alan.
You can pick up Jeffrey’s musings via RSS at:
https://www.jsnover.com/blog/rss
I agree that they’re worth reading!
Ben
Pingback: Dealing with Net Negative Producing Programmers - .NET Code Geeks
Pingback: PEBKAC – Problem Exists Between Keyboard and Chair | Software and Teams that Survive the Woodpecker (Entropy and Chaos)
This is great. I’ve noticed that when you do talks with Don Jones he spends much of the time competing negatively with you. Also you did two PowerShell version 3.0 day talks with (Jason Helmick?) who was very positive verbally but proceeded to ignore many of your most important points about version 3 and insisted on turning it into mainly a version 2.0 course because that was what he knew. There are many examples. He continued to insist on using the console in spite of your saying you were trying to get rid of the console and everyone should use ISE. He continued to use WMI commands when you explained that version 3 introduced the CIM commands and how important they are. And one that really bothered me is the number of times both of them interrupt you to change the subject when you are saying exactly what needs to be said and we miss out on your comments. You usually handle these guys very well. In fact I would like to model much of how you handle it. But often it feels very annoying to watch them and to miss out on important stuff. Perhaps you need to select who you do talks with following your own advice and do talks with a soldier rather than someone who is trying to present themselves as a hero. A good example of when you worked with good people was your Transform the Datacenter talk at Tech Ed Europe about the future of the datacenter where most of your co-presenters were both positive and helpful.
I’ve got nothing but praise for Don Jones. Don was one of the very first adopters of PowerShell and he has consistently been one of my most trusted sources of input on where customers are with their use of PowerShell. We have different approaches and styles but I think that is fine. In fact it is one of the things I actively want in my talks. It makes the point that PowerShell is all about making the customer successful and not just pushing my view of how things should work. I don’t think that there is anything important that Don and I disagree on. There has been in the past but we’ve taken that as an opportunity to learn more and always ended up coming to a compatible view on things.
Jeffrey Snover
Cowboy coders do work well alone and do indeed hate working with others. But the reason I find my cowboy coders hate working well with others stems from a couple very good points. In one scenario I found that a cowboy coder was completely frustrated by another team member suggesting a simpler and more clear design for something he wrote. He was very angry when he spoke to me about it and eventually we found that though his design was a little harder to understand, it was fewer lines of code, ran much faster, and the other approach wasn’t even correct (it failed in one edge case).
Cowboy coders exist possibly because they simply have a unique programming background and understand some important things that other programmers fail to grasp. We had to let this guy go though, because in the end we cannot produce software from one programmer, we need a team, and I got tired of this guy pulling his hair out all the time.
It’s truly unfortunate, because this guy produced much faster, much simpler code than his peers, but he couldn’t work with his peers. As it turns out the guy never returned to the industry and looks like he opened a vintage electronics pawn shop instead.
Trying to get my team to embrace DSC for server management. After watching a ton of tech ed videos and workshops I intend to demo DSC for team. Do you have any power point slides that are more case study like? I have noticed because of the flexibility and open standard of DSC, there are many angles to cover. Btw We are already a very large customer of MS.