Host Intro (Gene Kim)

So for nearly a decade, we've had experience reports from nearly every industry vertical — airlines, manufacturing, healthcare, government agencies, military services, so many more. But when I actually analyzed the 1300-1500 talks a couple of years ago, I was struck by the absence of one industry: pharmaceuticals. They famously have spent so much effort on R&D — where's the pharmaceutical organizations? So I was so delighted when we got a submission from the team at Pfizer.

So up next is Sharon Taylor, Director of DevOps Program Management. She'll be co-presenting with Laura Tacho, CTO at DX. We'll talk about how developer experience became so critical at Pfizer and how they helped their organization win — eventually helping thousands of developers across that entire organization. Here is Sharon and Laura.

Laura Tacho (DX)

- slide: "Pfizer's Future of Development" (DX + Pfizer logos) - slide: "Sharon Taylor — Developer Enablement Lead, Pfizer / Laura Tacho — CTO, DX"

Thank you Gene. Good morning everyone. We're both delighted to welcome you to day three. We're here to tell the story of Pfizer's Future of Development program. Future of Development is a program designed to modernize and accelerate software development at Pfizer.

I'm joined here by Sharon Taylor — she's the Developer Enablement Lead at Pfizer. My name is Laura Tacho, I'm the CTO at DX. We are a developer experience company. We connect leaders with metrics to improve developer productivity and increase the developer experience at your organizations and companies.

- slide: (Pfizer corporate fact sheet) "$58.5 Billion Revenues in 2023 / 37 Manufacturing sites worldwide / ~200 Countries where we sell our products / 112 Projects in our pipeline / ~88,000 Employees globally / 9 Products with sales greater than $1B in 2023 / CEO: Albert Bourla / Global Headquarters: 66 Hudson Yards, New York, NY 10001 (USA) / Stock Exchange Listing: NYSE (PFE)"

Pfizer needs almost no introduction. They're one of the biggest pharmaceutical companies in the entire world. Last year they had $58.5 billion in revenue. There are 88,000 employees globally and presence in over 200 countries.

A company of this size has goals that are equally huge, and Pfizer right now is on a mission to change 1 billion lives per year.

- slide: "THE PROBLEM — Pfizer's current development practices must evolve to keep up with the vision of changing 1 billion lives a year"

And in order to change 1 billion lives per year, their software development practices need to change to keep up. That is where Future of Development was born.

- slide: "QUESTIONS TO ANSWER — 1 Why now? / 2 What are we doing? / 3 What are the challenges? / 4 How can we measure it?"

We're going to talk about why now was the right time for this change, what's actually being done on the ground in the engineering teams, some of the challenges that have come up, and how we measure success — sharing some of the amazing results we've had in the early stages.

To answer these questions, I'll hand it over to Sharon.

Sharon Taylor (Pfizer) — Why now?

- slide: "WHY NOW?"

Thank you, Laura. I'm really delighted to be here today to share a little bit about our journey so far with the Future of Development program.

While the program itself began at the end of 2023, the catalyst for change began to emerge long before that.

- slide: (timeline) "FAST GROWTH / INCREASED DEMAND AND SCOPE / AGING DELIVERY MODEL / DESIRE TO RETAIN TOP TALENT / EVOLVING SECURITY RISKS"

As an organization, we had scaled rapidly and to a significant size. Also, as our go-to-market model was changing in the commercial space, the demand for digital solutions was growing, and the breadth of our portfolio was growing. Between 2020 and 2023, our commercial digital portfolio grew by 345%.

Unfortunately, our delivery model was not keeping pace with this level of change, and the strain was beginning to show. We were really struggling to attract and retain top engineering talent, as our teams were becoming increasingly frustrated with the ability to get things done. And alongside that, we were starting to see increasingly sophisticated cybersecurity risks.

- slide: (illustration: small group → large crowd) "The organisation grew from 100 to over 3000."

The sheer scale of our organization had become a challenge. Within the platforms and engineering team, our organization had grown from 100 to over 3000. The global distribution of the teams and increasing breadth of our portfolio meant that silos were beginning to emerge — and there was a real lack of clarity around who was responsible for what.

- slide: (same illustration) "The original team culture was strong, but couldn't sustain the rapid growth."

Our once-strong culture was suffering as a result of this rapid growth. We could tell from our developer experience survey that developer engagement was also suffering, as people were becoming frustrated by the challenges they faced when trying to do their best work. The element of fun that had been fundamental to getting through the challenges of the past was disappearing.

- slide: "In recent years we have had to work faster and on a scale we have not seen before. This changed the status quo."

In recent years, we've had to work faster and on a scale that we have never seen before.

- slide: "As this rapid growth created some inefficiencies, the demand for innovation also increased, creating more pressure to create capacity and to execute efficiently."

Our teams were faced with trying to balance delivery against aggressive timelines and the need to innovate and experiment. It was becoming a seemingly impossible conundrum.

- slide: "Attacks are becoming more sophisticated. Our teams need constant learning, but also to embed vigilance and awareness into our culture."

We were also seeing increasingly sophisticated cyber risks. We deployed red teams to hack ourselves and we identified multiple weaknesses that could be exploited simultaneously, creating risks to our business and our customers. We needed to effectively communicate those risks and shift the culture to develop an even greater focus on security. In a highly regulated industry, our teams were very well versed in delivery in a compliant and secure manner, but we needed to elevate security to another level.

- slide: "There's too much at stake to move slowly"

We had to act, and act with purpose. Failure to change was not an option.

What are we doing?

- slide: "WHAT ARE WE DOING?" - slide: "OUR VISION — We are the industry-leading digital organization, working at the cutting-edge of technology and operating with the speed, sustainability and agility to change 1 billion lives a year"

Given that background, what did we decide to do? We set out a bold vision to support our corporate ambition to change a billion lives per year. This wasn't just about giving tools and processes to our developers — it was about changing the culture and the fabric of our organization.

- slide: "Our future is / Which looks like — Thriving and joyful tech teams: Passionate and productive tech debates; People are empowered to make decisions & say no / Possibilities continuously explored: Principal Engineers drive tech direction, not vendors; Experiment scientifically & learn from our mistakes / Consistently applied high standards: Red team exercises take much longer; Highly engaged LT ready to help resolve disputes / Value delivered at speed and the highest quality: Demonstrable progress over status slides; Fast investment decisions."

How does that vision translate to our proposed ways of working? In thriving and joyful tech teams, we wanted to be the organization that people wanted to join and enjoyed working in. We wanted our engineers' voice to be respected and for our engineers to be empowered.

In the continuous exploration of possibilities — in the past, we'd outsourced some of our thinking and technical strategy to our vendors. We wanted our principal engineers to have clear accountability for that technical strategy, and experimentation is a critical element of that new approach.

In high standards, we recognize that no organization is perfect and we can always improve. Through the continuation of our red team exercises, we wanted to make sure that we were identifying those opportunities to learn and grow.

And of course, we needed to continue to deliver value at speed and to the highest quality.

- slide: "PRINCIPAL ENGINEERING FUNCTION — Community of most tenured technologists / Lead technical decision making / Collectively drive technical strategy / Make expertise engrained in daily decisions"

So who are the principal engineers? We already had some principal engineers who'd become trusted experts to their business partners. We wanted to expand this to all of our major platforms and projects. These are our trusted technical leaders driving an aligned technical strategy. And it was also about implementing the structure and processes to support our principal engineers and set them up for success.

- slide: "MAKE THE RIGHT THING EASY — Additional training for all technical contributors / Grant certain permissions only after specialised training / Leverage talent from previous projects instead of onboarding new developers / Improved CI/CD tooling"

Simplicity was a guiding principle for our approach. For example, we wanted to ensure that everyone had the appropriate training for the work they're doing — permissions conditional on specialized training. Through the implementation of talent tooling, we built greater visibility for our managers of available talent and skills, to redeploy talent as needed and to mitigate delays with onboarding and loss of talent. We also wanted to provide our teams with improved tooling with a focus on delivering secure code.

- slide: "MAKE THE WRONG THING HARD — Reverse incentives are in place to add a barrier of entry for undesired behaviours, like bringing in new contractors for every engagement instead of fostering long lived teams."

The flip side is to make the wrong thing hard — we deployed reverse incentives. The increased timelines to onboard new contractors (due to more stringent training and security needs) meant that we were more likely to look around within and bring on board the talent we already had. And the ongoing costs associated with providing these new capabilities was applied to all contractors, which reduced the risk of supplier-benched resources having access to our systems when no longer required. Since the beginning of this year, we've reduced our contractor base by over 700.

- slide: "MAKE KNOWLEDGE STICKY — Improve documentation to surface existing knowledge / Establishing principal engineering function / Incentivise longer contractor relationships / Discourage fungibility of contractors / Rebalance ratio of colleagues vs. contractors"

Historically, we'd relied on tribal knowledge being shared within a small network, but that was no longer sustainable given our new scale. We needed to become a learning organization and find ways to embed this tacit knowledge into the culture of our organization. Document, share, and maintain retention of this knowledge is key.

- slide: "ENGINEERING-LED INNOVATION — 4 key roles on all major programs; Principal Engineer is front and centre / Principal Engineer leads technical ideation / Progress demonstrated by live demos, not slides! / Innovation events planned to offer sneak previews of working prototypes that address real-world business challenges"

With our new Future of Development ways of working, we implemented four key roles within each program, and the principal engineer is a critical role — responsible for leading the technical ideation from the very beginning of the program.

Another practice that we stopped was the heavy reliance on PowerPoint status reports to demonstrate progress. Instead, live demos are encouraged to show actual progress. And as we embed these new ways of working, we're launching innovation events to offer sneak previews of working prototypes that address real-world business challenges. These events will be based on a challenge format where teams can respond to high-priority business needs or come up with challenges of their own.

- slide: "PILOT PROJECTS — Establishing ways of working / Selecting top impact projects / Key lead positions in place"

Outside of the changes we're making to training, processes and platforms, we need to work with our teams to ensure that our projects are being delivered within this new model. So we selected some of our largest and most impactful programs to be the pilots for this initiative. A key objective for these pilot projects is to ensure that our new ways of working are flexible enough to be easily applied across our diverse portfolio of engagements.

- slide: "INVESTMENT — Adding multiple new principal engineers / New team created to manage devex and Principal Engineers / New dedicated project teams on org-wide initiatives. Future of Development covers 1000s of application and code repositories"

This is not a one-time initiative — we are investing for the long term. In addition to increasing the number of principal engineers, we've also employed dedicated security resources with a focus on our commercial portfolio, and we've established dedicated teams to focus on developer experience and developer enablement.

- slide: "PFIZER DIGITAL STRUCTURE — Chief Digital Officer Lidia Fonseca. Horizontal Functions: Client Partners / Digital Strategy / AI & Analytics / Digital Medicines / Enterprise Platforms & Security. Division-Focused Creation Centers: Commercial Creation Center (C4) / R&D / Global Supply / Enterprise Functions"

How does this fit into Pfizer's organizational structure? Within Pfizer Digital, we have division-focused creation centers and we also have horizontal functions. We started this initiative within the Commercial Creation Center, working in close partnership with our Global Information Security team within Enterprise Platforms and Security.

The program is sponsored by Mike Lamb, the VP of Platforms and Engineering within the Commercial Creation Center, and was previously partnered with his GIS counterpart. Due to changes in the organization, we don't currently have a GIS sponsor, but as soon as that new person is appointed, they will also co-sponsor this program. This is very much a joint effort between the development teams and our security teams.

- slide: "FUTURE OF DEVELOPMENT PROGRAM STRUCTURE — Executive Sponsor: Mike Lamb VP, Platforms & Engineering. Foundations (Learning, Training & Tooling) / Accelerators (Pilot Projects & Communications) / Enablers (Financial model & change management). Joint partnership between Commercial Creation Center & Global Information Security"

With regards to the program structure, we have 13 work streams that sit within three major work streams. Foundations is focused on all the things that we simply need to get better at — improved training, security improvements, and improved tooling. Accelerators is looking at how the projects work differently with Future of Development and actually running them. And within Enablers, we are looking at ways to fund these new ways of working and also looking at the human element of the change.

What are the challenges?

- slide: "WHAT ARE THE CHALLENGES?"

The program's significant, and I've shared part of what we're doing today. And as with any change program, it hasn't been without its challenges.

- slide: "BRINGING CHANGE TO LIFE — Change Fatigue: Future of Development occurring alongside significant organizational change / Leaders create the circumstances that empower their teams to play an active role in change / Ensuring that people feel that they are a part of the change and not that it's something that's being done to them"

Change fatigue is real. This program is occurring alongside significant organizational change. So we created a change management plan for Future of Development and aligned it with broader organizational change management plans to ensure that key messages stand out and reach the right audiences. The feedback loop is an integral component of this, and that includes our DX survey.

- slide: "BRINGING CHANGE TO LIFE — Bridging the gap between theory and practice: Meeting each team where they are (recognizing the diversity in our portfolio and working styles) / Scale of development team and high rate of turnover makes engagement difficult"

It's also important that these new ways of working don't just exist on paper. We created colleague workshops to allow colleagues to experiment with the new ways of working in a safe space before applying them in day-to-day activities. So far, a third of our Commercial Creation Center colleagues have attended these workshops, and the workshops evolve based on the feedback that we received from previous attendees.

- slide: "STAKEHOLDER ENGAGEMENT — Executive sponsorship is essential / Find the right champions / Must have a charter and budget / Advocacy alone is not enough to create change"

The cultural change is also required to be driven at all levels of the organization. We shared our initial plans with the leadership team and then they created the overarching program goals, creating a sense of shared responsibility.

- slide: "VENDOR PARTNERSHIPS — Vendor partnerships and communication are critical to success / Engineers need to understand what changes are implemented, and need reinforcement and support from vendors / Must create buy-in to new ways of working, paired with strong expectation setting"

Our vendor partnerships are also essential to the success of this program. We engaged early with our vendors to obtain their insights about working with us and how we could improve things to achieve our Future of Development vision. Ongoing two-way communications have helped to establish a sense of priority and ensure that any issues are addressed in a timely manner. Each vendor has named a dedicated tech lead to partner with us on this.

- slide: "CHANGE CURVE ISN'T THE SAME FOR EVERYONE — Not all leaders will be bought in / Work on influence skills and recognise situational authority / This problem isn't happening on my team… Previously, an easier path was to obscure the pain. Now need to bring everyone into the same reality."

The other thing to recognize is that we're all going through this change journey at a different pace. So that ongoing two-way communications with key stakeholder groups, including our leadership, is also critical.

That's just a small snapshot of what we've been doing. Hopefully that's giving you some insight into our Future of Development program and what we're trying to achieve. I'm now going to hand over to Laura to discuss how we are measuring our success now and moving forwards. Thank you.

Laura Tacho — Measuring Success

Thanks Sharon.

- slide: "MEASURING SUCCESS" - slide: "FOD MEASUREMENT FRAMEWORK — Thriving and joyful tech teams: DXI and DevEx Drivers (DX) / Possibilities continuously explored: Experimentation Driver (DX) / Consistently applied high standards: Harder to Hack / Value delivered at speed and the highest quality: Program ROI"

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 (DXI) and developer experience surveys delivered and managed through DX.

We're also looking at the Experimentation Driver, which is a mix of workflow metrics and sentiment metrics to figure out: are developers satisfied with the amount of technical experimentation that they get, and how often are they actually getting the chance to do experiments and drive innovation forward?

Consistently applied high standards is really digging into that harder-to-hack measurement. Sharon mentioned that they've developed red team exercises to hack themselves — so we're trying to make sure that it takes longer to hack.

And finally, program ROI is so important. We need to make sure that the value for the business is there.

- slide: "METRICS METHODOLOGY — Collect baseline, then measure against it / First baseline in 2022, now every quarter to track progress of developer experience / Must include oppositional metrics to ensure we don't lose sight of big picture, ex. speed vs. value / Partnership with DX"

In addition to these measurements, we're also collecting some project measurements. The first step in this measurement methodology was to collect a baseline. Future of Development is largely a formalization of some work that was already underway. DX has actually partnered with Pfizer to take the first baseline for these particular measurements back in 2022. Now we're taking them every quarter, to make sure that we don't fall victim to survey fatigue or measurement fatigue, but we're also getting incremental insights to track progress over time.

- slide: "PROGRAM AND PROJECT MEASUREMENTS — Regularly conducting red team exercises / All repos have security and code quality scanning / All inactive accounts have been removed / Attrition risk decreased by 33%"

In addition to these program metrics, we're looking at: are we doing what we say we're going to do? Are we conducting those red team exercises? Up until now, we've made sure that security and code quality scanning is in place in every repo. There's been work done to remove all the inactive accounts. As we've done this, we've noticed that attrition risk has actually decreased by 33%. This is such a testament to how paramount and important developer experience is to retaining top talent. It is good for the business to have a great developer experience.

- slide: (four-quadrant results) "91% of developers are satisfied with their ability to deliver a secure application / documentation no longer a top 2 priority after 6 months of focused effort / 33% more developers can resolve an incident in <1 hour / 22% more developers can deploy in <1 hour"

As we look into the metrics, the story gets better. Right now, 91% of developers are satisfied with their ability to deliver a secure application. Also, after about six months of very focused work on documentation, documentation is no longer a top-two priority for developers — it's actually fallen to number five after some very focused efforts to improve the quality of documentation.

If you think about a company like Pfizer and the scale that they're operating at, and talk about more secure applications with better documentation, where my mind goes is: that must be getting slower. But in fact, the opposite has happened at Pfizer. 33% more developers can now resolve an incident in less than an hour, and 22% more developers can deploy in less than an hour. When you think about the scale that Pfizer operates at, this is tremendous success.

- slide: "15% more developers feel it is easier to deliver software — increased from 11.3% in Q1 24, highest value to date"

Finally, we're tracking how many developers feel it is actually easy to deploy software at Pfizer. This number keeps getting higher. Right now, 15% more developers feel it's easier to deploy software than before Future of Development. This is up from 11.3% last quarter, and this number keeps steadily going up. So given the choice between better software faster, or worse software slower, Pfizer's definitely chosen better software faster.

- slide: "IN 6 MONTHS… 100% of platforms have a training plan and content / >95% of developers satisfied with security practices / Permissions model overhauled and implemented / Tooling in place to proactively manage secrets/credentials / Continued increase in developer satisfaction/developer joy / All new Principal Engineers in role"

Of course, this is not without more work to do. We want to make sure that in six months, 100% of platforms have a training plan and content. We want to see developer satisfaction with security practices get up above 95%. There's more work to do about permissions models, security credentials, developer experience. We're also trying to get all of those principal engineers placed on their teams and thriving in their roles.

01Asks

If you have principal engineers at your company, or fellows, or something similar — that's a place where we would love your help. Right now Pfizer's trying to stand up a community of practice for these very senior, tenured technologists, and we would love to hear from you all some examples of what you're doing. These dispersed principal engineers can come together and share their knowledge with each other.

We'd also love to hear examples of excellence. If you're working in a similarly regulated industry or at similar scale — what are you doing? What can you share with us? What are some of your lessons learned?

Sharon and I will be around for the rest of the day before heading to the airport, like most of you in this room. You can also find us on LinkedIn. Thank you in advance for sharing your words of wisdom and your tips with us, and we'll see you around the internet.

Thank you.