Tom Peruzzi's thoughts on digital, innovation, IT and operations

the knowing-doing gap

Posted in general failures, organizational by opstakes on February 8, 2013

Bildschirmfoto 2013-02-08 um 08.40.36There 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!


DevOps as the solution?

Posted in organizational by opstakes on October 18, 2010

I got more and more info regarding DevOps and how good it is within the last weeks. I even started posting at some of their blogs and during my first steps I really liked it, it looked like being a good approach to keep on driving the idea of an operational platform. Nothing new, but another good driver for bringing Operations as a discipline of operating and engineering upfront.

The more I think on that the more I believe that this is just another approach and it will take a much longer time and much more approaches like DevOps to convert Operations from a barrier to a driver within tons of organizations.

You disagree? See why: In the past we have seen some very interesting scenarios. One – very long supported by all departments within companies – was to see IT operators as the barrier of truth. Whoever and however you survived talking to them ,you were a hero. Introducing new functionality was more or less incredible and they – the IT Operators – always believed that they save business’ live by acting as a barrier for innovation. Even keeping things slow was king to them.

The other typical operations department was a little bit more open as they were seen as the IT engineers unable to write code. So those 3rd class employees needed work and why not acting on the simple infrastructure basis? They really did not like Development and you know why … they developed their own style, their own culture and propably this was not the intention of the business. They tried to establish themselve as the better IT within the IT …

Those 2 artefacts really need DevOps or alternatives like our Platform Engineering, dialects of ITIL or others. The question is how to transform from barrier thinking to business enabling.

If you understand operations as the fundament of business than you definitely need strong, accepted and rich of engineers operations, not barrier minded, not 3rd class developers, not people stopping invention during mainframe area. Those will neither accept DevOps nor anything else, everything was already there and they know when and why …

Beside DevOps think more not on the tool (DevOps may be one), think on how you can transform your IT opps organization to a living one, being well accepted with good and strong communications, transparent operations and KPI willingness. By starting the cultural change you potentially will result in DevOps, but DevOps itself will not result your organization in good communications, transparen ops …

Tagged with: ,
%d bloggers like this: