joeware - never stop exploring... :)

When poking around today I found a comment I made on a post two years ago, I thought I would share it here as it is just as true today.

…complexity kills. A lot of my work is around trying to figure out and fix stuff where people got too complex for the task at hand. Either they weren’t very good at what they did and made it complex accidently, the environment grew beyond intents over time and was patched into complexity, or someone was trying to be fancy and thought a complex solution was sexier and made them look smarter or something (I call this consultant / vendor syndrome). For the record, the simplest most elegant solutions are the most sexy. Those are the ones that have real life down the road and are more likely not to be ripped out and replaced. I personally am far more impressed and joyful at simple solutions than complex ones stacked up with all sorts of various interconnections. Don’t build the Titanic when a paddle boat will do.

This goes when fixing anything, you don’t always have to fix the entire problem in one fell swoop. Sometimes it not only makes sense, but makes infinitely more sense to solve issues in small bite-size pieces that slowly work you back to how something should really be done. When I worked for HP Enterprise Services I regularly saw cases where they would try to fix something but building a whole new solution that was a massive undertaking and would be paralyzed and unable to do anything until that was completed and unfortunately more times than not those massive solutions would end up getting killed before anything got done and so we would never move off the dime and fix even small things because people didn’t look at solving them at the micro level and wanted only to deal with them at the macro level. That is when I first started saying “don’t build the Titanic when a paddle boat will do”. I said it because I would visualize our many issues and problems as us floating down the river without so much as a stick to our name and someone would say let’s fix that and the solution was to build the Titanic and everyone would have great job and expectations and two years later nothing was built and nothing was going to be built and in the meanwhile we are still waterlogged in the river and could have been much better off if we had just built a paddleboat.

   joe

Last Friday I wrote the email below and sent it to the Directory Services team (which I am the Technical Expert for). I have received some very positive feedback so I thought I would share the verbiage here as well because this really applies to every medium to senior level person in the business and if you are a low level person in the business it is something you should keep in mind as well. Also if you haven’t read the Amazon Letter to the ShareHolders referenced, please do yourself a favor and read that as well.

==

From: Joe Richards
Sent: Friday, May 26, 2017 6:14 PM
Subject: We do it for the result, not the process.

I wanted to send out an email to the team calling out the signature I have had on my emails for a while.

This text came as a warning from the CEO of a competitor and it is very sage advice. It is important information for this team to keep at the top of our minds at all times. Even though this was only recently published by our competitor this basic concept was taught to me in the late 90’s and has been a fundamental underlying mindset of nearly every team I have had any input into and has worked very well.

Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right.[1]

We care about the outcomes, not whether or not we followed process properly because our deliverable isn’t the process, our deliverable is the result we are trying to achieve when we are following the process. What matters are the outcomes. This aligns with the old joke, “The operation was a success but the patient died”. We have and build processes to make it more likely we will get to successful correct outcomes. We OWN the process, if we don’t get the right outcome, we OWN the resulting failure. When we fail, we take that failure and analyze it with an eye to fix the process to prevent future failure.

By now you have probably heard me say several times, “Does this step add value to the process?” or “Does this process add value to what we are doing?” as well as “Question everything.” If something isn’t adding value or worse, puts us in a position to fail, it must be questioned and, if not removed outright, corrected to make sure it gives us the needed value and allows a successful result.

This isn’t cart blanche to throw out all process but it is a responsibility on each of our parts to question process and try to correct it in a feasible manner that leads us to the correct result.  Even if we are in the middle of some process and we see a potential bad result coming, if we have time and/or the potential badness outweighs moving forward we stop and figure it out or we get clarification before proceeding. Anytime something doesn’t feel right, question it.

We are professionals. We own a service and the processes around it. Process is only a tool to help guide us in the correct direction to do the right thing and we have to be aware enough of and understanding enough of what it is that we are doing and do everything with great purpose such that we can see when the process is failing us and correct it. If we have a failure, our answer should not be, “We followed the process.” It should be “Yes, we failed, we will correct things so it doesn’t happen again.” We are professionals.

    joe

[1] The whole letter to the Amazon shareholders from which this snippet was pulled can be found at https://www.amazon.com/p/feature/z6o9g6sysxur57t and is a great read.

—

Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right.

Be pragmatic: Everyone told the King of Swamp Castle that he was “daft to build a castle on a swamp,” and sure enough, his first attempt sank into the muck. “So I built a second one,” he says. “That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up.”

This is the kind of thinking that produces epic SAP implementation failures. The King and his melancholy son Alice … I mean, Herbert … could’ve spared themselves a lot of trouble if they had listened to trusted advisors and built on another site. Be pragmatic and be willing to shift your plan as events and conditions warrant. Oh, and no singing.

<SNIP>

https://msdn.microsoft.com/en-us/magazine/mt742864.aspx?f=255&MSPPError=-2147217396