Cultivating technical innovation in daily operation
Many companies that are undergoing a digital transformation are discovering that it is an endless endeavour. Technological innovation allows a company to become more responsive to change in their business domain, but also makes it subjective to progress in the underlying technical implementation. A lot can be said for the delivery pipeline optimizations that help deliver business value more efficiently, but how does your organisation keep up with technological innovation?
I was recently asked for my opinion on how a hypothetical company could 'implement innovation'. The question suggested innovation had become a project in itself, accompanied by a manager sitting on top of a bag of money allotted to it, which they planned to spend over the course of the year. This project would be expressed in terms of tools, technology, methodology, tech stack and what-not. The manager struggled to find ways of getting people on board, given that those people were stuck in teams delivery business value with their tools at hand, and solving operational issues. New technology appears at an ever increasing rate, so how do you keep up?
Discussing this further, I shared the following insights.
Insight 1 - Innovation is part of daily operation
The first step towards successful technical innovation is realizing that it is not a separate thing from daily development and operation. Clean architecture and the Boy Scout Rule mean your technical landscape evolves as you implement new features. Innovation in technical capabilities allows you to deliver new, better, faster and more secure features. Often, when the intended business value is clear, exploring what a new technology can bring to the table to help implement it is a matter of spiking it. The bottom line is that business value should drive innovation.
Insight 2 - Innovation is an answer. What is the question?
The question is how it helps you deliver more value and deliver it faster. Innovation is also the remedy to technical decay: technology can become obsolete as support evaporates (which may happen as a result of the community moving to better alternatives, or the enterprise deprecating it) or becomes too expensive for the intended value (abuse of monopoly position, or squeezing more 'enterprise features' when you want a tool to do one thing and do it well (Unix philosophy).
Insight 3 - Developers may resist innovation when they resist change
The third insight is realizing that developers aren’t necessarily interested in a new technical undertaking and may resist change. This can have several causes, most of which can be mitigated to some degree once the first insight has been established.
… because it disturbs daily operation
Management may have bought time through a special innovation budget, but that doesn’t mean a developer working in a team with a sprint backlog magically has that time to spare. If something requires time during a sprint, the best idea is to make that explicit during sprint planning. This is the subtle difference between a disturbance of work and a planned activity.
… because the alternative of doing nothing has no risk or cost tied to it.
To be fair this goes for functional features too, but technical innovation by its nature may feel closer to home for a developer: sometimes the only value of doing something lies in the risk of doing nothing.
As suggested by Daniel Pink in DRiVE, productive workers feel autonomy, mastery and purpose. A backlog of work without apparent value is like a backlog without purpose. The work will feel more like a chore.
… because the acronym "POC" is flung around without realizing what it means.
Proof should be measurable and to a large degree agreed on upfront. A concept should be accurately described in terms of design and expected value. Otherwise, it’s just work without purpose.
… because the option of trying something new carries the risk of failure.
Not every organisation tolerates failure and instead fosters a cover-your-ass mentality. Etsy’s John Allspaw wrote a lot about the Blameless Post Mortem as a means to achieve this. Etsy is even famous for introducing the Three Armed Sweater as a reward for people who made the most valuable mistake to learn from.
So pleased to have won this year's Three-Armed Sweater Award for that time I accidentally upgraded apache! Thanks @allspaw! <3 #opslife pic.twitter.com/1hP6WLjqPD
— Ryn Daniels (@rynchantress) December 7, 2016
Taking it one step further, one could argue that a company should plan to fail at appropriate scale as a mean means to improve. Amazon’s Jeff Bezos shared this insight several years ago, claiming the Fire phone was a valuable failure that Amazon could and should afford.
Insight 4 - Innovation is a repeat journey from the old to the new
This means that innovation should include an exit strategy for when the new is the new old. An exit strategy is a contingency plan for moving away from that new tool, platform or clever architecture when it ultimately falls short of your new requirements.
Insight 5 - Innovation is culture
The final insight is that innovation is culture. The culture of an organisation can be changed by fostering certain behavior and cultivating certain traits.
IT is not a cost centre
IT should be the heart of your organisation as a business enabler, instead of being treated like a bump in the road towards success. Jez Humble makes a case about this in his book Lean Enterprise: How High Performance Organisations Innovate at Scale
Keeping up with technological developments in the market is stimulated
People are given the time to study.
People are given the opportunity and a platform to share and discuss their findings.
People are stimulated to attend and speak at conferences in their field.
The hiring process includes looking at the desire to learn, master and teach something new; not only at that which has been mastered already. The contrary of this is the bad practice of making people feel like a lack of knowledge is a sin, and that their salary comes with the expectation that all knowledge required is present, and anything missed should be acquired in time outside of working hours.
Budget and time is available for teams to hire external consultants or take part in external courses.
Success is judged by including what was learned
Velocity is usually expressed in terms of business value. This is mostly expressed as the 'why' of a backlog of work. Developers can find purpose in the 'why', but are mostly about the 'how', and this is where they find mastery and autonomy. When looking at the result of a sprint (or a comparable period of work), it is a missed opportunity to disregard that part of the work done. Experiments, even when they yield the insight that an innovation should not be pursued, should be part of the review and heralded as value.
Architecture is a direction; not a destination
Much can be said about architecture in an agile organisation. With respect to innovation, one things is pivotal: Architecture is a direction; not a destination. This means architecture is designed to set boundaries within which multiple roads can be taken. Innovation is about finding new roads within those boundaries, and sometimes about testing those boundaries themselves. The abovementioned remark concerning having an exit strategy applies here as well: when you know you’re constantly on the move, evolving and innovating, architecture becomes more concerned about having a safe journey than describing the endpoint.
Change can be brought about quickly
Checks and balances are important and should be taken into consideration when defining experiments - indeed, the 'proof' part of a PoC should include quality assurance and audit trails. Be sure these requirements are formulated as guidelines; a 'why', and less as a 'how'. You want to avoid bureaucracy where going through the motions involves several procedures and teams before being able to affect any kind of change. Such processes can become impediments even to existing operations, let alone innovations which by definition will challenge some existing boundaries of how you do things.
