Years ago I enjoyed reading the book, Execution: The Discipline of Getting Things Done. I got a lot of out of it but it had a small signal-to-noise ratio. I’ll save you a few bucks and a lot of time by sharing the 2 key lessons I got from the book:
- Execution matters. Vision and strategy are great but what changes the world, improves the lives of our customers and pays the bills is execution. I remember the first time I heard Bill Gates say, “vision is cheap”. I thought to myself, “what a jerk”. That was before I had read this book and I didn’t “get it”. Well Bill was right and I was wrong (it has gone the other way a few times as well but that is for a different blog post ) The book did a great job making this point. I’m not sure whether it was this book that said it or not but the phrase that gets this in focus is, “a vision without execution is called a ‘dream'”.
- It is critically important to engineer encounters with reality. “Engineer encounters with reality.” Say that a couple dozen times. The point is that people have lots of visions/strategies/ideas/approaches. They could be good or they could be bad. At the end of the day, the best judge of that is reality. Our job is to create a system whereby we never stray from reality for long and constantly course-correct to be better aligned with reality.
I got a great lesson in this from John Sweitzer a Distinguished Engineer at Tivoli/IBM. I had the privilege of working closely with John for a number of years through a number of very difficult situations and boy did I learn a lot from that guy. There was one situation where I was trying to get a group to adopt a particular design and was having difficulties in convincing them. Having no positional authority over the group, I could not control the decision so I needed help in figuring out how to convince them to do the right thing. John had been in this situation many times before and his advice was, “sometimes the best thing you can do is to help a team fail“. You could have knocked me over with a feather after I heard this. There are people that love to win and there are people that hate to fail (they are different). I hate to fail. I’ll do almost anything to avoid failing and viewed it as my job, hell – my reason for existing, was to help this team avoid failure and here was John telling me to help them fail.
John went on to explain, “You are either right or you are wrong. If you are right and they are going to fail with their current approach, then you should be able to articulate where the design is going to fail. Use that to help them fail as quickly as possible so that they can learn the lesson and restart on the right path. You are saying that the design won’t scale so make sure everyone agrees what the scale requirements are and then arrange to have them prove that their design can meet those goals ASAP (make it one of the first coding goals). One of two things are going to be the case: 1) it scales in which case you’ve learned something and it is a good thing that you didn’t get them to change or 2) it doesn’t scale in which case they are going to have to change their approach. At that point they might take your approach or they might pick another but one way or the other, it is going to meet the scalability requirement that we’ve all agreed to.” That was a career-changing conversation for me. John was giving me my first lesson in “our job is to engineer encounters with reality”.
Early in my career I adopted an aphorism which has served me well and is key to embrace this idea of focusing on reality: “My job is to ship the best ideas not come up with them“. I come up with lots of ideas and a lot of them have turned out well but this aphorism has helped me shift focus from my internal thoughts to what is going to change the real world. This mindset allows you to drop your idea in a heartbeat if someone comes up with a better one without your ego getting in the way and as such, it allowed me to embrace John’s advice and make it actionable. If it think a team’s approach is broken and I have a different idea of how it should be done, I try to be clear about what problem I want addressed and then be totally open to how that problem gets addressed. (It doesn’t always play out that way at work but when I’m doing my job well, that is what I strive to do.)
As a general rule, it is much better for a team to come up with their own approach for addressing the problem instead of you telling them how to solve it. Sometimes the situation doesn’t give you that flexibility but when it does it is the better approach. Given a clean slate and a problem to solve, the team might come up with a better solution than you have. If you give them a solution then they might just adopt it and not think out all the possibilities or take responsibility for its success.
At the end of the day what matters is reality. What we need to do is to transform conflicts in the ethereal world of ideas, opinions, egos, visions and strategies into encounters where reality will provide the data about the right thing to do. In Tog on Software Design, Bruce Tognazzini said something along the lines of, “Engineers will argue for weeks over things that can be solved with a 30 minute user study.” Many cloud-services have adopted a data-centric decision making process where they create various experiments and then let the user response decide which approach to take.
Sounds easy right? It isn’t. Knowing how to do this, when to do it and what to do when you can’t is super difficult but that is what we have to strive for. I once had a meeting where a team had done a customer survey and wanted to use the results “as-is” as the plan. I knew the area well and had a pretty good idea of where the survey was telling us real information and where it reflected the fact that we asked the question in the wrong way. My comment to the team was that, “If you aren’t using your perspective and knowledge to interpret the data, then I could replace you with a computer survey and save a lot of money.” The aphorism that helps here is, “Any idiot can listen to the customer. It takes a smart person to know WHEN to ignore them.” Apple is famous for ignoring what customers say but clearly have done a good job focusing on reality and delivering products that people respond to.
There are no easy answers here. The mechanisms to focus on reality will vary and require judgment. John Sweitzer taught me a really great technique to help teams you are trying to influence by helping them fail fast. There are many other techniques. As the book said, execution matters so developing a strong preference for reality over opinions is the correct path forward. It not only produces better products but a better work environment.
Great post. I’ve been trying to focus recently on delivering rather than ‘analysis paralysis’ and the following always helps sharpen my mind;
“There are five frogs sat on a log and four decide to jump off. How many are left?”
Answer? Five. Deciding and doing are NOT the same thing.
I’m going to steal that one. 🙂
Jeffrey Snover
Jeffrey,
Thanks for sharing! I am a strong advocate to ‘fail fast’ too. Your quote from Tog hits home. It’s amazing how often we catch ourselves in theory, when sometimes 20 minutes of ‘doing’ will definitively answer many of the questions we’ve debated for the last two hours.
“Fail fast, fail often, and grow……. “
Sage advice. Thanks for sharing!
Hi Jeffrey,
Just wanted to drop you a line after I watched 646. Your talk was interesting and you have a nice way of presenting. Also, you stated something in the talk that reminded me of the UAC issue. (Powershell is an API to build rich management tools on – were as in a lot of cases it’s been pitched as a CLI). UAC went through a period of misunderstanding and people not understanding what it actually was..
You also stated that starting from 8 – server core is by design meant to be the way to go.
I sincerely hope server core in 8 is better than Hyper V in 7. The reason I say this is that I found Hyper V basically a very poor product in the setup phase. I know I may be in a minority here. But examples for Hyper V in 7
1. The join a domain slot in the menu is at 1. This needs to be below setup networking. I have no idea how that ended up like that but it’s obviously wrong.
2. CORE CONFIG (2) is badly needed in Hyper V, and having to go get it as an extra is a product failure. It should have been shipped in the release.
3. I say the above, and I say it knowingly as you smile and say ‘Powershell and the new age guys’ got round that ages ago.
I’ve been a sys-admin since Novell 3 / Win 3.1, and I concede to you that I have found the MS changes since before 7 a serious challenge and remain so to me. This is largely due to under the bonnet deep level change going on in MS at your level/area. And this means everything I know, or did know is being annihilated by the change to the Cloud, Powershell, and Metro. We live in interesting times as the Chinese used to say.
I’ve never ever been a sys admin who held an aptitude on the scripting side of the IT world, and I think in many cases this would be true of the smaller on premise business world in a general sense – ie the one you guys sold NT4 to. I concede that I am having no fun at all with Powershell. I achieve a hundred fold doing work than I get done in Powershell in UI or old methods. This is obviously due to a lack of core programmer aptitude. It’s also why the barrier is high in Linux with Bash scripting and so on. Powershell is right now something I have to use and will have to use more. I wish I had your excitement about it, I really do. I understand that the UI and tools based on it will be very powerful, and that’s a good thing.
Vaguely speaking, this comes across to me in a simple way. The current mindset at MS is indeed to build huge OS sets based around a hybrid cloud. But to do this, a new cloud savvy IT pro is required, and he or she will need to have a severe skillset to work in such an arena. It’s a deathnell to generalist IT pro’s who hold old skillsets. I do understand the power of Powershell. Don’t get me wrong, but this is not an accessible or human readable ‘power’. It’s going to be defined down to specific people with aptitude and talent. In the cloud world, this I understand. When building a cloud of 10,000 machines, you only want high skill assets working on that structure, and they need to be accomplished at what they do. The costs of this structure have to be as minimised as possible, so you want as few people and costs as possible.
I’ve been around a long time. I’m watching admin’s around me cut and paste large portions of code they don’t even understand, and I look at the scripting, remote ability, and so on as a plausible attack vector. As this is going to be always on, and guaranteed between old and new. Further, I’ll add that I am basically thinking the idea that the structure is administered from remote hosts (and I’m thinking here, it’s going to be done from end user machinery, Win 7, Win 8, and probably watered down security to make things ‘easy’ ) fills me with dread. People are going to cross network boundaries, with infected admin machines and a direct scripting engine to the Hybrid structure. And get job access to Scheduler and Task Manager (and the rest of course!).
I would pose the question of ‘is this wise’ – but I am sure you guys have this covered off to a very refined level.
Anyway, thanks very much for the 646 talk, it was very interesting, and it is nice to see MS consider things like nanoWBAM.
Kind Regards
Darren
you are clearly a very clever guy and i love powershell.
however, there is no such thing as rockstar developers or technology heroes. You don’t need to sanitise your posts with truly terrible imagery and similies. It would be far easier to just say what you mean without using some terrible references to imagery
@Dan. I’m pretty lucky. Microsoft is willing to do whatever it takes to hire the best engineers in the world. This week I had the pleasure of meeting with a number of our Technical Fellows. They guys are rockstars and heroes to me.
Jeffrey Snover [MSFT]
Jeff, I read with great interest your insights into ‘failing fast’, so one can learn and move on. Hopefully Microsoft will learn quickly that Modern UI in Windows Server 2012 is total failure and will move on from there.
I think many developers and IT Professional agree that doing (i.e. protyping) is by far the best approach, rather than debating and exploring every option without actually delivering anything – but the trend to de-skill and out-source *everything* and bring in non-technical managers has stifled innovation and the can-do attitude that used to be prevalent in IT has all but gone.
Unfortunately, these days it’s all about managing the ‘process’, not outcomes. Good technical people, who are focused on outcomes, are leaving the industry in droves because of the micro-management by non technical people who don’t understand this.
Several years ago I attended one of your PowerShell technical sessions at IT Forum/TechNet Europe in Barcelona. Very informative, thanks.