How to squeeze in more automation (and keep up in a product-based organisation)

Blog Post • 4 min read

When the organisation reaches a certain stage of digital transformation, infra teams face major Day 2 challenges. 

The wider business wants to improve digital capabilities and move to a product-based organisation with agile ways of working. But despite progressive cloudification, costs haven’t really gone down and speed of IT hasn’t gone up much. 

As a result: 

  • Costs are higher than planned – in particular, cloud is costing more than you thought it would, and people costs are high
  • There’s lots of product team grumbling about slow IT – they depend on core tech platforms, but are creating shadow IT to minimise scheduling impacts
  • Infra teams are frustrated, stressed and overworked – because people can only support so many product teams at once
  • Skills aren’t available, and it’s hard to upskill – people aren’t fully utilising the tools and processes set up when you migrated

Automation: so close and yet so far

These challenges are often rooted in lack of automation. 

Ideally, the central IT team should provide end-to-end automation, enabling self-service from request to managed services provisioning. That way, product teams don’t need to interact with the managed services team as often.

However, despite best efforts, IT can struggle to deliver 100% automation. Often, about 80% is automated, but the remaining 20% gets stuck in a 2-week human process.

As a result, it’s more ‘click-click’ ops than infrastructure as code.

How to bridge the automation gap

The plain truth is that the current IT support model is throwing hurdles in the way of 100% automation – and enabling the central infra team to shine in a product-based organisation.

To get that last mile, you need to reorganise the support model so it can deliver automation to the level required to enable product team self-service. 

There are 4 overarching steps required to achieve this:

  • Coordination – to drive the automation project, team processes, policies and KPIs need to be restructured to enable coordinated budgeting, goal setting, skills sharing/development and risk sharing
  • Shared vision among different IT teams – herding the cats to get buy-in on more automation and self-service
  • Evaluating managed services provider contracts – some providers might not support key elements like automated onboarding
  • Rationalising/modernising VMs – once you’ve automated landing zones and CI/CD in cloud PaaS and Kubernetes, you may be hitting an automation wall if your migration approach (lift and shift) left you with lots of VMs. You can either get rid of some of that technical debt by rationalising/modernising or introduce automation at a VM and database level

Updating the IT support model

When lots of organisations migrated, they didn’t change their IT support model, which means it has gaps from a Day 2 operations perspective – and it’s not clear who has responsibility for key areas. You need to optimise the support model to inject clarity on who’s responsible for what.

In the early stages of cloudification, a cloud centre of excellence (CCoE) can handle support elements (and paper over the cracks), but when you reach a certain level of scale, you need to stop papering over and start optimising. 

There are 3 elements to optimise:

What a best-practice IT support model looks like

Through that optimisation process, you end up with a model in which product teams are supported by a central IT team:

  • Managed cloud, security and platform engineering teams deliver what product teams can’t
  • Everyone can operate in an agile way
  • You support the CCoE as you scale up

So it’s time for a think…

If infra teams are seen as bloated, expensive and slow and you’ve hit an automation wall, is it time to think about IT support model changes?