Insights

A recent article by The Economist, argued that only investment bankers stand between consultants and the label of “most reviled species in the professional world.”This wide-spread image of consultants as “corporate counsellors, snake-oil salesmen bamboozling chief executives with glossy charts” certainly makes our task more challenging. The methods by which we overcome these perceptions and effect positive organisational change for our clients offer a keen insight into how to deliver value better than some of the intricate technical solutions we are more used to working with.

Passing the Buck

Over the course of the last year, we have been working with a global SaaS (software as a service) company to optimise their cloud estate, reduce their operational expenditure and strengthen their engineering teams’ cloud capabilities. These engagements necessitated some deep dives into solutions architecture with the engineering teams – a particularly intricate redesign of cross-regional NAT Gateways to eliminate data transfer costs springs – but these technical solutions were the ends, not the means, by which we helped the client optimise their cloud estate. The means were less technical and more personal.

Individuals, often quite naturally and for many different reasons, avoid doing tasks. They “pass the buck” and let someone else deal with and pick up the slack. We saw this tendency on multiple fronts over the course of our cost op engagements this year. Yet, we were successful in turning individuals and teams around to progress cost savings across multiple products.

The question one needs to ask is “why might an individual or team avoid doing something?” It is often difficult to peel back the veil of initial hostility when you get an unhelpful response but, in our experience, this veil is usually a thin one, which hides the real reason someone is reluctant to act. When we drilled a little deeper, the most common reasons for teams passing the buck seemed to be:

•  Lack of understanding around performance, particularly of what good performance looks like.
• Lack of visibility on cloud costs. These are problems easily solved. They do not even necessarily require teams to retrain or upskill.
  

Changing Mindsets with Visibility

When asked why full-scale production environments were created 6 months or more before the possibility of them being used, or why development environments only used during office hours were left running overnight, technical teams first reaction was usually “better safe than sorry” or “it’s easier for us to do it this way”.

When shown that same production environment running unused for 6 months cost over $100,000, or that a development environment turned off overnight could shave 50% off its annual cost, you could almost see the lightbulb flickering behind the eyes. It is often said that engineering teams “don’t think about costs.” This can be true, but in our experience, it is not because they are uninterested; rather, it is because no one has told them they need to think about cost. No one joined up cost and performance and demonstrated how they related to one another. Once we did so, and set performance metrics alongside dollar amounts, teams became much more engaged because they saw our engagement was not just about cutting costs, it was also about technical efficiency.

A False Sense of Security

Reliable performance is efficient. By showing teams (and executives) they could potentially be paying 50% less annually for their infrastructure before they even thought about making changes to technical architecture, we expanded the horizon of performance to encompass efficient, as well as functional, infrastructure.

Reliable performance is like a great view: you could pay $25 to sail past the Statue of Liberty on one of those irritatingly busy boat tours, or you could hop on the Staten Island Ferry and get the same view of Lady Liberty for free. $25 seems reasonable for such an iconic experience, until you realise you could get the same view for $0. The point is that it is not enough to ask whether something works.

Old adages such as “if it ain’t broke, don’t fix it” lull executives and engineers alike into a false sense of security. If we are asking, “does it work?” the immediate follow-up needs to be “at what cost?” It is from this starting point that we should be examining technical architecture.

In an age of soaring energy prices and a global pivot to sustainability, businesses are being pressed to ensure their infrastructure is sustainable over the long-term. In many companies, even in Big Tech companies such as Twitter, which recently announced it needed to save $3M per day on its infrastructure, it is simply assumed that cost optimisation will have an impact on performance.

Our experience with our SaaS client over the last 12 months demonstrates this is not the case. People avoid things they do not enjoy. Whether that is because they do not understand something and therefore find it difficult, or because they cannot see how something like finance relates to the technical infrastructure. The moral of this story is that it is our job as consultants to illuminate the links between what we are interested in (cost) and what the engineering teams see their roles as (delivering a performant application/infrastructure).

Cost is (or should be) a Shared Responsibility

For this customer, putting the costs of infrastructure side by side with the environments, demonstrated to engineering teams that cost could be a key metric of technical efficiency. This secured buy in from engineers who had previously passed the buck on costs because they did not see it as being their responsibility. Our success in these engagements, often boiled down to illustrating how cost is not one person or one team’s responsibility, it is very much a shared responsibility.

At Capacitas, we transfer our knowledge to our client’s engineering teams in a programmatic way, and to a far greater extent that any traditional cloud optimisation partner. We help identity the value of the Cloud.