This article is based on reporting originally published by TechRepublic, covering remarks made by Brian Gregory, Director of IT at Express Scripts.
From “Do More With Less” to “Hire 1,000 Developers”
For years, the dominant philosophy in enterprise IT was austerity: squeeze more output from fewer resources. Express Scripts, a large pharmaceutical benefits management company, flipped that model on its head. After adopting DevOps practices across its engineering organisation, leadership approved the hiring of 1,000 new developers—a striking vote of confidence in the business value that a well-executed DevOps transformation can generate.
Brian Gregory, Director of IT at Express Scripts, shared the company’s journey at a technology event, offering candid lessons on tooling decisions, cultural change, and how DevOps shifted IT from a cost centre to a recognised value driver.
Context: A Company Built on M&A
Express Scripts grew significantly through mergers and acquisitions beginning in the 1980s. That history left the company with a fragmented landscape of disparate processes, legacy systems, and technology stacks acquired from different organisations over decades. DevOps became the mechanism for unifying those systems—and for accelerating the delivery of value across all of them.
Building the DevOps Toolchain
Gregory’s team didn’t start from scratch. They already had the ability to spin up and provision virtual machines quickly, which gave them a foundation to build on. From there, they moved up the stack, assembling a toolchain around several well-known open-source and commercial products:
- Pivotal Cloud Foundry — chosen as the core platform for application hosting and runtime management.
- Jenkins — used as the primary automation server to orchestrate CI/CD pipelines.
- Concourse — an additional pipeline automation tool (its maintainers describe it as a “continuous thing-doer”) used alongside Jenkins for orchestration.
- Artifactory — used to automatically download, cache, and compile code dependencies, bringing consistency and speed to build processes.
- Git — used as the source control repository, providing a single source of truth for all codebases.
Together, these tools enabled the team to implement continuous integration and continuous deployment (CI/CD) pipelines that dramatically reduced the number of manual steps between a developer committing code and that code running in production.
Buy vs. Build: A Critical Decision
One of Gregory’s most direct pieces of advice for teams embarking on a DevOps journey concerns the temptation to build internal tooling from scratch. His position is pragmatic:
“If I told you that you’ve got to figure out a way to get to work, what would you do? Would you build a car? You could, but if you could buy a car, then you could get to work faster and you could start delivering value.”
— Brian Gregory, Director of IT, Express Scripts
The principle isn’t that custom tooling is always wrong. Rather, teams should ask a pointed question before investing engineering time in building internal tools: Does this tool create differentiated business value that justifies the investment? If an off-the-shelf or open-source solution covers the use case adequately, the better ROI usually comes from using it and redirecting engineering effort toward the organisation’s actual product.
The Business Outcome: 1,000 Developer Hires
Once the toolchain was in place and CI/CD pipelines were running, the results became visible to leadership. Deployment steps from development to production were reduced significantly, and both developers and operations staff reported increased productivity. IT began to demonstrate that it could drive business outcomes—not just keep the lights on.
That shift in perception had a concrete consequence: company leadership approved the hiring of 1,000 new developers. To appreciate the scale, Express Scripts employs roughly 30,000 people in total, spanning healthcare professionals, pharmacists, and administrative staff. Adding 1,000 engineers is a substantial commitment. Gregory noted the magnitude himself:
“I started two and a half years ago, and I would’ve told you that would never have happened then—I would have said we would have been lucky to get 100. But it’s really taken off.”
— Brian Gregory, Director of IT, Express Scripts
DevOps Extends Beyond the Dev-Ops Boundary
Gregory was clear that the benefits of DevOps at Express Scripts weren’t limited to bridging the traditional gap between development and operations teams. The feedback loops and collaboration practices extended outward to business partners as well. That broader reach created new obligations for the IT organisation:
- IT teams must develop a genuine understanding of business goals and partner expectations—not just technical requirements.
- All technical teams must remain open to feedback and willing to adjust course when something isn’t working.
- Failure should be treated as a learning mechanism, not a reason to retreat to safer, slower practices.
“You’re not going to hit the mark on day one, nobody does that. It’s what you learn when you fail or you learn in that process that’s so important. That’s where the real value is.”
— Brian Gregory, Director of IT, Express Scripts
People and Culture: The Hard Part of DevOps
Technology choices matter, but Gregory was emphatic that the harder challenge in any DevOps transformation is cultural. The shift requires a fundamentally different mindset—one that not everyone will adopt immediately or enthusiastically. His recommendations for managing this:
- Find champions who embrace risk. DevOps adoption needs people who aren’t paralysed by the possibility of failure. Calculated risk-taking and experimentation are core to the practice.
- Develop leaders who empower, not gatekeep. Command-and-control management styles conflict with the autonomy that high-performing DevOps teams require.
- Bring people along at their own pace. Not everyone will understand the mission immediately. The goal is to keep the overall organisation moving in the same direction, even if individuals are at different stages of the journey.
Key Takeaways for DevOps Practitioners
Express Scripts’ story offers several actionable lessons for engineering teams and IT leaders considering or mid-way through a DevOps transformation:
- Start with what you have. The team leveraged existing VM provisioning capability before layering on more sophisticated tooling. Build on existing strengths rather than waiting for a perfect starting point.
- Choose a coherent, integrated toolchain. Pivotal Cloud Foundry, Jenkins, Concourse, Artifactory, and Git work together as a system. Evaluate tools for how well they integrate, not just their individual feature lists.
- Default to buying before building. Reserve custom engineering effort for problems that genuinely differentiate your product or organisation.
- Measure outcomes that matter to leadership. Reduced deployment steps and increased developer velocity are meaningful, but translating those into business impact is what earns investment.
- Treat culture as a long-term project. The mindset shift required by DevOps is real and takes time. Plan for it explicitly rather than assuming the tooling will carry the transformation on its own.
The headline outcome—1,000 developer hires—is a consequence of demonstrating value, not a starting condition. Express Scripts earned that investment by showing, incrementally, what a well-structured DevOps practice could accomplish.