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.