The key to simplicity isn’t “Know How” it’s “Know Why”
Alex Honor /
Many of us technicians like to understand complex things and learn about the roots of hard problems.
We are also very well versed in technology, how it works – how to make machines and advanced sophisticated designs. But at our jobs we work in the context of the business. It’s the business outcome that is the important context to always keep foremost in our minds. Well, at least it should.
“We have to grasp not only the Know-How but also ‘Know Why…’”, – Shigeo Shingo (Toyota)
From time to time, the business comes to us asking for help to reach a desired outcome. The outcome might be to launch a new product, add new features to the web site, anticipate a bunch of new customers, open a new market, or shorten lead time for customer requests.
So, we technicians put on our thinking caps and get excited because we are going to get to make something.
“What’s the best solution?”, we ask ourselves. “It better cover all contingincies for changing scale or future concerns”, say the far thinkers. “It’s a big project with lots of moving parts”, exclaims the project manager.
What often happens? We technicians get mired in how we solve the problem, using all the tricks up our sleeves, relishing in our know how. We know how that goes. We say: “Meta-object protocols will make our solution infinitely extendable, even dynamically! This inheritance hiearchy design coupled with good component composition will ensure the software architectured is correctly multi layered.” Blank stare and reply from the business manager: “What?” We say: “Oh it’s superior technology”
Admit it. We’ve all been there saying or listening to this kind of stuff.
What stands between us and our goal is the complexity of the solution.
“The most dangerous kind of waste is the waste we do not recognize.” – Shigeo Shingo (Toyota)
Complexity is a killer. We already live in a dynamic, fast paced world and the business is always changing. Our work world is complex so why make our solutions complex? Complex solutions are fragile, hard to roll out and adopt, time consuming to fix and extend. Complex designs just make life harder. Does the business outcome depend on any of this complexity in the solution? If not, we are gold plating and are just creating a form of waste.
So, how do we avoid building the complexity? Here’s some good rules to live by:
1. Stay focused on the “Know Why”.
Be clear you understand the desired outcome the business expects. Are you sure about it? Do others agree with your interpretation. If not, you’ll be alone defending your choices or you might suffer living with your own decisions.
2. Don’t fall prey to your “Know How”.
Watch out for the inclination to create advanced/sophisticated/over-engineered designs and implementions. This just adds time, risk, and money to get the work done.
3. Be disciplined.
Building a new solution and migrating from the “old way” of doing things to the new way is by definition a transformation. The new way will require its own new “Know How” and will not be perfect/complete/usable the first time (or the 2nd, 3rd… time). If moving to the new solution is painful, you have to stay disciplined and keep iterating to make the solution less painful. Stay focussed on the outcome the business cares about and expects from you as your guiding principle.
4. Do the simplest thing.
Choosing products and tools that are inherently simple to use, require little Know How from everyone. Tool shininess gets the heart rate up because new is fun but this isn’t what the business cares about.
You know the old saying, the shortest path between two points is a straight line.
[…] up from yesterday’s post. Tagged in News / 0 […]
[…] 景“,对”业务背景“。http://t.cn/zYTkyY5 […]
[…] Complexity often gets in the way of providing workable solutions to the business. Alex Honor explains how the complexity was built and what we can do to avoid or limit it. The key to simplicity isn’t “Know How” it’s “Know Why” (dev2ops) […]
[…] Recent DevOps Blog Post: The Key to Simplicity Isn’t “Know How”, It’s “Know Why” […]