the knowing-doing gap
There is a great book out there from Pfeffer and Sutton writing about the difference in knowing and doing. Even if you know it will not become reality you often start doing something in that direction. Even if you know this brings you into a dangerous situation, you keep on running. It is scary, honestly but human too.
The same often happens when talking about operations, QA and development. Some examples: Even if developers know that untested code often results in bad behaviour, stress and pain, the code gets deployed. Even if operators know that they should provide a service (the infrastructure and related daemons) they much more try to build barriers to “ensure stability”. Even if QA knows that controlling isn’t enough it is much easier to tell somebody that he did not reach the line instead of helping him/her coming there. We are all obliged to support the company we work for. If the company is run by idiots, please leave otherwise do your work as you promised with your signature.
We all live in a time where time becomes an evident issue, pressure is high, likelihood to fail too, but we are no longer allowed to fail even if a lot of enterpreneural books write about fail-learn-improve cycles. Often this happens as we react not like we know we should react. Business pressure, politics, friendships and sometimes the missing willing to change make us to some sort of organisational animal, no longer reacting rational in a human manner, much more rational in a corporate manner.
But as we are all obliged to Quality, as it is our wish to product high quality products/services, as achieving mastery is one if the fundamental personal goals of “running” we should try to bring in more evidence, react on what we know and not what best fits know and stop doing if we recognize the difference in knowing and doing. Another reason why this is that hard: the organisational culture has to support such behaviour. Saying “no” or “we must change …” has nothing to do with blaming, it’s a positive escalation showing new ways of working and thinking and propably (hopefully) better ones. This has nothing to do with basic democracy, everyone should bring in his/her expertise and evidence to allow the company grow and prosper – knowing without doing isn’t enough!
the missing IT and Ops strategy
It often sounds like operators – or in specific IT operators – just operate on a day2day basis independent of what’s coming from the business and where the business is going to.
In fact this is bullshit. You cannot act as an operator if you do not know where your company is willing to go to! And even you cannot operate if your IT and your IT Ops department don’t knows how to answer on the business challenge and on how to challenge the own IT department. There is difference between “headless” and strategy less. We often see organisations with strong management in terms of discipline, procedures and routines but they still fail. The reason why is not bad engineering … it is a lack of understanding that beside discipline and processes you need 2 more factors (I would not call them soft or whatever and I will not write about culture!)
- a strategy showing people there to go to
- challenge from the market
It is quite interesting to see that the less IT strategy exists the more you hear something like “we are so extra complex and not comparable to market … we have superior engineering on board …. we cannot compare to market as we have special self written applications …. the market will not understand our demand …. ” Potentially we will be able to name tons more of those bullshit arguments.
I worked a serious long time as a systems engineer with potential the same “ideas” regarding our rocket science ops platform ;-). Once I went to the CTO as he asked me to have a look at a special solution being on the market. I told him the pros and cons for about an hour and explained why this is shit. At the end he pointed out that if 1000 people think this is good solution and I think this is shit …. who will be the right one? The funny thing behind …. we used that solution and were quite happy, it was near market standards and we started to build our special ops platform market conform and got tons of more possibilities; on the economic and on the tech value!
Why this is important? The CTO had the strategy to be as market compliant as possible but staying rocket science in the business related tasks, processes and programmes. He showed us that this strategy is able to work and how the company benefits from the strategy (he did not mention in detail that engineers are easier to exchange if you use market standard hardware and software 😉 )
Next thing is that if you do not be on your own on both, organisational and technical, than you can take part on market innovation and inspiration. Mostly market will be much faster and innovative than you are, especially this should help you in the security environment. Keep an eye on being as secure as the market allows you to be. The most innovative internal solution will not help if you cannot participate in security development speed!
Let’s summarize: Have a strategy, give your people a mission, a scope and an idea of how to go forward, don’t forget to check the market and do not hesitate to accept that market is faster and more innovative than you and your department, nothing to shame on, only if you think you can be much faster as the rest of the world. Hopefully or potentially you will be able to exactly tell the “I’m the fastest” story to your business than talking about core processes, metrics and IT/business behaviour!
Tom Peruzzi's thoughts on digital, innovation, IT and operations 
leave a comment