Too many IT workers operate under a cloud of fear and frustration. The 2017 congressional testimony from the former Equifax CEO — in which he pointed to a single IT employee as the cause of one of the largest data breaches in history — illustrated exactly why that culture persists. The DevOps Enterprise Summit (DOES) 2018 offered a very different picture: one where engineering teams are empowered, data-driven, and increasingly willing to challenge long-held assumptions. Here are three substantive lessons from that event.

1. Legal Teams Can Be Engineering’s Ally in Legacy Modernization

Anne Bradley, Nike’s Chief Privacy Officer, and Courtney Kissler, Nike’s VP of Digital Platform Engineering, delivered one of the conference’s most memorable sessions. Their topic: how to kill legacy systems that the business has been unwilling to retire.

Their approach was counterintuitive. Rather than building a purely technical case for decommissioning aging infrastructure, they framed the problem in legal and financial terms. Anne Bradley introduced the concept of negative ROI — calculating the expected cost of regulatory fines if a non-compliant legacy system remained in production. Modern data privacy regulations (such as GDPR and similar frameworks) create real, quantifiable financial exposure for organizations running systems that cannot meet current compliance standards.

Courtney Kissler used that legal and financial analysis to build an executive-level business case for shutting down the offending systems. The retirement was celebrated with an Irish wake, a cake, and poetry — a cultural signal that ending a system’s life is worth acknowledging, not mourning.

The practical takeaway: Engineers often fail to retire legacy systems not because the technical argument is weak, but because they fight the battle alone. Partnering with legal, compliance, or risk management functions transforms the conversation. When a legacy system carries a potential fine measured in the hundreds of millions of dollars, decommissioning it stops being a technical debate and becomes a straightforward risk decision. Look for allies outside your team when you need to drive modernization.

2. Databases Must Be Part of Your DevOps Transformation

Dr. Nicole Forsgren and Jez Humble from DevOps Research and Assessment (DORA) presented findings from the 2018 State of DevOps Report. One of the more noteworthy additions to that year’s research: the role of the database in DevOps performance.

The DORA research found that organizations actively incorporating database practices into their DevOps initiatives — version-controlling schema changes, automating database deployments, and treating database changes with the same discipline as application code — showed a positive correlation with overall IT performance.

Equally important was a finding about universality: database practices were described as non-differentiating in terms of where an organization sits on its DevOps maturity curve. Whether you are just beginning your DevOps journey or are already operating at an elite level, addressing your database practices produces measurable benefit.

The practical takeaway: Database changes are frequently the last piece of an otherwise automated delivery pipeline to remain manual. Schema migrations applied by hand, change scripts stored outside version control, and database deployments requiring a separate approval window all introduce risk and slow down releases. If your CI/CD pipeline handles application code but still treats the database as a special case, that is where your next investment should go. As the familiar saying goes: the best time to plant a tree was twenty years ago; the second-best time is today.

3. External Change-Approval Processes Hurt Software Delivery Performance

Nicole Forsgren’s book Accelerate (co-authored with Jez Humble and Gene Kim) attracted significant attention at DOES 2018. One distinguishing characteristic of the book is its foundation: years of empirical survey and analysis data, rather than anecdotes or vendor-sponsored case studies. None of the three authors worked for a technology vendor at the time of publication, which reduces the usual conflicts of interest found in this genre.

One of the most striking findings — discussed in detail in the book — concerns the approval process for software releases. The DORA researchers asked organizations to self-identify which of the following release approval models they used:

• All production changes must be approved by an external body (such as a manager or a Change Advisory Board)
• Only high-risk changes (for example, database changes) require external approval
• Changes are managed through peer review within the team
• No formal change approval process exists

The data produced a result that directly contradicts decades of received wisdom in IT operations: teams that required approval from an external body achieved lower software delivery performance across key metrics including deployment frequency, lead time for changes, mean time to restore (MTTR), and change failure rate.

This does not mean that governance and oversight are unimportant. What the data suggests is that concentrating approval authority in a committee or manager external to the delivery team creates bottlenecks and does not provide the safety benefit commonly assumed. Teams operating with peer review — code review by colleagues who understand the system — consistently outperformed those relying on external change advisory boards.

The practical takeaway: If your organization runs a Change Advisory Board that reviews and approves every production deployment, the evidence suggests this process is slowing you down without meaningfully reducing risk. A more effective model invests in automated testing, deployment pipelines, and peer code review so that quality is built into the process rather than checked at the gate. External approval can be reserved for genuinely high-risk or regulatory scenarios rather than applied uniformly to all changes.

Key Takeaways

• Find non-technical allies when driving legacy modernization. Legal and compliance teams can make the business case that engineering teams alone cannot.
• Extend your DevOps practices to the database. Version control schema changes, automate database deployments, and treat database migrations as first-class artifacts in your pipeline.
• Rethink change approval. Peer review within the team produces better outcomes than external change advisory boards. Invest in automated testing and code review instead.

The themes from DOES 2018 — modernization, database inclusion in CI/CD, and evidence-based governance — remain as relevant today as when they were first presented. The DevOps community continues to accumulate data that challenges assumptions baked into traditional IT operations, and the organizations willing to act on that data are the ones pulling ahead.