Case Study · SSE Electricity
What SSE taught me about real DevOps and Agile for Eloqua
SSE is a major UK energy company with deep roots in electricity generation, networks and retail. I joined their DevOps team to support the Oracle Eloqua platform that underpinned key customer and marketing communications.
This was not a typical campaign build role. It was a DevOps position inside a serious engineering team, where I stopped treating Agile and DevOps as buzzwords and started to understand how they actually work when they are done properly.
Client background
SSE is a UK listed energy company with operations and investments across the UK and Ireland. The organisation develops, owns and operates low carbon energy assets, electricity networks and a range of energy services. At the time of this engagement, SSE Retail was still part of the group before later being acquired by OVO.
Eloqua did not sit in a marketing silo. It lived inside a central DevOps and integration function. That team was responsible for making sure that backend systems, databases and customer facing platforms all worked together in a way that met internal standards for reliability and compliance.
The DevOps group was made up of long serving engineers. Some were on their second or third decade with SSE. One of the newer team members already had eighteen years in the company and another colleague celebrated forty years of service while I was there. These were people who had seen several waves of technology come and go and had kept critical systems stable through all of it.
At a glance
- Sector: Energy and utilities
- Platforms: Oracle Eloqua, internal integration stack
- Team: Central DevOps and engineering
- Role: Eloqua focused DevOps and technical support
The challenge
SSE needed two additional people to strengthen their Eloqua capability inside the DevOps team. This work was not about building emails or campaigns. It was about the heavy lifting that sits under the surface so that marketing can run safely on top of a stable platform.
Eloqua inside the engineering landscape
Most of the DevOps team focused on how Eloqua connected to backend systems. There were several initiatives in play at any given time. These were often complex or highly technical pieces of work that required a deeper understanding of how Eloqua behaves once it is wired into real enterprise data.
The items that landed with me were usually things that the marketing department or campaign contractors could not realistically own. They involved:
- Complex data flows into and out of Eloqua
- Edge cases around program behaviour and data processing
- Looking at the performance and stability impact of new ideas
- Research into undocumented or less documented features
From waterfall to structured Agile
At the same time, SSE were transitioning from waterfall delivery to Agile. This was not Agile in name only. Management and engineers were taking formal Agile training alongside their day jobs and committing to doing it properly.
The Eloqua DevOps work had to fit inside three week sprints with real planning, a prioritised backlog, daily standups, sprint reviews and retros. Work could not just appear out of nowhere. It had to be shaped, estimated and owned like any other engineering task.
The challenge was to support the DevOps team with Eloqua work that was too technical for marketing, while learning and respecting a delivery model that was far more disciplined than what most marketing tech teams are used to.
My approach
My approach at SSE had two layers. On the surface, it was about solving Eloqua problems and supporting integration work. Underneath, it was about learning how a mature DevOps and Agile culture operates and aligning myself with that standard.
Focus 1
Eloqua as a core system
I treated Eloqua the same way the team treated any other critical system. Changes were considered, documented and controlled. Integration behaviour, failure modes and data flows were all reviewed with the same seriousness as other platforms in the stack.
Focus 2
Deep research and problem solving
A lot of my time went into research. That meant digging into how Eloqua handled specific integration patterns, testing ideas in a controlled way and then coming back to the team with clear options, trade offs and recommendations instead of guesses.
Focus 3
Learning Agile properly
Before SSE, I had seen Agile used loosely and I will admit I did not take it seriously. At SSE, three week sprints, real planning sessions and honest retros were the norm. I learned how Agile looks when an engineering team commits to doing it correctly and I adapted my way of working to match that.
Focus 4
Respect for long term ownership
Many of the engineers had been looking after SSE systems longer than I had been working with Eloqua. I listened more than I spoke, asked questions rather than arriving with fixed ideas and made sure every change respected the history and constraints of the environment.
Focus 5
Taking on what marketing could not own
When marketing or contractors hit the limit of what was safe to do in Eloqua, the work moved into DevOps. My job was to take those requests, break them down into proper tasks, remove risk and either deliver a robust solution or explain clearly why something should not be done.
Impact
The full business impact of the Eloqua work at SSE was cut short by the OVO acquisition and the arrival of COVID. My role ended suddenly as the organisation reshaped its platforms and teams. I did not get to see every long term outcome of what we built and investigated.
What I did walk away with was a very different view of DevOps and Agile. Before SSE, I had seen both used as labels without structure and I will be honest and say that I took the idea of DevOps and Agile with a pinch of salt. SSE proved that when you run them seriously, everything changes.
The DevOps team ran three week sprints with discipline. Work was prioritised. Backlogs were real. Standups meant something. Retros were open and honest. There was structure, ownership and clear expectations. DevOps was not a fashionable title. It was a way of protecting stability while still delivering change.
Since SSE, I have seen plenty of environments claim to be Agile with no framework around them at all. No real planning, no respect for WIP limits, constant context switching and no documentation. The contrast is stark. Without structure, everything turns into chaos and people burn out trying to compensate.
SSE taught me how DevOps and Agile should work when grown up engineers are in charge. That experience changed the way I scope work, the way I estimate, the way I document and the way I support Eloqua inside other large organisations.
In my words
I have a lot of respect for the SSE DevOps team. They were patient while I learned their way of doing things and they showed me what proper engineering and proper Agile look like in practice. I genuinely hope that through the OVO transition they were treated fairly. Many of them had given most of their working lives to keeping those systems running.
- Greg Staunton
Need Eloqua support inside a serious engineering environment
If you need Eloqua to work alongside core systems and DevOps practices without causing chaos, I can help you bridge the gap between marketing expectations and engineering reality.