Host Intro (Gene Kim)

Alright. For nearly a decade, we have had experience reports from nearly every industry vertical: airlines, manufacturing, healthcare, government agencies, manufacturing, military services, and so much more. But when we analyzed the 1,100-plus organizations that presented here at this conference, what became evident was that there were some industry verticals that were totally absent, one of which was the pharmaceutical industry, which was so important to society for regaining normalcy during the global pandemic.

That is why I am so excited about this next amazing presentation from Jamie Hook, Director and DevOps Lead from Pfizer, and Laura Tacho, CTO at DX. They will talk about how developer experience became so critical at Pfizer and how they helped their organization win, eventually helping thousands of developers across their organization. Here are Jamie and Laura. Thank you.

Laura Tacho

Hi, Gene. Welcome, everyone. Thank you so much for joining us. Gene, thank you for the lovely introduction.

You might tell that I am a little under the weather. My voice at least sounds a little under the weather. I promise I am feeling just fine. It is just taking my vocal cords a little bit of time to catch up with the rest of my body, so bear with me.

As Gene said, Jamie and I are here to share the story of Pfizer's Future of Development program. This is a culture change program and a developer experience program, and I am so happy to be able to share this story with you today.

Pfizer is a company that needs almost no introduction. They are a household name, one of the biggest pharmaceutical and biotechnology companies in the world. In 2023, the revenue was over $58 billion, and they have 88,000 employees globally. The scale on which Pfizer operates is just mind-blowing.

I am joined today by Jamie Hook, who is the Director and DevOps Lead at Pfizer Digital. I am Laura Tacho. I am the CTO at DX, and we are a developer experience company. We help you measure and improve developer productivity in your engineering orgs.

I actually met Jamie a few years ago when I was doing some engineering leadership coaching for some other engineering leaders in his group. As luck would have it, I joined DX last year in November, and Jamie and I were able to continue working together in that capacity. That is what is bringing us both here to share this story with you today.

The problem that Pfizer is trying to solve is: how can they innovate and keep up pace in order to match their vision of changing 1 billion lives per year? The story of Pfizer's Future of Development program is an important one and one that has true global impact, not just for the thousands of technologists who work across Pfizer, but for all of the people who are impacted by the work that Pfizer does in their daily lives.

Today we want to share the story of not just what this program is, but specifically why now was the right time to start. We are also going to talk a bit about what is actually being done as part of the program, what lessons have been learned, what challenges still exist, and finally, what metrics we are keeping track of to measure success and what results we can already share with you.

Jamie Hook

Cool. Thanks, Laura. Your voice sounds a lot better than it did yesterday when we had a little run-through.

Laura Tacho

It sure does. Hopefully I survive the next 15 minutes.

Jamie Hook

I am really happy to be here today as well and share our story. I will not be able to go into everything, but hopefully this will give you a flavor of what is going on.

Our story is very much a journey. We are still traveling. A lot of work has been done in the past few years. However, in the past six months, we have really ramped up our efforts. Let us take a look at what made us decide now was the right time for that ramp-up.

As a leadership team, we started hearing more complaints about the way some teams work, seeing more potential security issues, and various other problems. There was not a single aha moment, but when coming together to look at the root cause of the issues and complaints, this is the list we came up with. In the coming slides, I will touch on a few of these in some more detail and what led us to this realization that we had to do something on a larger scale.

Our commercial digital function at Pfizer has been centralized and growing for about 10 years. Prior to this, every country that Pfizer operated in basically did its own thing from a marketing technology perspective. Every country had a different tech stack with different vendors. Domain names were registered by the current favorite agency.

We now have multiple global platforms covering requirements ranging from content-heavy marketing sites to complex web applications. Our teams and platforms serve every country that Pfizer operates in, which is pretty much everywhere at this point. Looking at both contract and permanent staff, we scaled from around 100 people across all disciplines to over 1,000 pure technical resources. This brings our total number to north of 3,000.

We fostered and created a great culture in the early years of our team, bringing brand-new, crazy ideas like open source and agile methodologies to a large, risk-averse corporate. As this growth accelerated, it got harder and harder to maintain the spirit of exploration and technical excellence.

Over the years, as the organization has grown, more and more of our projects and teams are adopting older styles of ways of working, running with PowerPoint status updates and long release cycles.

However, the past few years have been busy at Pfizer. We have had to deliver results across all of our business lines in extremely compressed timelines. To meet these demands, the best engineers and practices were put front and center. During this, we were able to launch sites and solutions to multiple global markets at the same time. The fact that our teams were able to execute rapidly, respond to change, and deliver high-quality results has opened the conversation to evaluating the way we work. We want to ride this wave of understanding with our business partners and take the best parts of our delivery model to the wider organization.

We have a number of vendor partners, and contract resources make up a large portion of our staff base. We have noticed an increase in the turnover rate with some of these partners. Some of this can be attributed to Pfizer rolling teams on and off projects. Others can be attributed to managed service contracts where the vendor is fully responsible for the changes. No matter the cause of the turnover, turnover is a problem. We lose skills, knowledge, and culture.

There has also been a lot of change in the world in the past 10 years. For example, the word of the year in 2013 was selfie. That no longer feels like a new word to me. Ten years later, we have AI models that can generate a photorealistic selfie of you on the moon in a few moments. This is a silly example, but when we apply this lens of technical change to security, it really is eye-opening. In 2013, there were roughly 600 publicly reported data breaches. In 2023, this number reached over 3,200 in the United States alone. It is a dramatic increase, and the sophistication of the attacks keeps improving.

Given that background, what are we doing? Our corporate ambition, as Laura said, is to change a billion lives a year by 2027. It is a lofty goal that needs support from everyone in the company to achieve. We feel that this Future of Development program is needed to support this wider ambition, so we crafted our vision statement based on it.

Breaking down that statement, I know it is quite corporate to have a vision statement, but you also need something to rally around at times. Thriving and joyful tech teams: we want to be the organization that people want to join. We want the engineer's voice to be respected and empowered, and we want to be one of the best places to work.

Possibilities continuously explored: in the past, we have outsourced our technical strategy to vendors and outsourced our thinking. This is not smart. Our principal engineers will lead this now.

High standards: no organization is perfect, but we can always improve. As an example, we want our red-team security exercises to take much longer before a result is found.

Value and speed: let us ensure all our projects are focused on delivering value, not worrying about perfected status slides.

We have had the concept of principal engineers for a while. However, they have been limited to platform owners in most circumstances, in the most technical worlds. This has been really successful. Principal engineers are some of the most trusted technical leadership resources we have. We want to take the concept of principal engineers and elevate them to leadership positions across all of our key projects.

These principal engineers will lead the delivery of solutions and drive alignment to our technical strategy. We plan to invest in building a strong community around these engineers and, with time, develop internal career paths laddering up to principal engineer as well.

A guiding principle for this work is that we should be looking to make the right thing as easy as possible. Change is difficult at the best of times. If you are trying to implement change but also making it difficult to adopt, it is going to be a really tough road.

We want to make it easy to use our platforms by providing tailored training and access to industry certification courses. Elevated and proliferated permissions across the organization are really hard to manage. We are building tooling to ensure that the right people are controlling access to the right tools, and that elevated access accounts have focused training courses before permission is granted. We are investing in our CI/CD tooling to identify security and code-quality issues earlier in the development process as well.

The flip side of making the right choice easy is making the wrong choice hard. We want the easy choice to be retaining talent for the long term so culture can grow in the new world. It will be easier for us to capacity-plan projects for a trained, certified, and onboarded team than to onboard a new one from a vendor whenever there is demand.

A huge amount of technical knowledge at Pfizer is simply lost or inaccessible. We need to improve this. By having clear ownership over documentation, setting clear expectations, better training, investment in improved tooling, and people dedicated to developer experience, we can reduce the amount of time wasted trying to find the right answers.

So the right choice is easy and the wrong choice is hard. Let us now make it sticky. One of the most important things we are doing is creating some pilot projects. We have selected some major programs to integrate into Future of Development. There are key leadership roles across every one of these programs that will help embed changes we want to make and identify new things to work on. They will also help shape an ongoing recommended project team shape and operating model that we can roll out.

We are backing up these pilots with a real investment in people. We are hiring multiple principal engineers. We are creating a new team responsible for principal engineers, developer experience, and continuing to evolve our delivery model. We also have a number of smaller project-based teams working on the likes of training, security, and tooling.

This is how we structure our program at a very high level. Our sponsors are Mike Lamb, who is a VP overseeing all platforms and engineering, along with Brian Cincera, who is our Chief Information Security Officer. We split the work into three substreams, each with its own dedicated lead. Foundations is focused on all the things that we simply need to do or just be better at, such as training, security improvements, and CI/CD tooling. Accelerators is looking at how projects work differently with the Future of Development and actually running them. Enablers is finding ways to fund all of this work and spending a lot of time looking at the human side of these changes and how we best support everyone through it.

In the past few slides, I have touched on what I consider to be the most impactful changes we are making. There are many others as well that we do not have time to go into today. I want to spend a little bit of time talking about the challenges we have and are still facing in some areas.

Getting momentum for a program like this requires a large human investment. You cannot simply advise and state what the best practice is. You have to show it: pilot projects, organizational changes, implementation of better tools and resources, and lots of engagement.

Change at this scale needs to be well communicated and supported by those with influence from the start. However, as we continue, it is crucial to find champions at all levels of the organization, not just a top-down approach.

Some transformation programs like this can feel a little nebulous, at least in a large corporate, and we wanted to ensure that the program had hard deliverables such as the tooling changes and new dedicated teams, but also the culture and organizational change to the way we deliver. To make this as transparent as possible, each workstream within Future of Development produced a charter stating what will be delivered in the short term and also the long-term objectives. I believe we ended up with about 13 of these charters. They have proven invaluable to gain a shared understanding of what this program is and what the explicit deliverables are.

Not everyone is going to be on board, and not everyone is going to be happy. Sometimes you are not going to be able to easily change their mind. That is okay, but it does have to be managed and understood. Spend time to find who your cheerleaders are and who the main detractors are. Understanding both of these groups is key. If we can understand what is driving their views, we can work to influence or allay their concerns.

Part of bringing everyone on board is to ensure we all have a shared understanding of the problem and why the change is needed. In the first few months of this program, when it was obvious to us why we had to do this, we had a hard time getting that message to land with some of the team. Over time, this message was understood, but it took lots of effort and different approaches to get the messaging right.

A great culture can, and for us did, materialize naturally with the right leaders in place in the early days. I truly believe that so many aspects of this program will come down to a careful curation of our culture. We for too long have left it to fend for itself, thinking that because it was so solid, it would naturally continue to permeate through the entire organization. However, as we have grown, we now realize that it needs intentional effort to scale and grow that culture.

That was a whistle-stop tour. That is everything for me. Hopefully you have a better idea of the why and what of this program. I am going to pass over to Laura to discuss how we are looking at measuring our success going forward and some of the results we have also had to date.

Laura Tacho

Thanks, Jamie. This program has a massive impact. It is a comprehensive program, and a program so comprehensive also needs comprehensive measurement: multifaceted and multi-level. The approach that Pfizer has taken to measure success for this program hits on three levels.

We have Future of Development program-level measurements. This first quarter's worth of work specifically had an emphasis on creating long-lasting teams with sticky knowledge, hardening security and permissions across all applications, and doing that while simultaneously improving the developer experience. This is no small task. There are specific measurements related to the Future of Development program as a whole that Pfizer is tracking to make sure that the program is being executed effectively.

We can zoom into each of those project-level initiatives, or the charters that Jamie spoke about. These are numerous. At the project level, there are more specific measurements of success or measurements of completion, such as impacted resources and other project-defined metrics. For example, the number of inactive accounts that have been identified and purged, or the amount of time it takes for a red-team exercise to result in a finding.

Then zooming way back up, we have the developer experience. This is something universal to every single developer who is working within Jamie's group, regardless of whether they are working on a very specific project related to the Future of Development or being impacted more peripherally simply by working on the golden path that this program is establishing.

To measure how effectively and efficiently Pfizer's technologists are able to work, Pfizer is keeping track of four key DevX measurements, which are speed, ease of delivery, quality, and wasted time per week on the developer level.

As Jamie mentioned, this project is still fairly new, but we are excited to be able to share with you some of the results that we have already been able to observe and measure.

Starting on the program and project side, Jamie's org has been able to establish a habit of regularly conducting red-team exercises already. All repos now are equipped with automatic code-quality and security scanning tools, and all inactive accounts have been identified and removed across all services. Developer turnover was also something top of mind, especially for the early stages of this work. Since starting the program, there has been a 33% decrease in developer attrition risk. Again, this is very early stages, but there is a lot of promise here on the program and project measurement side.

Telling the story about developer experience at Pfizer is a bit of a longer story because a lot of the initiatives that play into developer experience actually predate the Future of Development program. We can sometimes think of Future of Development as a formalization of some of the efforts that were already underway.

Pfizer is using DX to first take baseline measurements, which was done back in autumn of 2022, but now to update and take new developer experience measurements every quarter so we can look at how these numbers are trending and changing over time. Then we can correlate that with the work of Future of Development and see how this program is actually impacting developer experience.

The numbers that I will share with you represent changes since the last quarter, the last three months, which really marked the beginning of the formal Future of Development program. But again, many of the improvements to developer experience were underway before this program's official start.

Quality is something that is both a program-level metric and also one that is measured here in DevX. 6.6% more developers feel the code base is more stable and technically sound. At the same time, 6.3% more developers are writing documentation more frequently, which is something Jamie just spoke about: making knowledge sticky, making it persistent, and making it stay around.

Pfizer also uses DX to track delivery capability metrics. The capability to deliver quickly is a cornerstone of the developer experience that Pfizer requires to innovate at the speed needed to reach that vision of changing a billion lives per year. Compared to just last quarter, 33% more developers can resolve an incident in less than one hour, and 22% more developers can deploy in less than one hour.

These are massive changes and such a testament to the amazing work that Jamie and his group are doing. Overall, since the beginning of the Future of Development program, 11% more developers feel that it is easier to deliver software at Pfizer. When you think about the global scale and the human impact, it is quite mind-blowing to think about the impact that the sum of all these changes is having.

Six months from now, we would love to have more updates here to continue this trend. In six months, it is planned to have all of the platforms have a training plan and content developed, a new permissions model, tooling in place to more proactively manage secrets and credentials. We want to see a continued increase in developer satisfaction, and all of those new principal engineers that Jamie spoke about with this new community, we want to see them placed and thriving in their roles.

There are some places where we need your help. Those of you who are part of this community, if you have an example of community building or building a community of practice for principal engineers, we would love to hear about what has worked, what has not worked, and lessons learned. Also, if you are operating in a similar context, highly regulated and with a similar sense of scale, we would love to hear any examples of excellence or any lessons learned that you would like to share with us. That would be tremendously helpful.

Jamie and I would love to hear from you. Of course, we will be in Slack to answer questions, and we will leave our contact information up here for a little bit so you can connect with us on LinkedIn or shoot us an email.

Thank you so much for letting us share this story with you. We look forward to exchanging with you, maybe hearing some of your own stories, and we will both see you around the internet. Thank you.

Host Outro (Gene Kim)

Thank you so much, Jamie and Laura, and congratulations on all your fantastic achievements supporting people doing such important work. Thank you.