This article is based on an interview originally published by Techerati with Martyn Coupland, DevOps Technical Lead at Virgin Atlantic, ahead of DevOps Live London 2020.
From Subject Matter Expert to Cultural Champion
At Virgin Atlantic, Martyn Coupland wears two distinct hats as DevOps Technical Lead. The first is deeply technical: he serves as one of the airline’s subject matter experts for Microsoft Azure and owns the Azure toolset that underpins its DevOps programme. The second is harder to put on a job description — he is a champion for the people and process dimension of DevOps across the wider business.
“As technology changes, people change and processes change,” Coupland explains. “DevOps will always be here to ensure all three sit together and provide real value. This allows not just technology teams at Virgin Atlantic but other parts of the business to adopt DevOps methodologies.”
That dual focus — technical enablement paired with cultural translation — is a pattern that practitioners at large enterprises increasingly recognise as essential. Getting the toolchain right without winning hearts and minds leaves organisations with automation nobody trusts and processes nobody follows.
How DevOps Thinking Has Shifted
Coupland identifies a meaningful change in how senior leaders frame DevOps over recent years. Early conversations were dominated by cost optimisation — a framing that often translated, in executive suites, as an opportunity to reduce headcount. That narrative has largely given way to a speed-and-value narrative.
“Speed and value are the main drivers to getting products to customers before competitors,” he says. This reframe matters because it changes the investment case. DevOps is no longer positioned as a way to do the same things more cheaply; it is positioned as a competitive differentiator that lets organisations ship faster and respond to customers sooner.
For engineering leaders trying to make the business case internally, this shift in language is worth borrowing. Talking about deployment frequency, lead time for changes, and time-to-restore resonates differently with a board than talking about tooling consolidation.
Small Teams, Big Lessons
Coupland is candid about his own early struggles with DevOps. Like many practitioners, he found it difficult to change deeply ingrained ways of working.
“My first journey into DevOps was a really small team of three of us — that actually helped the transition. We worked well together and started to implement some of the processes, technology and cultural changes we know as DevOps.”
This is a recurring theme in DevOps adoption stories: starting small is not a limitation, it is a strategy. A tight-knit team can experiment quickly, fail safely, and develop shared norms before those norms need to scale. Trying to transform a large organisation all at once, without proven patterns to replicate, tends to produce chaos rather than improvement.
Virgin Atlantic’s software teams now practice continuous integration and continuous delivery (CI/CD) on applications that cabin crew, flight crew, and ground staff depend on daily. Coupland frames this software dependency not as a risk but as a benefit: robust DevOps practices mean that dependency is backed by fast, reliable delivery and recovery.
DevSecOps: Baking Security In From the Start
The tension between speed and security is one of the most persistent challenges in modern software delivery. Coupland uses a Formula One analogy: mechanics and drivers — standing in for operations and developers — can be tempted to chase speed before thinking carefully about safety. In a hyper-competitive environment, the pressure to ship fast is real and understandable.
But Coupland sees the security conversation as natural and healthy. “When something new in technology comes around, people naturally and rightly ask questions. Remember when the cloud was new? Security was one of the main conversations I had about why not to adopt the cloud. As vendors proved their security credentials, these fears went.”
The implication is clear: DevOps security concerns are not unique to DevOps — they are the same concerns that greet every significant technology shift. The answer, then as now, is transparency and evidence.
Bringing InfoSec to the Table Early
Coupland’s practical advice for bridging the developer-security divide centres on inclusion and communication. DevOps teams should actively create advocates within InfoSec — people who understand the tooling, can assess the risks intelligently, and propose proportionate mitigations rather than blanket blocks.
“Then they make a call on it and we work together to propose a sensible mitigation to that risk,” he explains.
He pushes back on the stereotype of InfoSec as a blocker: “Many IT professionals still feel InfoSec is there to add delays and cause unnecessary blockers — it’s not the case. Most of the time the InfoSec team is the one making sure your organisation is not front-page news. As data becomes more important, so does the effort to protect it.”
Security by Design, Not Retrospective Retrofit
One of Coupland’s clearest prescriptions is to avoid the common mistake of bolting security on after the fact. CI/CD pipelines, he points out, are fundamentally workflows — and most engineers have implemented workflow systems before. Framing it this way demystifies the process and makes it easier to identify exactly where security controls should sit.
His rule of thumb: define first, build second. Decide what your security requirements are before you start wiring up pipelines. Once the full delivery chain is visible, the points at which security should be embedded become obvious.
“Don’t try to retrospectively add security to your tooling, unless that’s continuous improvement of course, and make sure that you start with security first — security by design.”
Martyn Coupland, DevOps Technical Lead, Virgin Atlantic
This aligns with widely accepted DevSecOps principles: shift security left by integrating static analysis, dependency scanning, secrets detection, and policy checks as early as possible in the pipeline — ideally at the pull-request stage — rather than as a gate at the end.
Key Takeaways for DevOps Practitioners
- Reframe the value proposition. Position DevOps around speed and competitive advantage, not cost-cutting. This changes how non-technical stakeholders engage with the programme.
- Start small and prove the model. Small, cohesive teams are the best environment to establish DevOps norms before scaling them.
- Include InfoSec from day one. Security is not a gate at the end of the pipeline — it is a participant in the design conversation from the start.
- Define before you build. Security requirements should be established before pipelines are built, not retrofitted after the fact.
- Simplify the language. CI/CD pipelines are workflows. Describing them in plain terms makes security conversations with non-specialists more productive.
- Accept imperfection. Coupland still considers Virgin Atlantic “new to DevOps”. Continuous improvement is the goal, not a finished state.
No Organisation Has “Finished” DevOps
Perhaps the most grounding note in Coupland’s perspective is the acknowledgement that DevOps is not a destination. Even at an organisation with tangible, measurable CI/CD benefits across operational-critical applications, the journey continues. The goal is not perfection — it is a culture of constant, deliberate improvement.
For teams earlier in their journey, that is both a realistic expectation-setter and a reassurance: you do not need to have everything figured out before you start. You need a small team, a willingness to work differently, and a commitment to bringing security along for the ride from the very beginning.