At Container Solutions, we often work with customers who approach us saying they need a Cloud Native Transformation because they are not able to deliver fast enough. Typically, a leader will tell us tales of woe about how frustrating it is for them to get things done. They tell us they are drowning in maintenance issues, that they are inefficiently solving the same problem in multiple ways in multiple places, and it just takes too long for them to get changes delivered. How, they ask us, can we get from where we are to the nirvana of faster feature development and continuous delivery, and all the good stuff Cloud Native promises us?
Fortunately we have seen this scenario many times, and have developed a methodology for helping our customers achieve their business goals. Essential to this methodology is understanding exactly how technical and organisational change goes hand in hand.
A common pattern
When making a transformational change to a business, it is important to understand where you are right now. So before we recommend any changes we take a good look at the current situation. No two businesses are the same, as their context and histories differ, but over time we have seen patterns emerge both in how customers got to where they are, and what the best approach is to helping them.
One of the most common patterns we see is that the early success of a technology, product, or business takes place in a low-dependency, low-regulation environment with relatively few contributors. This creates a naturally Agile workflow and results in fast growth of the business, department, or product. Over time that small and tight delivery group grows into a much larger team, or even multiple siloed teams that develop different cultures and metrics for success. This helps create bottlenecks in the delivery system, and delays and conflict ensue, as well as rising costs to maintain or extend the product.
One recent example of a customer we worked with that fits this pattern is a hardware company with a software telemetry system designed to extract the most value from the hardware they sold. This started as some bespoke software installed on a PC and plugged into their customers’ machines. Over time, it grew into a large group of teams maintaining a complex distributed computing platform running across multiple racks of machines across different data centres. We’ll call them ‘HardwarePlatform’.
Another example was a B2B software services company (‘B2BSoft’) that grew with a product that fragmented as it was sold to different customers, who then made bespoke changes to each implementation. This fragmentation of their core product into multiple bespoke implementations meant that, over time, a greater proportion of operational cost was going to maintenance as each site required bespoke care and attention to its specific idiosyncrasies. As a result, new deliveries and features were becoming increasingly more expensive and delayed. (We also wrote about this pattern here).
A faster horse?
In these cases, customers often come to us looking for the magic bullet that will solve their problems. Often in their minds this takes the form of a product or technology that might conveniently be easily bought or implemented. Unfortunately, no such product or technology exists. At best, applying a new product or technology to the same organisational patterns will only result in a ‘faster horse’, by which we mean incremental improvement within a limited boundary: No horse can go quicker than the fastest horse. To go faster than the fastest horse, you need to make a step change by using a car.
In order to get step-changes in delivery and reliability, our customers need to metaphorically get off their horse and into a car. Changing the way anyone works is difficult, and changing the way a company works is even more so. To help them, we first focus on making sure of two things: Whether they want to change, and whether they agree on what they want to change to.
To help them with this, we advocate they take advantage of an assessment process we’ve built over eight years that minimises the need for customer involvement while maximising the information gathered from the client. The output of this process is a presentation to the senior stakeholders that communicates:
- A presentation and report with a ‘key finding’ about the biggest challenge they face, and
- A roadmap of steps to moving to where they want to be.
The key finding mentioned above is a single statement that marks out the biggest challenge the business faces in making the change they want to make. This is almost always a statement about the organisation rather than about the technologies used. Here are some examples:
- “If you want a step change in delivery, you need to invest in finding defects earlier.”
- “Ineffective organisation prevents things from getting done (fast).”
- ‘Your middle management has too many competing constraints on delivery to enable any meaningful change’
The value of presenting the key finding is to clarify and ensure alignment across the business about what needs to be tackled. Of course it does not cover every nuance of the situation, but generally provides a significant and necessary area to be tackled before the work can have any chance of success. This can transform boardroom discussions from statements like ‘why can’t we just move to the cloud?’ to more constructive statements like ‘What do we need to do to unblock our middle management?’
The roadmap we provide as part of the assessment typically follows our Think, Design, Build, Run methodology. Many customers’ habitual approach to transformations is to plan and target a big delivery by a specific date. However, once the ‘Think’ phase is over, we often recommend placing a ‘small bet’ in the design phase to fully flush out the organisational challenges required (a pattern we call “gradually raising the stakes”).
Because of the organisational changes required to embrace cloud technologies, simple technological implementation is not enough, and technical and organisational changes need to be approached in tandem. This requires an exploratory approach designed around reducing risk and uncertainty for the lowest possible cost. It also requires a collaborative approach aimed at building the collective knowledge and capability within the business rather than a more traditional ‘integrate a solution for me’ approach taken by consultants in more mature areas.
The Design phase: the ‘easy’ technology bit…
For B2BSoft, the Design phase involved building a re-usable Kubernetes cloud-based platform with their senior engineers that could onboard two reference applications ready to sell to their customers. For HardwarePlatform, the Design phase involved doing exploratory work with both their development and cloud centre of excellence teams to develop a distributed Continuous Integration model that could ‘shift left’ and catch defects as early as possible in the hardware cycle. This proved successful very quickly, and resulted in broader-scale adoption across the business.
Although far from trivial work, we like to say that this Design phase is the ‘easy’ bit, for two reasons. First, it mostly involves the technical aspects of transformation, adopting technologies we are well familiar with and expert in. Second, we are usually working with internal evangelisers of cloud technologies. Even though it is ‘easy’, this initial smaller phase is vital to help build confidence that the ‘bigger bets’ that are coming will be worth the effort.
The Build phase: the ‘difficult’ organisational bit…
The next phase is Build, where the balance of focus shifts from the technical work more toward the organisational. Whereas designing and building new technology with a small group of self-selected and motivated engineers is relatively straightforward, this phase is where we hit the challenges of changing the behaviours and cultures within the business. This is much harder, as people find change very difficult, especially when they do not feel fully in control of it.
One example of this was with B2BSoft, who had a manual test team, many of whose roles were effectively being replaced by automated testing being done as part of their new platform. Not unreasonably, this created significant anxiety in the team, and had to be carefully managed. Three concurrent approaches were taken to help:
- Those in the team that were motivated to were upskilled through coaching and pair programming in the new automated testing technologies
- Others were still needed to run certain tests that were not amenable to automation,
- The remainder were repurposed to manage the business’s cloud computing costs, a new need arising from the new platform for the business that fit well with the team’s existing skills.
A more subtle challenge we often help with is how the changes made are accounted for. These might include an organisational shift from project to product funding, and a move from capex to opex. These changes can result in unexpected changes elsewhere in the business that need to be coordinated, such as how the CFO accounts for technology spending across the business, and how salespeople account for the cost of what they’re selling both internally and externally. These challenges were written about in more detail in this blog post.
When helping B2BSoft in this area, we were able to engage with the right stakeholders across the business at the right time, so that the challenges were made visible and understood in a timely fashion during the transformation process. It’s our experience that raising all these organisational challenges at the start proactively threatens to overwhelm the business and cause significant anxiety about whether the whole endeavour can succeed. When challenges like this are identified at the right time along with suggested solutions, then the process of change is much easier to manage.
How we deliver value
Over time agility gets lost as organisations grow and become more complex. To recapture that agile innovative spirit, you need to make organisational changes that support technical changes. In our experience, this means doing things differently from how you’ve grown used to doing them. When we help customers, we generally follow this recipe for success:
- Establish the current situation and shared goals
- Align on the key constraints on success
- Agree a roadmap
- Demonstrate with a ‘small bet’ that the path agreed is going to deliver benefits
- Build out the innovation across the business, working through the organisational changes that need to be made
When innovating within a business, it’s difficult to predict exactly how that business will respond to the technical and organisational changes that need to happen. This is why gradually raising the stakes as your confidence in the success of the endeavour increases, and adopting a dynamic strategy rather than a monolithic one, has a better chance of succeeding.
All the while, technical and organisational change must be seen as two sides of the same coin, with the technical side being more the focus early on in the process, and the organisational more the focus later. Container Solutions’ real-world experience at managing this end-to-end process and keeping all these elements in mind are where we deliver the most value.
Previous article
