Who is Jeffrey Snover?
Snover is known primarily as the “father” and chief architect of Microsoft’s object-oriented command-line interpreter Windows PowerShell, whose development began under the codename “Monad” (msh) at the beginning of 2003. He had the idea of an object-pipeline and implemented the first prototype in the C# programming language. After the completion of version 1.0 in November 2006, Windows PowerShell was downloaded nearly one million times within half a year. In 2015, Microsoft promoted Snover to Technical Fellow.
Engineer Encounters with reality
John Sweitzer a Distinguished Engineer at Tivoli/IBM
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”.
My job is to ship the best ideas not come up with them
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.
Knowing When To Ignore
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 has 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.
Say what you will about some of these behemoth technology companies.
Specifically about those that create platforms ( Microsoft, Google, Amazon [ AWS] ).
Notice I did not say products.
Upon having your say, being confused about the depth of their technical bench is being self-serving petty.