top of page
  • Writer's pictureSean Kellett

Sign #9: Your IT teams are still divided between engineering and operations.

14 signs your cloud journey may be off track


Are your IT teams still divided between engineering and operations? Alternatively, has your organisation tried to implement a DevOps team, but not seen the responsiveness you were expecting? DevOps is critical for successfully implementing your cloud strategy; without it, you won’t realise the agility that should come with your cloud investment. In this article, we’ll explore the value of DevOps and steps you can take to make it work for your organisation.

Competing internal incentives

Traditional IT-project delivery splits engineering (more recently, “development”) from operations. Engineering builds the service while operations deliver the service. This has a certain logic, as most traditional IT initiatives require long lead times to account for procuring and configuring infrastructure, upskilling teams on new technology, and working through the roles and responsibilities. In this situation, you do not want your operations team wasting time and energy better spent operating systems that are already in production.


However, splitting engineering from operations creates a big drawback – different incentives. Since the engineering team is part of a larger project team, their work is timeboxed to finish before the project ends and funds run out. On the other hand, the operations team only want to take responsibility for a new service after all operational issues have been addressed.


These competing incentives create tension, particularly as the project deadline nears. Except for unicorn projects that run on time and on budget – engineering teams will start to produce sub-optimal implementations or postpone less important features, leaving what is sometimes referred to as “tech debt”. Operations teams will, of course, push back as they don’t want to be responsible for the debt. This back and forth means the project will be subject to escalations, time-wasting, and finger-pointing.


Aligning development and operations

To address competing incentives, most organisations create an Operational Readiness Checklist (ORC) when an IT service is handed from engineering to operations. ORC is a contract between engineering and operations that defines responsibilities. In some organisations, this checklist can grow extraordinarily long after numerous battles between engineering and operations. Getting sign-off on the ORC is a vital goal for the engineering team, because once they’ve thrown the service over the fence, it becomes the operations team’s problem.


Caught in the crossfire between engineering and operations are the customers of the service – your organisation! Battles between engineering and operations can severely impact business agility, making it difficult to remain competitive in your market.

One obvious solution is to combine engineering and operations into a single DevOps team. Some organisations have gone down this route. Unfortunately, combining teams without changing their incentives will not provide the agility you need. For DevOps teams to succeed, the incentives of all team members – engineering and operations – must be aligned.


The first step to align incentives is addressing the fundamental issues that divide your teams: the need to wait for infrastructure to be built, training, and sorting out roles and responsibilities. We have discussed solutions to these issues in Sign #4: Your RACI matrix is overcomplicating operations and causing friction. These solutions form part of a well-implemented Cloud Operating Model that, respectively,

  1. exposes the self-serve, on-demand value proposition of your cloud investment,

  2. includes a modern cloud user journey, and

  3. defines a Cloud Shared Responsibility Model.


Once the fundamental issues are addressed, the next step is to replace the timeboxed IT project-delivery model with the evergreen product development model. We discussed the product development model in Sign# 3 Everyone has their cloud certs but no-one is building cloud apps. In short, the model is built around continually funding feature development – not dissimilar to business-as-usual funding for traditional operations teams. Once the project delivery timebox is removed, incentives can be aligned, and your organisation’s DevOps model can succeed.


If you are not seeing the expected agility from your DevOps teams, or your teams are still split between engineering and operations, then you’re not realising the full value of your cloud investment.



At DigiRen, we have years of experience building cloud solutions. We specialise in building Cloud Operating Models that enable businesses to take advantage of their cloud investment. Successfully implementing a DevOps model takes time and if you would like our help or want to learn more, please contact us at solutions@digiren.com.au and follow us on LinkedIn.


bottom of page