Pfizer’s Future of Development
Pfizer’s path to faster software delivery, decreased attrition risk, and a reinvigorated engineering culture.
This is the latest issue of Engineering Enablement, a weekly newsletter covering the data behind world-class engineering organizations. To get articles like this in your inbox every week, subscribe:
This week’s newsletter is from Laura Tacho, DX’s CTO. Last month Laura presented alongside Sharon Taylor, Developer Enablement Lead at Pfizer, at ETLS about Pfizer’s Future of Development program. In this issue, Laura describes what the program is, why it was so important for Pfizer, and the outcomes it has delivered for the company so far.
Here’s Laura.
Pfizer is a company that almost needs no introduction: they're one of the biggest pharmaceutical companies in the world. A company of this size has goals that are equally huge, and Pfizer is on a mission to change 1 billion lives per year. Software is crucial in hitting this goal and touches everything from research, to manufacturing, to physician and patient experience. So to keep up, their software delivery practices need to change.
This is where the Future of Development was born—a program designed to modernize and accelerate software delivery at Pfizer.
In this newsletter, I’ll describe why Pfizer felt that now was the right time for this change and what’s actually being done. Then, I’ll explain how they’re measuring success and the outcomes they’ve seen so far.
Why now?
The Future of Development program began at the end of 2023, but the catalyst for change began long before that. Pfizer had scaled rapidly, as did demand for their digital solutions. However, their delivery model was not keeping pace, leading to visible strain. They were struggling to attract and retain top engineering talent, and teams were becoming increasingly frustrated with their ability to get things done. On top of this, they were starting to see increasingly sophisticated cyber security risks.
Other issues were also becoming clear: silos were forming, there was a lack of clarity around who was responsible for what, and Pfizer’s once-strong culture was suffering. A developer experience survey revealed that engagement was also suffering, as people were becoming frustrated by the challenges they faced when trying to do their best work. The sense of fun that had been fundamental to getting through the challenges of the past was disappearing.
Together, these issues drove the need for change. As Sharon put it, “We had to act with purpose—failure wasn’t an option.”
The vision
Pfizer’s engineering leaders and developer enablement teams set a bold vision to support their corporate ambition of changing a billion lives per year. This wasn't just about giving tools and processes to their developers, it was about changing the way they worked.
They identified three areas to work as levers to increase efficiency:
Thriving and joyful tech teams. Technical contributors should work in an environment where it’s easy to get work done, where friction and waste are addressed and eliminated.
Possibilities to be continuously explored. Principal engineers drive technical direction, with capacity created to run experiments, explore new ideas, and learn from mistakes.
Consistently applied high standards, especially when it comes to security and reliability.
This would lead to the outcome of value to be delivered at speed and the highest quality. They wanted to see fast investment decisions and demonstrable progress, and be able to draw a line between speed, quality, and revenue.
Key changes
To achieve their vision of accelerating software delivery while improving quality, Pfizer needed to update their default way of working. At the same time, they recognized that change management at this scale has significant challenges.
To overcome this, their changes were guided by two principles: make the right thing easy and the wrong thing hard. If they could make the path from A to B as easy as possible and have that path be in line with the new ways of working, then the changes are much more likely to turn into habits and default behavior. In some cases, reverse incentives were deployed to add resistance to the wrong path.
A few concrete changes:
Expand the Principal Engineering function. All major platforms and projects now have a Principal Engineer to drive technical direction and innovation.
Make training accessible. All technologists should have the right training for the work they’re doing. On top of accessibility, they implemented some talent tooling so that managers had greater visibility into who was trained or certified in what.
Retain more talent. Instead of bringing in new contractors for each new project, make it easier to rotate existing technologists to new projects. Additionally, introduce slight friction for bringing in brand new contractors to discourage the practice of contractors being fungible.
Make knowledge sticky. Find ways to embed this tacit knowledge into the culture of the organization by improving documentation, incentivizing longer contractor relationships, and discouraging the fungibility of contractors.
Demos, not PowerPoints. Live demos are now encouraged to show actual progress, not a status slide in PowerPoint.
To make sure projects were being delivered within this new model, they selected some of their largest and most impactful programs to be the pilots for this initiative. A key objective for these pilot projects was to ensure that their new ways of working are flexible enough to be easily applied across a wide set of project types.
Another important element of their rollout was the creation of a change management plan for Future of Development, which was aligned with the broader organizational change management plans.
Measuring success
You can imagine that a program as robust and far-reaching as Future of Development needs a measurement framework that is equally as comprehensive. The Future of Development measurement framework has four pillars:
Thriving and joyful tech teams are measured via the Developer Experience Index and developer experience surveys delivered and managed through DX.
Possibilities continuously explored: They’re using the experimentation driver, which is a mix of workflow metrics and sentiment metrics to figure out how satisfied developers are with the amount of technical experimentation that they get, and how often they’re actually getting the chance to do experiments and drive innovation forward.
Consistently applied high standards is digging into a ‘harder to hack’ measurement. Pfizer developed red team exercises to hack themselves, and they’re trying to make sure that that number gets longer, showing that they’re harder to hack.
The three previous pillars are seen as levers that influence the ultimate goal: delivering high quality software quickly, in order to provide business value. To track the ROI on this program, they’re looking at metrics related to business impact: are they spending more time on innovation while also bringing value to the business?
Results
The program started with a baseline measurement in 2022. Since then, Pfizer has seen the following results:
Attrition risk decreased by 33%
91% of developers are satisfied with their ability to deliver a secure application
After about six months of very focused work on documentation, documentation is no longer a top-two priority for developers. It's fallen to number five, after some very focused efforts to improve the quality of documentation.
Within ~8 months from the beginning of 2024, they had reduced their contractor base by over 700 while retaining highly trained and qualified technologists.
33% more developers can now resolve an incident in less than an hour
22% more developers can deploy in less than an hour.
15% more developers feel it's easier to deploy software than before Future of Development
Those last three are particularly striking: with a company as large as Pfizer, we expect that adding security and additional documentation to the software development process would slow things down. But in fact, the opposite happened at Pfizer. They increased security, quality, and documentation, all while getting faster.
Looking ahead
Of course, this success doesn’t mean there is not more work to do. Pfizer wants to make sure that in six months, 100% of platforms have a training plan and content. They also want to see developer satisfaction with security practices get up above 95%, and to have all principal engineers placed on their teams and thriving in their roles.
The Future of Development program is still young, but they’ve already seen a lot of promising success. There’s too much at stake here to move slowly, and given the choice between better software faster or worse software slower, Pfizer has chosen better software faster.
A special thank you to both Sharon and Laura for sharing this story.
That’s it for this week. Thanks for subscribing to Engineering Enablement. This post is free so feel free to share it.
-Abi
 | A guest post by
|