Following the Whale
In this post I share some personal insights into driving the adoption of new transformative technology, like DevOps or Continuous Delivery, across a large enterprise. I do so with the help of a whale. Perhaps you have never read “Moby Dick”. Don’t worry. This is not about Moby Dick and if there is a test at the end, it will be a test that you had coming anyway. This great adventure story serves as a powerful allegory for how we drive sustainable change in organisations. If that is how you’re being tested right now… follow the whale.
What is transformative technology change? Nobody would deny that technology, such as the personal computer or the internet has radically changed how organisations function, how they go about their business and indeed redefined what their business is.
The personal computer dominated the 80’s. Client Server the 90’s. The internet the 00’s, with Agile methods, object orientation and similar appraoches maturing. In the 10’s, we consider ‘big data’, infrastructure as code, and see virtualization and client centric computing mature. The key point is this; transformative technology is not that rare these days. All of those listed above have had a huge impact on how we run our businesses and structure our IT departments.
So, chances are, you are currently struggling to get your organisation to understand a new technology or battling to see it have the impact or adoption you think it should.It may appear rather implausible for a 150 year old novel to have something to say to us about managing technology change. However, Moby Dick is a very technical novel, containing around 100 pages of its total given to fairly detailed technical discussions of the whale as a species and whaling as a profession.
Now, whales play a less central role in technology discussions today than they might have in 19th century, but at its core Moby Dick is anovel about a leader and a team of specialists seeking an almost mythical outcome:Every successful change effort creates a sense of purpose among its members that is at least partly borne in the imagination of what might be as much as it is in the reality of what will be.
The leader, Captain Ahab, subordinates everything to that outcome and so becomes increasingly isolated from his team / crew as they begin to question the mission itself (hunting the white whale). As his obsession grows he also becomes increasingly alienated from other captains also hunting whales.
Change as Chase
Kurt Vonnegut famously diagrammed the narrative structure of many well known stories. In these, he plotted the balance of fortune over time. For example, Cinderella’s fortunes rise when she meets the prince and fall when she leaves the ball and then rise again when the prince puts the slipper on her foot. What would Moby Dick look like in this treatment? That all depends on whether Ishmael, once rescued, is better off than before he left on the Pequod.
He certainly has a great tale to tell. But how did the experience leave him? Analogously, how does failure in confronting change leave people in large organisations?As organisations attempt to drive change and fail in small ways (inclusiveness, rewarding talent etc.), they create an organisational story, less dramatic than Moby Dick, but nonetheless encoding a signature lesson; that change isn’t worth the risk. Better to stay on dry land.
The lesson of Moby Dick is in preparing us for a chase that does not leave just survivors, but more experienced and able hunters; where the practise of chasing change creates a greater appetite to do so in future. We will return to what it means to survive change later.
So, what is the whale? I think of the whale Moby Dick as a symbol of change and Ahab an obsessive seeker of it at all costs. Therefore, Moby Dick and the single-minded pursuit of it by Ahab, is a very powerful cautionary tale for technologists: How often have you been tied to the mast of a ship not of your own steering, seeking an objective in which all faith has been lost? How often have you been at the helm? Whether you have been Ahab or Ishmael in those tales, or just had them recounted to you by others, Moby Dick the novel provides a rich narrative through which to interrogate how you lead teams and enable them to chase down change.
The Character of Change
There are three key ideas relevant to driving the adoption of new technology in a large organisation:Finding the right kind of crew.Keep your compass true by letting go of the helm.Tracing your route for others to follow.Finding the right kind of crewIshmael justifies his intentions when setting out,
“Chief among [the reasons for going ] was the overwhelming image of the great whale himself.”
He fantasised about the “wild and distant seas’ and the “nameless perils” of going after the whale.When we are seeking others who will attempt a major new initiative, like introducing DevOps, we need to find those that understand the huge effort that it will entail: blurring organisational and functional boundaries of responsibility, changing the very processes that have been used to signify ‘quality’ for many years, and introducing ideas of autonomy and empowerment that seem to run counter to large organisations management of compliance. I find Ishmael’s justification above unreliable.
Once he understood the true purpose of the voyage he was already many miles from shore and locked in for the duration. Unlike Ishmael, your devops journey, particularly at the start can’t really sustain any passive observers and the identification of fellow travellers who will not feel similarly duped once you get under way is critical for early speed.
Form a small group of those who are in seek of change not just to tools, processes or technology but to the organisation as a whole — big thinkers who share and understand the problems that devops addresses but who also understand that in order to enable its effects to be sustained some important changes need to be made to the organisation by it. They will form the reliable core of your endeavour and will be powerful advocates and motivators to others who come later. Ensuring that, as the team grows, those that join are seen to be part of, and an extension to, the existing crew is critical. Sometimes, organisations can foist outsiders on a team for the purposes of providing oversight often under the guise of ensuring alignment with other corporate initiatives.
Recall the ‘stowaways in “Chapter 48, The First Lowering”. “Phantoms, for so they then seemed…” were resented by the boat crews and each leader could do nothing but accept it. Starbuck exhorts the crews, “..Sperm’s the play! This at least is duty; duty and profit hand in hand.” As leaders, how often have we had to explain away a team disruption by calling on the higher power of driving business profit, as though it were in some way different from the teams that deliver it.
Do not be too seduced by great tales from others about transformative technology change and how they achieved it (including mine). Any organisation can introduce (for instance) TDD, continuous delivery tools, Chef and vagrant and still harvest few benefits. If the organisation’s belief in what is being attempted is shallow, it will get in the way, slowing down your ‘flow’, reducing the true decision making power of engineers and scrums. So islands reform and the sea reclaims and destroys what you have built.
Creating a credible narrative is the most important thing you can do and it will be a unique formula for your organisation.
Some will respond well to a Queequeg (although likely not a cannible as he is in the novel) walking through the door of your CIO and telling stories of the strange lands he has visited. Others will instinctively react to him as excessively alien. In my experience, an observer like Ishmael is always required. Being a bridge between the savagery of the new way and the staid status quo. Perhaps that is you, or perhaps a trusted partner outside the organisation. Unlike Moby Dick, do not wait 50 chapters before you land a whale. Get your team to demonstrate something simple quickly. Small sprints that produce something for senior executives to look at early is more important than tackling big technical issues invisible to them. Build excitement within the team at creating excitement within the organisation. Once that is done, you get down to real business.
Keeping your Compass true by letting go of the helm
Two issues are very obvious to senior management as they consider supporting a new technology initiative:Ensuring buy-in across the organisation.Retaining some measure of control.In my opinion, ‘buy-in’ is one of the most corrosive terms used in corporate life.
Following work done by Rogers on the diffusion of innovation, innovators with whom you can start to build early adption of something like DevOps will amount to less than 10% of the whole organisation. Yet we often drive ourselves to distraction (literally) attempting to convince and cajole those that are not yet in a position to adopt, when we have no real product to sell.Early on, focus on ‘pay-in’. Find those willing to risk something — sometimes as basic as their personal time — to make it happen.
Their passion will ignite the organisation and adoption of the benefits seen will be a great deal easier than adoption of the theory. A very effective means of achieving this is by forming a virtual team from across many organisations or functions. So instead of creating a team from entirely within your own unit or function, you actively seek out others who share the problem and attempt to build an alliance that is able to speak in the specific language of a range of businesses. It is tempting to take Ahab’s way and build a small team that you ‘truly trust’ (stowaways) while simulating inclusiveness with others. But your ability to grow beyond the first 10% is heavily retarded by this. If they have felt that engineers or architects from within their oragnisation have been involved, valued and are themselves advocates, a division / team / unit is much more likely to adopt your approach.
This does not mean that you do not need to form a stable core. There are some functions on the boat that are compulsory and you will need a core of people who work with you or for you. The difference is that they are indistinguishable from the rest of the crew as the project continues. They, like the others, were there from the beginning.
Try to get your cross-business team dedicated for a period of time on a specific project with well understood goals. Once the team has completed, send those from other units back. They will evangelize on your behalf, likely continue to participate in the core activities, and will be users of your approach in their daily work. I have found that some may want to stay in the core but in practise this should not matter, as you want to ensure that all those involved have complete visibility and a voice in how the initiative progresses. This is not management by committee but rather an entire crew being clear on where they are headed and why. Observers show themselves early and can be ignored rather than actively excluded.
The Paying-In Approach
Form a small team to demonstrate some basic ideas easily relatable by executives. Grow it by finding a few more that really get what you’re trying to do and want to be involved — actively seek those from other units.Find a project to dedicate them all to.Send them back as ‘Apostles’ once its done and start again. Include ALL those who have been involved in the future decisions about the initiative. Jealously protect their inclusion.
Try to get every Apostle to start from 1. in their own organisation. Even if only one makes it, you will have gained great depth and credibility.Retaining Control“The whole crew were half suffocated as they were tossed helter-skelter into the white curdling cream of the squall. Squall, whale and harpoon had blended together and the whale, merely grazed by the iron, escaped.”The passage above is a pretty good summary of what it feels like to be working with new technology while trying to satisfy old goals.How could a lawyer, compliance officer, sourcing person etc. understand the combination of technologies, design decisions and trade-offs you have had to make as you begin your journey. You barely understand it! Yet, it is common for organisations to impose these constraints quite early on.You cant control what you don’t understand. You cant comply with what you cant implement.
In new technology initiatives, compliance and oversight concerns usually have as much to do with the ‘disruptiveness’ of the people / team as with the implementation of the technology. I have found that inviting such stakeholders to demonstrations, common in scrum-like approaches, is very effective. While they understand little of the technology being discussed at the beginning (when you may not be far past the command line) they begin to see and understand the interaction of the team and the inherent transparency of an agile and iterative approach.In other words, Show them how the #whalesausage is made.
All the time.There is a deeper theme here though. How much of new technology is controllable or governable using traditional methods anyway? If we take the recent global financial crisis as an example we can see that one factor that contributed to it was that sophisticated math was used to create derivative products that those who sold them could not understand and those who should have understood their implications could not. How different is that to the application of new technologies to the building of applications? For instance, does a compliance officer know or understand the subtle issues of data isolation with respect to different hypervisors or application containers like docker, ESX, KVM etc? They will always catch up. But there will always be a lag. Which calls into question whether governance and compliance can be performed in any way other than as a dialogue with the team that is innovating. Design your compliance processes so that they require this dialogue. That will also ensure that the older processes do not slow you down.
Remember the Rachel
The “Rachel” lost some sailors overboard during a gale and retraced their route to pick them up. In so doing they discovered and rescued the sole survivor of the “Pequod”, Ishmael.The experience and memories of the Pequod are largely lost to us and recounted only in a ‘survivor’s tale’. I am sure that you have heard many in your organisation tell stories of great daring and organisational failure in which they were the lone voice of reason. As we build teams to drive and embed change we need to remember that there will be others who come after us, using our tools, experiences and approaches.If what we have done does not form a solid foundation for them then we have failed.The finest sign of success in driving change is a distinct lack of survivors…over time, everybody just becomes part of the crew.
