How I Turned a $2.3M Setup into $7.4M Value in an Aussie Enterprise
Fair dinkum, leading a DevOps function in a large enterprise can feel like herding cats at times. You've got the business folks talking strategy (often vaguely), the developers wanting the latest and greatest tech, and your own team striving to keep the lights on and build for the future.
My 2024 was precisely that – a whirlwind of bridging these worlds at a significant Australian enterprise. The business objectives were not clear. But the business needed speed, stability, and security. As the Cloud Product Engineering Manager, I saw my role as the orchestrator, the one bringing harmony to this chaos, ultimately delivering some pretty impressive return on investment.
Bridging the Divide: From Ambiguity to Awesome ROI
My crew was a cracker team, composed of highly skilled individuals:
- Five Senior DevOps Engineers: These engineers were the backbone of our automation efforts, building and maintaining our tooling and patterns.
- A gun Solutions Lead: This individual provided technical leadership and guidance, ensuring our solutions aligned with the overall business strategy.
Each team member earned an average of around AUD 190K a year. My role involved strategic direction, team leadership, and hands-on work when needed.
We were responsible for a core suite of tools:
- GitLab (self-managed on AWS EKS): For source control and CI/CD pipelines.
- Sonatype Nexus: As our artefact repository.
- SonarQube: For static code analysis.
- Snyk: Integrated for security scanning.
On the deployment side, we'd built ruby-based abstractions to streamline our AWS container deployments on Fargate. This setup supported roughly 600 Java developers building a plethora of microservices and event-driven applications.
A key part of our challenge was blending established ITSM processes, like Change Management, with the agility of DevOps automation to truly optimise our delivery lifecycle.
Peeling Back the Layers: Our Operational Costs
Let's talk about the investment to run this show. Here’s a rough breakdown of our Total Cost of Ownership (TCO) for the year:
- People: Approximately AUD 1.8 million which included salaries, superannuation, and learning and development.
- Licensing: Roughly AUD 292K. This covered our subscriptions for GitLab, Sonatype Nexus, and Snyk. These were non-negotiables for the functionality and governance we needed.
- Cloud Infrastructure: Around AUD 125K for AWS (EKS, RDS, S3, LB and Fargate). While this could fluctuate, we kept a close eye on optimisation.
- Auxiliary Costs: An estimated AUD 30K for various bits and pieces – macbooks, tooling integrations, minor software (Docker Desktop) etc.
- Total TCO: Approximately AUD 2.3 million.
Looking back, one of the surprises wasn't necessarily a single massive cost, but the constant balancing act. We couldn’t aim for absolute perfection in every area – security and availability, for instance – without a prohibitive cost. It was about finding the sweet spot, the pragmatic level of risk mitigation that delivered the most business value.
This required ongoing discussions and recalibration with stakeholders. We had to continually remind them that neglecting seemingly small things, like updating pinned dependencies, could lead to a significant accumulation of risk over time. It wasn't always the glamorous part of the job, but it was crucial.
The Sweet Taste of Success: Quantifying Our Value
Now for the good stuff – the value we actually produced. While precise figures are proprietary, I can confidently estimate that our efforts generated around AUD 7.4 million in value for the organisation. How did we get there? Let's break it down:
- Productivity Savings: With roughly 600 developers, we estimated savings of 5 to 10 hours per developer per week thanks to our automated pipelines, consolidated patterns and efficient infrastructure. This equates to a significant chunk of developer time freed up to focus on delivering actual business features.
- Risk Reduction: Our integrated security scanning with Snyk helped us catch an estimated 500 to 1,000 potential vulnerabilities before they hit production. Preventing even a handful of major security incidents can save an organisation millions.
- Revenue Uplift: While harder to directly attribute, improvements in deployment frequency, stability, and overall system performance contributed to an estimated 1 to 3% uplift in revenue through faster feature releases and improved customer experience.
- Cost Optimisations: By continuously monitoring and optimising our AWS usage, we achieved an estimated 20 to 30% reduction in cloud waste. A combination of Reserved Instances, Savings Plans, Right-sizing, moving to Graviton-based instances, consolidation of tools led to these savings.
Putting it all together, that’s a return on investment of over 3x\! Fair to say, it was a testament to the hard work of my team and the effectiveness of our DevOps strategy. But the numbers only tell part of the story. The real insights lie in the journey.
Lessons from the Trenches
-
Leadership Style: Making it Desirable, Not Dictated
One of my core philosophies is that you can’t just force DevOps on people. We intensely discussed and calibrated what "value" truly meant for our context – speed of delivery, enhanced security posture, infrastructure consistency, and a consolidated Standard Operating Environment (SOE) – all while prioritising a great developer experience. We positioned our DevOps offerings as enablers, making them desirable rather than a mandated burden. This subtle shift in approach led to much smoother migrations, genuine organic feedback, and even contributions from development teams who felt empowered.
-
Team Dynamics: Drawing Lines and Telling Stories
The reality of enterprise is that you’re constantly juggling BAU (business as usual), strategic initiatives, and often unexpected project demands. We faced our share of challenges, like unclear targets for application containerisation (we had a vague goal of "most apps in containers within 6 months," which lacked specifics) and periods of being undeniably under-resourced. In those moments, I had to draw a line in the sand, prioritising ruthlessly and setting clear boundaries for the team. Motivation came from transparently narrating the cost-benefit stories of our work. Showing the tangible impact of their efforts in terms of efficiency gains and risk reduction was far more effective than simply assigning tasks.
-
Innovation: Pragmatic Standardisation
A while back, the deployment landscape was a bit of a Wild West, with teams using a mix of Terraform, CloudFormation, RubyDSL and ad-hoc scripts. To bring order to this chaos and provide better governance for our predominantly Java-based applications, we chose to build ruby-based abstractions. Why ruby? My team had strong expertise in it, and it allowed for relatively easy adoption by development teams. These abstractions provided parameterised controls for things like NewRelic observability, standard base Docker images, and Sumo Logic logging integration. It wasn't about using the "coolest" new tech; it was about pragmatism and standardisation that delivered real value.
-
Metrics: From Compliance to Culture
Tracking metrics wasn’t just about ticking boxes for compliance. We used deployment frequency and the percentage of applications with autonomous CI/CD pipelines (which we got up to around 85%) as indicators of our progress. We also saw a noticeable rise in our internal Net Promoter Score (NPS) following major infrastructure consolidations and migration efforts. It often involved a fair bit of hand-holding with teams who were earlier in their DevOps journey, but seeing those improvements was genuinely rewarding.
-
Enterprise Integration: Navigating the Bureaucracy
Integrating DevOps principles with existing ITSM processes, particularly IT Change Management, initially felt like trying to fit a square peg in a round hole. There was a natural bias against what was perceived as "skipping steps." To overcome this, I immersed myself in their documentation, sought to understand their concerns, and negotiated for the minimal viable expectations. By building trust and demonstrating how automation could actually enhance their processes (not replace them entirely), we gradually automated and even removed redundant steps. Respectfully navigating the bureaucracy was key to making progress. A good resource that helped in bridging this gap was Atlassian's guide to running IT support the DevOps way.
-
Budget and ROI: The Imperfect but Effective Approach
Reflecting on our budget and the resulting ROI reinforced a crucial lesson: "perfect is not the answer." Trying to build an absolutely impenetrable or infinitely scalable system from day one would have been financially crippling. The enterprise needed consistent maintenance and proactive management to avoid the accumulation of technical debt and security vulnerabilities. This included advocating for regular upgrades, allocating resources for addressing critical security findings, and consistently demonstrating the value of these seemingly "invisible" tasks.
Looking Ahead: Bridging, Building, and Boosting Value
As I reflect on my experience, the key takeaway is the critical role of being the bridge. You’re constantly mediating between often-unclear business needs, the diverse expectations of stakeholders (developers, security teams, architects), and the ever-evolving tech preferences within your own tribe. Creating clear yet adaptable structures that provide both boundaries and a sense of shared purpose is paramount.
This period significantly shaped my own career trajectory, reinforcing the power of a hybrid approach to IT and DevOps, the absolute necessity of being able to narrate value in a language the business understands, and the art of orchestration to achieve significant impact.
If you are evaluating whether your own Cloud and DevOps foundations are ready for the next step, our Agentic AI Readiness Audit scores your organisation across six dimensions. For a broader view of how to extract value from your Cloud investment, see our post on building business value with Cloud Engineering.
Author's Notes and Clarifications
In the spirit of transparency, a couple of clarifications on specifics mentioned earlier in the post, surfaced through subsequent conversations:
- On the ~600 user count: The platform supported approximately 600 users. The majority were active software engineers building Java microservices and event-driven applications, with the rest spanning systems engineering, security operations, application security, architecture, business analysis, and so on. Roughly 80 to 90 percent were active engineers or alike using the pipelines day to day.
- On the productivity savings estimate: The 5 to 10 hours per week savings applies to active engineers or alike (~80 to 90 percent of the ~600 users), not to all 600 platform users uniformly.
- On the containerisation footprint: Approximately 200 applications were containerised. Workloads progressed from bare EC2 to Dockerised EC2 to ECS / Fargate. EKS was used for self-hosted developer tooling such as GitLab, not for production application workloads.