Jeffrey Snover is a Microsoft Technical Fellow, PowerShell Chief Architect, and the Chief Architect for the Azure Infrastructure and Management group which includes Azure Stack, System Center, and Operations Management Suite.  Snover is the inventor of Windows PowerShell, an object-based distributed automation engine, scripting language, and command-line shell, and was the chief architect for Windows Server.

After studying physics at the University of New Hampshire (1978–1982), Snover worked as architect and development manager for Tivoli NetView at Tivoli Software (IBM), and as a consulting software engineer in the DEC management group at Apollo Computer, where he led various network and systems management projects. He also worked at Storage Technology Corporation and various start-up companies. Snover joined Microsoft in 1999 as divisional architect for the Management and Services Division, providing technical direction for Microsoft’s management technologies and products.

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.

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 that has served me well and is key to embracing 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 I 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 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.