{"id":137,"date":"2011-12-24T12:44:46","date_gmt":"2011-12-24T19:44:46","guid":{"rendered":"http:\/\/www.jsnover.com\/blog\/?p=137"},"modified":"2013-09-22T18:00:35","modified_gmt":"2013-09-23T01:00:35","slug":"focus-on-reality","status":"publish","type":"post","link":"https:\/\/www.jsnover.com\/blog\/2011\/12\/24\/focus-on-reality\/","title":{"rendered":"Focus on Reality"},"content":{"rendered":"

Years ago I enjoyed reading the book, Execution:\u00a0The Discipline of Getting Things Done<\/a>.\u00a0 I got a lot of out of it but\u00a0it had a small\u00a0signal-to-noise ratio.\u00a0 I’ll save you a few bucks and a lot of time by\u00a0sharing the 2 key lessons I got from the book:<\/p>\n

    \n
  1. Execution matters<\/strong>.\u00a0 Vision and strategy are great but what changes the world, improves the lives of our customers and pays the bills is execution.\u00a0 I remember the first time I heard Bill Gates say, “vision is cheap”.\u00a0 I thought to myself, “what a jerk”.\u00a0 That was before I had read this book and I didn’t “get it”.\u00a0 Well Bill was right and I was wrong (it has gone the other way a few times as well\u00a0but that is for a\u00a0different blog post\u00a0)\u00a0 The book did a great job making this point.\u00a0 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'”.<\/li>\n
  2. It is critically important to engineer encounters with reality<\/strong>.\u00a0 “Engineer encounters with reality.”\u00a0 Say that a couple dozen times.\u00a0 The point is that people have lots of visions\/strategies\/ideas\/approaches.\u00a0 They could be good or they could be bad.\u00a0 At the end of the day, the best judge of that is reality.\u00a0 Our job\u00a0is to create a system whereby we never stray from reality for long and constantly course-correct to be better aligned with reality.<\/li>\n<\/ol>\n

    I got a great lesson in this from John Sweitzer a Distinguished Engineer at Tivoli\/IBM.\u00a0 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.\u00a0 There was one situation where I was trying to get a group to adopt a particular design and was having difficulties in convincing them.\u00a0 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.\u00a0 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<\/em>“.\u00a0 You could have knocked me over with a feather after I heard this.\u00a0 There are people that love to win and there are people that hate to fail (they are different).\u00a0 I hate to fail.\u00a0 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.<\/p>\n

    John went on to explain, “You are either right or you are wrong.\u00a0 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.\u00a0 Use that to help them fail as quickly as possible so that they can learn the lesson and restart on the right path.\u00a0 You are saying that the design won’t scale so make sure everyone\u00a0agrees 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).\u00a0 One of two things are going to be the case: 1) it scales in which case\u00a0 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.\u00a0 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<\/em>.”\u00a0 That was a career-changing conversation for me.\u00a0 John was giving\u00a0me my first lesson in “our job is to engineer encounters with reality”.<\/p>\n

    Early in my career\u00a0I adopted an aphorism which has served me well and is key to embrace this idea of focusing on reality:\u00a0“My job\u00a0is to ship the best ideas not come up with them<\/strong>“.\u00a0 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.\u00a0 This mindset allows\u00a0you to\u00a0drop\u00a0your idea in a heartbeat if someone comes up with a better one without\u00a0your ego getting in the way and as such, it allowed me to embrace John’s advice and make it actionable.\u00a0 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.\u00a0 (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.)<\/p>\n

    As a general rule, it is much better for a team to come up with their own approach for addressing the problem\u00a0instead of\u00a0you telling them how to solve it.\u00a0 Sometimes the situation doesn’t give you that flexibility but when it does it is the better approach.\u00a0 Given a clean slate and a problem to solve, the team might come up with a better solution than you have.\u00a0 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.<\/p>\n

    At the end of the day what matters is reality.\u00a0 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.\u00a0 In Tog on Software Design<\/a>, 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.”\u00a0 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.<\/p>\n

    Sounds easy right?\u00a0 It isn’t.\u00a0 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.\u00a0 I once\u00a0had a meeting where a team had done a customer survey and wanted to use the results “as-is” as the plan.\u00a0 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.\u00a0 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.”\u00a0 The aphorism that helps here is, “Any idiot can listen to the customer. It takes a smart person to know\u00a0WHEN to ignore them<\/strong>.”\u00a0 <\/em>Apple is famous for ignoring what customers say<\/strong> but clearly have done a good job focusing on reality and delivering products that people respond to.<\/p>\n

    There are no easy answers here. The mechanisms to focus on reality will vary and require judgment.\u00a0 John Sweitzer taught me\u00a0a really great technique to help teams you are trying to influence by helping them fail fast.\u00a0\u00a0There are many other techniques.\u00a0 As the book said, execution matters<\/strong> so developing a\u00a0strong preference for reality over opinions is the correct path forward. It not only produces better products but a better work environment.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Years ago I enjoyed reading the book, Execution:\u00a0The Discipline of Getting Things Done.\u00a0 I got a lot of out of it but\u00a0it had a small\u00a0signal-to-noise ratio.\u00a0 I’ll save you a few bucks and a lot of time by\u00a0sharing the 2 … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[6,5],"tags":[],"class_list":["post-137","post","type-post","status-publish","format-standard","hentry","category-career","category-work"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/posts\/137","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/comments?post=137"}],"version-history":[{"count":22,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/posts\/137\/revisions"}],"predecessor-version":[{"id":206,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/posts\/137\/revisions\/206"}],"wp:attachment":[{"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/media?parent=137"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/categories?post=137"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/tags?post=137"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}