Technology Leadership

The shelf-life for many leaders in IT is dreadfully short and often leads to organisations being unable to comprehensively execute strategy.

Achieving balance between delivering today and innovating and setting stretch goals is incredibly hard.

Perhaps the issues in many organisation are compounded because too many technology leaders have a distant relationship with technology?

Clearly there are a number of topical debates around technology at the moment and I have participated in, and led, many discussions around them.

With many organisation having broad ranging strategy that touch:
– Cloud
– DevOps
– Big Data
– Mobile
– Security
Is there little wonder that CIO’s and even CTO’s struggle?

Perhaps we need to look at this debate from a number of angles.
1) Education

Too few of the innovators in the technology world can present their ideas clearly and even when they are able to there is often an agenda. Take big data as an example; a storage vendor in this space has one perspective, traditional RDBMS companies another and Map Reduce occupies a third position.

Leaders need to take the time to educate themselves and guide their team to identify problems and map them to solutions. Vendors need to start helping with education and community events more to enable end-users to have a better understanding.

2) Experience

Expert technologists need to develop new skills, or hone their existing abilities, so that they are able to assist in the corporate decision making process. And conversely their leadership needs to have a better compass to help identify who they should trust and when to be skeptical.

Technologists need to also broaden their exposure, experiment and not be afraid to make mistakes. But all the while be realistic about the potential and potential pitfalls of a decision to go down a direction of A or B.

3) Business Value

Enterprises must learn to measure the benefits of their strategic choices to help improve.

Suppliers must start to measure the value of their solutions and not simply in a sales cycle but when also be prepared to work with their clients in the long-term when real results can be measured.

Is your product|service mature enough?

How much Enterprise software sits on a shelf unused?

Unused because it didn’t work as expected or perhaps it required a higher level of skill than perceived. Maybe it was bought by one team and ignored by the others?

In reality it is probably a mix of these with a few other challenges thrown in for good measure.

With open source and community-driven software – will this impact the value chain?

Heath Robinson

Let’s discuss.

Be under no illusions open source often has a commercial basis so what levels of support or frequency of release might you expect. This will vary dramatically across companies, product and geography and in many cases you will find the contributors are also active in the support communities responding to you before any commercial response.

Then consider the maturity, or perhaps better expressed as enterprise understanding, of the contributors. Do the people designing, writing or reviewing the code or features have a real background in the enterprise or an understanding of context. As someone who has spent two year at Chef I believe this is one of the more significant and, as yet, unresolved challenges. It is UNLIKELY that the community does have exposure or understanding!

Do not under-estimate the expectations of the community. Open source fosters an expert audience – expert but often lacking emotional connection or empathy. The author has observed contributors who no appreciation of the expertise available in a standard IT department and have never been exposed to IT service management tools or practices. This is not surprising but it is a significant consideration when you buy in to their ecosystem. Beware of features or processes that don’t or cannot fit with the way you run your business, examples include:
– inconsistent user management / directory integration capabilities
– ignorance of IT risk and mitigation
– poor documentation
– over-reliance or ignorance of tooling and process such as orchestration
– the ‘you can write that’ syndrome
– solutions that actually cause problems including false positives and ignorance of the need to use exception-based notifications when working at scale