Developer Experience at American Express

Abi Noda: Okay. All right, let’s dive in. Michelle, really excited to have you on the show today. Thanks so much for your time.

Michelle Swartz: Thanks, Abi. It’s a pleasure to be here.

Abi Noda: I’ve been fascinated and inspired by the DevEx journey at American Express. And where I want to start today is by you sharing where does the DevEx focus and effort live within your organization today?

Michelle Swartz: Yeah, so I have to tell you, it’s been a really great opportunity working in this team from really its inception and this particular organization, actually falls underneath our chief technology office. And it’s underneath a larger organization called Developer Experience. And it’s really one of the key drivers, what we call our technical heartbeat. And I’m really just a custodian for an amazing group of engineers and product colleagues that truly focus all their efforts on enabling our engineering community. And some of the things that this group is responsible for is really around advocacy work. And so we have our open source program office, we have communities like guilds and communities of technical practice. We do certain types of events, we have boot camps, we have DevCons, and then our technologist sentiment survey.

Abi Noda: And one of the things that was interesting when we were talking earlier is how American Express thinks about developer experience. As I understand there’s an enablement side which you are responsible for as well as a platform side that a colleague of yours is responsible for. So share the breakdown and how you think about developer experience.

Michelle Swartz: Yeah, so when we think about it, we have a pretty comprehensive developer experience program, both from an enablement and advocacy side. Again, it’s about how do we make it real for the engineers? How do we set the tone, the context, how do we bring clarity into the bigger picture? Is there a pattern or practice that needs to be aligned for a tool or feature? And is there feedback that needs to go back to the platform team? And then my colleague, Tim Cleaver, he really thinks about the platform side. And so what is the tooling that’s needed to support the overall, what we call path to production? And so much of the community work actually that is being done today was actually done by Tim Cleaver prior to moving over to the developer platform role.

So I think it really creates a great synergy. In fact, a lot of people talk about us about two sides of the same coin. He’s got some of the advocacy and community work, but then he’s been able to bring that over to the platform side and I’ve been able to continue to focus on the community, the feedback and how we actually deploy some of the amazing tools and platforms that his team is responsible for now.

Abi Noda: One of the things you shared with me when we were speaking was your team’s mission is, “to make American Express an amazing place to be a software engineer.” And you described to me that this lines up with your larger people and culture technology strategy. I want to dig into that a little bit. When you say that it lines up, what does that mean? For example, do you have concrete collaboration with your people and culture organization or is this more implicit?

Michelle Swartz: Yeah, so again, like you said, we want to focus on making Amex an amazing place to be a software engineer. And we want to be able to grow the best developer culture that empowers our teams to focus on delivery. And it does line up to what we call a people and culture technology strategy. And a piece of this is, it’s important to us to be able to attract, grow, develop, and retain top tech talent. And to do that, we’ve got to be able to ensure that we’ve got a culture that’s inclusive where colleagues can feel like they belong. And the overall tech strategy has a focus on people and culture. And we partner very close within the team that is the custodian for this particular strategy pillar to really make technology the best place to work in. And while they are focused on the overall technology strategy and all of the colleagues that work in technology, our focus is more of a drill-down really focused on our engineering developer community.

Abi Noda: This speaks me to a broader question. Something I hear often from folks that I talk to is that while tech companies like Google and Amazon, they invest a lot in developer experience, I hear folks say for non-tech companies like Amex or companies that are traditionally not tech companies, that it can be more of a challenge to get leaders on board with the idea of developer experience and why it’s worth investing in developer experience. I’m curious to learn what sort of a challenge this may have been at Amex, especially earlier in your journey.

Michelle Swartz: So for many years, I think our leadership team has recognized the importance to attract and retain great tech talent. And there’s a commitment from our leadership team. To your point, we’re not seen as a tech organization, we’re seen as a financial organization. And so I think the leadership team recognizes that we really do need to focus on the developer experience. And look, I don’t get a blank check, they’re obviously competing priorities, but leadership has to be responsible for when we think about the use of the funding. And I may not receive all the funding that I actually put in for, but it has not been my experience that I didn’t receive the funding that I needed.

Abi Noda: And we’re going to get into your journey, the step-by-step journey here in a couple of minutes. But broadly speaking, how have you navigated the not having a blank check and educating business leaders maybe outside of your most senior leadership that gets it, but other folks who maybe don’t understand intuitively the importance of investing in developer experience. How have you navigated that?

Michelle Swartz: Yeah, I think it’s about trying to tell the right narrative. How do you tell the narrative that’s based on data? And in some cases sometimes having a proof of concept that demonstrates what the at-scale opportunity could be. It’s about understanding the technology strategy and then really thinking about the enabling role that you can play to help make that come to fruition. We really do try to ground the requests and the feedback from the engineering community also, which really helps to prioritize it. And I do think that we have a leadership team that understands the importance of investing in colleagues and the benefit that it has ultimately to our customers. And I think an example of that is the sentiment survey results and it has led to a lot of additional investment in some of the areas, tooling, for example.

Abi Noda: What would it be like if your most senior leaders didn’t get it, if they didn’t buy in and believe in this idea of empowering your software engineers? Would you imagine you would have been able to make progress without that top-down support or would you say that that has been pivotal and crucial to enabling the journey that you’ve been on?

Michelle Swartz: I would say that it would absolutely be more difficult. I think that I have enjoyed the ability to have support and sponsorship. In fact, in my previous role as a chief of staff to the CIO I had the opportunity to be in a lot of meetings and a lot of conversations around how important it was to create a really strong engineering culture. And again, this role was both the platform and the enablement role were created at the top of the house. I think that you can make small progress and I’ve heard on others speak on your podcast about being resilient and making small iterations and finding advocates within your organization. And I suppose I would do something similar, but I do think that my colleague and I have had the luxury of having a leadership team that recognizes care for our colleagues and care for our engineers is important for us to be able to continue to grow as an organization and when in the marketplace. So I can’t say I’ve experienced that and I’m thankful that I haven’t, to be quite honest.

Abi Noda: Increasingly when I meet with organizations, I tell them that above all else, getting that commitment and understanding and support from the very top is so pivotal to not just the early stages of the journey of doing small experiments and running surveys and collecting data, but even later in the journey when it comes time to really talk about investments that may need to be made, it’s so difficult to cross that bridge without having that top-down support. I love that your organization and the genesis of your journey began at the top. And that’s a good bridge into what is our next topic, which is I want to go through the genesis of your DevEx organization and journey from the very beginning. You’ve mentioned that this is three plus years in the making. You’ve had the privilege of working at Amex for a long time and being there from the beginning. So my understanding is that the DevEx organization really began with something that was referred to as the Jedi Council and Obstacle Removal team. Share with listeners how that came about, who sponsored that or initiated that and why?

Michelle Swartz: Yeah, so in 2015, organizations was hiring thousands of engineers with the intent on bringing in modern engineering skill sets. And so it began with this Jedi Council who basically had an audience with the CIO and the senior leadership team. And out of those sessions came what we call the obstacle removal team. And basically the CIO formed both the council and the obstacle removal team. It was made up of about 10 engineers, the council, and this was really in addition to their day job. So it wasn’t a special job that they had. And then the obstacle removal team had one engineering vice president and they had a few product managers. And so the issues were raised by the Jedi Council. To be fair, it was a lot of low hanging fruit. So the software you need to be able to write and deploy code. We were a PC shop, and so we brought in Macs for engineers.

And then what kind of special access rates did engineers need to have the freedom to be able to do what they needed to do, again, to build and deploy their code. The issues would be surfaced to this by the council in front of the CIO and the leadership team to this obstacle removal team. They would then bring the issues to the attention of the responsible teams, and they’d literally manage the issue as a project all the way through resolution. And they’d report every month to the CIO what progress was being made. So there was a lot of attention on it, but it really became clear that once the low-hanging fruit had been addressed, that there really needed to be more of a strategy and a group of full-time engineers that could focus on what was needed and ongoing process.

Abi Noda: When you say that it became clear that a more dedicated function here was necessary, what was it that you were seeing or hearing? What were the conversations? How did it become clear? Because I think that’s one of the places where organizations have difficulty is crossing that bridge from a working group, an informal working group of folks doing this part-time to hey, it’s clear there’s evidence here that a more formal dedicated investment is needed. So what did you see that compelled your organization to make that shift?

Michelle Swartz: Yeah, so the issues that again, were originally brought to the leadership team, they were no longer easily managed by a program. And in some cases it really did require larger investment and a longer-term strategy. And in addition, as the issues became more complicated, there were large dependencies on multiple teams and multiple backlogs that had to be aligned, which meant lots of coordination. And to be fair, we just weren’t going fast enough having these program people trying to do this and interject with other teams’ backlogs.

Abi Noda: And what was the process for getting the buy-in and formalizing that investment and formation of the dedicated team? What did you do to propose that make the ask? That’s again, a place where I think a lot of folks get a little tripped up or find obstacles in.

Michelle Swartz: Yeah, and so what I will tell you, which again, I know for many, it might be hard to believe, but we had a Jedi Council group come to a very senior leadership meeting. In fact, it was my first week in the role and they were asked to talk about what their experience was. I think it was rated from one to 10, what would you rate? And after they went through what their rating was of their experience in our organization, one of the members talked about the concept and it was a concept at the time of developer experience. And it was a very thoughtful dialogue about where they felt they were with this Jedi Council and the obstacle removal team, and that there was a larger concept and a concept that was made up of a strategy thinking about, again, the developer experience. And our CIO and the senior leadership team agreed. And then the search was on for who was going to be the right leader for the team.

And so I wish I could tell you there was a huge challenge and there was a lot, but I think it just goes to the testament that in 2015 there was a real focus by the team and a recognition that our organization wasn’t going to be able to evolve unless we really had amazing technical engineers in our organization. And once that decision was made, the leadership team recognized that change was going to happen and things were going to evolve. And they truly believed in the feedback that this council of amazing engineers was sharing, that it was the direction to move us forward. So I think the hardest thing was finding the right leader, to be honest. It took a long time for us to find the right leader that we thought would be able to lead us into the next chapter of developer experience.

Abi Noda: Are you able to share a little bit about why that process was challenging and how that process went?

Michelle Swartz: I wasn’t involved in the whole process. I think I was a part of some of the meetings where they were talking about the candidates, but I wasn’t involved in everything. And I think that they were really looking, because it was a relatively new concept, they were looking for people that had had experience. They were looking for the right fit in our organization from a cultural perspective, the right expertise. And ultimately we actually chose someone from within our organization, which was awesome too. And it was actually a member of the Jedi Council. So it was a great story that ended, I think, in a great way because this individual had the respect and understanding of our environment. And so I think it positioned them very well to be the first leader of the developer experience team.

Abi Noda: One of the things that struck me about your telling of this journey is that the concept of developer experience, it doesn’t seem like was introduced until the pretty late stages when you said someone on the council brought it up and articulated it. Is that true? And in your experience, being a part, being in that moment and a part of those conversations, what were your impressions of this idea of developer experience initially at that time?

Michelle Swartz: So I think to me, it was exciting. We knew that that obstacle removal team wasn’t going as fast as it needed to go. I think that the leadership team was looking for what’s the next thing? And the fact that the Jedi Council was able to talk to us about organizations that had developer experience teams and the research was shared with the organization, I think it was, okay, great. This is the path that we need to go. Let’s move forward with this developer experience team. Let’s form a strategy. Let’s think about this more holistically, and let’s have a dedicated group of engineers, not a group of people that are doing this part-time to really focus their effort on how to make this a better environment for our engineers.

Abi Noda: Okay. So the decision was made to form this dedicated team, which I understand was formed at the beginning of 2020. And at the get-go, you had already compiled a pretty large laundry list of things, engineers across the organization wanted to see improved. And from what you’ve shared with me before, your organization spent about eight months tackling as many of these issues as you could. Then came to the realization that not all issues are created equal. Take us through this journey and this learning.

Michelle Swartz: Yeah. So the team was really originally formed with about, we had two vice presidents. So again, we had platforms and enablement. We had about five staff engineers and we had seven engineers, so not a bad first start. And so originally we approached this by gathering feedback from our community via communication, internal communication channel. And we had a process to funnel out the input and work and what the appropriate team needed to go to. Was it our CICD team, was our security or cloud, they were our main partners and we had the engineering expertise so we could actually work through some of the problems and the potential solution with them and co-create with them. But the backlog really became large.

We were documenting any requests that came in from an engineer to improve the experience. And while we were closing out the issues, we just couldn’t keep up with the volume. And some engineers were waiting quite a long time for a resolution. And it was also really hard to understand what was the true impact. Is this a scrum issue, is it a platform issue? How many engineers are we actually solving for? And we didn’t want any engineer to feel like we didn’t care about them, but there was an opportunity to really think about what scaled and how we could help the most engineers.

Abi Noda: And so I understand at this point, you started looking into your sentiment survey, which you had run before, I understand, but you started looking into this as a tool, as a way to surface the most important areas to focus on. Can you share what your process was for this? You’ve shared with me before about how you analyzed and themed and aligned concepts from the survey to your business. It’s a really interesting process. I would love to unpack that.

Michelle Swartz: Sure. So as you said, the first sentiment survey was done in 2019, and we did look to leverage those results in 2020 when the team was officially started. To be fair, the process was in place when I took the team over, I actually took the team over in 2022. And so the team really wanted to do more than just report out answers to surveys. Anyone could look at that. They wanted to perform really a deeper analysis and understand the grouping of certain questions, looking at what we call storylines and then trying to identify any visible themes. And really it allows us to think about where our effort needs to be placed. So for example, a simple one is do junior engineers answer certain questions differently from our senior engineers? And we also wanted to make sure that our survey was aligned to our colleague value proposition.

We do have an annual company-wide colleague survey where we do make sure that we ensure that our questions complement, but they’re not the same. They’re really focused on what it’s like to be in technology. And we did want to make sure that it did however correlate to something meaningful and we felt that the colleague value proposition was the area to anchor on. And so the colleague value proposition has four pillars. The first one is we want colleagues to have a meaningful career, a unique journey. We want people to be able to bring their talents and skills and strengths to the team. And so we think about that in tech terms as do engineers understand why they do what they do? Do they understand the customer impact? And we think about engineering excellence. Can engineers have autonomy, purpose? And then the next pillar is about having a diverse and inclusive teams. People have empowered voices, making sure differences help shape the world and the commitment to our colleagues feeling seen and heard and like they really belong.

And when we think about that in tech, as with the rest of the company, this one’s psychological safety. We look at that whether you’re in tech or not, but do people support each other? Do we have employee networks? Are there external relationships that are positive? And then when the next pillar is how do you grow as a leader? Do we learn every day no matter what your role is, do you have the space and support that you need to learn to grow? And that’s thinking about tech. Do we have learning opportunities? Is there career paths or career development? Are people being recognized? What’s the experience when you join our tech organization? And then the last is about holistic wellbeing. We’re backed with programs that benefit and help support us. So again, is there work-life balance? Do we have caring, empowering leadership that work within technology?

And we map all about 50-ish questions in the survey to these four pillars. And then when we think about storylines, I do want to just call out one thing. This is run by engineers, so it’s run by a staff engineer and a small handful of the engineers that are on my team. We have added a couple of DX researchers, which we’re excited about, but we’re really looking for them to dig deeper into some storylines in more intimate focus group settings. What I want to, in part is these are engineers doing this. It’s not a special group of statisticians or it’s really group engineers that do this work every day. Last year we looked at productivity and satisfaction as our top level storylines, and then we came up with 10 supporting storylines. And these come from external trends, internal trends. Sometimes there’s a little intuition, not a lot, but every once in a while we’ll let intuition guide us and then thinking about what’s happening in some of our internal communication channels, and then what’s happening in our communities, like our guilds or communities of technical practice.

And then we also filter out our results by demographics. So this allows us to, again, look for regional market differences. Our engineers in the U.S saying something different than the UK or Asia-Pac. I talked a little bit about tenure, so did tenure influence a response to our storylines? And then we have a subset of questions around satisfaction. And those proved to be very useful in correlating across all our storylines. So we can use these questions to determine if a particular storyline is contributing to overall satisfaction. I have an example if you’d like to hear of a storyline.

Abi Noda: Absolutely. I think the storylines method is so interesting. It’s not only a way to focus and guide the way you analyze the data, but it’s also a way to communicate that data out to the organization in a way that’s compelling. So I would love to hear an example.

Michelle Swartz: Sure. So one example of a storyline is we have one around mobility, engagement, interest satisfaction, and there’s three questions that we’ve mapped to this. But again, basically we correlate these to every other storyline. So it’s a current project that the engineers’ working on engaging, given a lateral opportunity, would they change projects or teams? Are they satisfied with how much their tech skills have advanced due to their tenure at Amex? And last year, eight out of 10 of our engineers found their current project engaging. So we’re excited about that. Six out of 10 wouldn’t accept a lateral opportunity, so we’re happy with that, but obviously there’s more focus that we would look at. And this one we would, again, correlate to other storylines.

And then seven out of our 10 engineers are satisfied with how much their tech skills at advance. Again, we’re happy with that, but we want more focus, more work in that area as well. And then last year we also developed a developer network promoter score, and it’s a subset of six questions that we believe represent overall engineering satisfaction. A little bit different than the mobility question, but the questions around recommending Amex as a workplace to other tech professionals, how many hours do you spend creating and reviewing code? Is our ecosystem intuitive? Were you able to quickly find documentation? And then how structured or planned is your work? So we also look at this, and this is new, like I said, we just started that last year.

Abi Noda: And going back to what we were talking about a little bit earlier, which was one of the problems you were aiming to solve with this analysis was figuring out what are the real important problems versus a lot of the lesser problems that you were inundated with. What were the biggest things that surfaced to the top as a result of this work that you did?

Michelle Swartz: Yeah, I think two of the biggest things, and you have to also realize when we first started this, it was 2020. It was the beginning of the lovely pandemic. So there was a lot of things happening. And so, one of the biggest challenges that we had was people understanding the ecosystem to be able to write and deploy code. We actually hired quite a few new engineers and during the pandemic we did as well. And so we called that the path to production, understanding our internal ecosystem. And so that’s when we started focusing on creating an onboarding bootcamp for every new joiner. Both colleague and contractor consists of online learning and some curated experiences depending on your experience level. And then in addition, we started to explore the concept of the Paved Road, and then we also looked at knowledge management that came up where again, you’re not in the office, so people couldn’t just tap somebody on the shoulder and ask about something. So they needed to understand where they could go to find needed information to be successful. What were the documentation hubs that they could leverage?

Abi Noda: One of the things you mentioned surface was knowledge management was one of the big problems. I’m curious how your team thought about the scope of that problem, because when I talk to other organizations, this is a common theme that pops up, but it can be a tough one to figure out because there’s local problems of teams not having good knowledge around their code, and then there’s more global systemic problems around shared tools and systems. How did you actually think about how you were going to make progress towards solving this?

Michelle Swartz: Yeah, you’re right. The scope can really become quite large and untenable, and we didn’t do it by ourselves. Again, I think what’s important here is a lot of the work that we do and did was with the help of the community. And so we worked with a subset of engineers from across the organization and we created a framework that we call the Amex Way Library, and it consists of four quadrants. So we look at architecture and design, again, what we call the path to production, our culture, languages, patterns, tooling and frameworks. And then we looked to identify owners within the company that own the elements within these, what we call quadrants. And we started the journey of pulling in all the documentation from other places. We’re still on that journey by the way, but in some cases we had to curate new content for areas that we identified as gaps.

And I think we started communicating certainly to the people that were joining the company, new joiners. And also to our existing engineers that this was the place that they could go for information. And we also opened it up to the community for issues and contributions. Again, it’s been a really long journey and for me, it’s really rewarding now when we see someone ask a question in one of our communication channels and another engineer, not my team, but another engineer says, Hey, here’s the link to the library and here’s where the information is. But it was really talking to our community, getting some really brilliant engineers’ minds together and thinking about this, and then putting it to paper and putting it in a repo that our engineers could access and contribute to.

Abi Noda: Well, I love the thoughtful way in which Amex has approached this, and it sounds like you’re making good progress. I think your approach will be helpful to others, listeners of this show who are trying to tackle similar problems. This is also a great segue into the next topic that I wanted to get your insights on, which is Paved Roads. I know that one of the pillars of your strategy, your DevEx strategy that is, is to develop Paved Roads and common platforms and practices for engineers at Amex. This is such a common topic that comes up with leaders that I speak to, and I think you can provide a lot of advice on this topic based on your experience. My first question for you is what has been your process for finding the right balance between standardization and freedom? At a lot of organizations, I hear that there’s healthy tension and debate around this topic. I’m curious to learn how you at Amex, you all at Amex have navigated this.

Michelle Swartz: Yeah. And we have a lot of healthy discussion around it too. Again, some of the conversations around how many tools do you need to do the same thing? What makes sense to allow an engineer the freedom to use, they can use their IDE, what kind of IDE they want to use? When it comes to security and risk guardrails, that’s not an option. And when you think about it, every time you bring something new into the organization, there’s actually another choice that an engineer has to make. Like, well, which one do I use? And which one’s more important? And I think in addition, there is a cost to maintain as well.

I don’t think we’ve solved it. And again, we have a lot of debate, is this something that should be choice? Is this something that we should mandate? We try not to use the four-letter word must very often, and that’s what we actually call it, no four-letter words. But really our objective is to try to standardize the infrastructure and provide a toolset that engineers can easily use to write and deploy their code with. And I’ve heard other speakers on your show talk about the intent is that we make things so easy that you don’t want to go off-road, that you want to stay on the path. And I think the piece that we go back and forth of, is it a personal preference or is it really a gap in tooling that we have today that we need to solve for?

Abi Noda: That’s really interesting, the distinguishing of is it a preference or is there a real rationale or a real gap that exists, I think is a really important thing to call out. And as you’ve navigated these debates, how have you involved actual developers in this process? That’s another thing I see, sometimes can be almost an adversarial relationship that develops between the people trying to standardize and then the developers. I’m curious, how have you created an inclusive process to better navigate that?

Michelle Swartz: Yeah, so I think one of the things that we make sure happens in our organization is that every engineer, whether they’re doing something else, they all code. And so I think that that’s super important. So they do have some insight about the tooling. We never wanted this organization to be like people pushing things down. We wanted to make sure that there was a community of engineers. When we started, we leveraged our principal, our distinguished engineers. There were approximately 500 engineers that were involved in helping to establish the principles in certain aspects of the Paved Roads. And for example, our Golang Guild and our JVM Guild actually helped to create their respective Paved Roads and continue to help maintain. We wanted them to be able to make decisions. Now sometimes there’s a tiebreaker needed, but for the most part, we wanted them to have more input and influence into the tooling that they leveraged when they wrote and deployed code.

Abi Noda: And where have you landed in terms of allowing off-roading or allowing teams or developers to choose their own tools? What is the process or expectation around that?

Michelle Swartz: Yeah, so teams can off-road if they truly determine that there’s a current Paved Road or a tooling that doesn’t meet their needs. We have an exception process. I will say it has quite a bit of rigor to it, and it is off-roading, it’s bumpy. Certainly all of the security and risk guardrails have to be included as part of their solution. But again, what we don’t want to do is stifle something that’s important for future capabilities. And like I said, we try not to use the must word. So if there is a good business justification or something new that needs to be explored, we have a process and some rigor around it to make sure that it’s safe for the team to be able to leverage.

Abi Noda: And for all the talk about Paved Roads and organizations creating Paved Roads, I recently heard from a leader who asked, where do you begin when you begin establishing Paved Roads, where do you actually start? Does it begin with the developer onboarding process or is it about creation of new applications and services? So I’m curious at Amex, where did you all begin in terms of thinking about where that Paved Road actually starts?

Michelle Swartz: Yeah, so we began thinking about what are the routine tasks that the engineering teams had to do over and over again, thinking about how they spin up their environments, the common tooling based on their domain, and again, how could we create that path that allowed them to quickly spin their environments up and deploy with all the essential components, including the guardrails. When we think about where it starts, we said new applications. So asking engineers to use the Paved Roads for anything new. As they touch their older applications, we ask them to take a look at the components that could be retrofitted where it made sense. I think what’s important is the outcome. Will leveraging this new tooling or this process help you do your job better? And again, if it’s a security risk or guardrail, that’s not an option. And we do try to automate as much as possible to remove some of the burden from the teams.

And as far as understanding about the Paved Roads, everyone that joins the organization goes through the onboarding, and so they learn about the Paved Roads. And then we’ve worked really hard with the guilds again to talk about how the engineers can use the Paved Roads. Again, I don’t know that there’s a perfect science and we’ve gotten a few bruised knees along the way. In some cases we’ve rolled something out that we had to modify. But I think that’s what it’s all about, is not being so rigid that you can’t pivot or you can’t make changes based on what your community is asking you to do.

Abi Noda: When actually implementing or deciding upon what the Paved Roads looked like, was it mostly building on what folks were already doing or was there also an element or situations in which the Paved Road was entirely new, entirely stood up with new components and tools or ways that were disparate from the ways anyone was doing it today?

Michelle Swartz: So both. For some of the Paved Roads, we’ve leveraged some automation that was new and that was received very well. For others, one in particular, we probably swapped out four different tools, and that didn’t work very well for obvious reasons. Engineers felt that it was a really high bar. And so we talked about the need to meet engineers where they are and to think about this as a journey, and to focus on the things that were most important to them and not get hung up on not letting perfect get in the way of good. And I think in that instance, we actually have a couple of Paved Roads now. And so wherever the team is in their journey, they still have a way to go faster and be safer.

Again, it’s a learning experience, and I think it’s important that, again, you have the ability to be flexible and recognize that maybe you set the bar too high and that’s okay. You still can leave the bar there for those that can get there, but you need to come up with shorter ways for engineers to achieve what you want in order for them to be able to leverage the tools you have.

Abi Noda: One of the traps of standardization and Paved Roads, even in this conversation, for example, we’ve been talking about it for 15 minutes, but have perhaps lost sight of what is the actual problem we’re trying to solve with Paved Roads. And I think that’s something I see a lot of organizations lose sight of a little bit, which contributes to those healthy tensions and debates, I think. How do you at Amex think about what is the customer or developer or business problem that you are actually trying to solve with these Paved Roads?

Michelle Swartz: Yeah, I think a big piece of this is we talk to the engineers. Again, we talk to our team as well. As I said before, all of our engineers actively code. We call it drinking our own champagne. At least that’s what our CTO affectionately says. We do monitor the communication channels. We look for areas that maybe engineers appear to be having some friction, some of our support channels we take a look at. And then there are also other influences, again, such as security risk that come to play where again, we’re trying to integrate things into the pipeline so that our engineers don’t have to think a lot about it. And so I would say that’s one of the other things that we think about when we look at the paid pass or the things that we can remove the cognitive load from our engineers to have to think about, but rest assured that things are happening the way they’re supposed to.

Abi Noda: And can we give a few just concrete examples of the types of things we’re trying to eliminate? So for example, I imagine at Amex the certain types of compliance or security scanning needs to be run on code and there’s certain pre-merge and deploy checks, and I imagine you don’t want developers having to re-implement those types of guardrails. That being maybe one example. What are some other examples of the types of things you are trying to abstract away or eliminate from individual teams having to figure out?

Michelle Swartz: I think a big piece of it is looking at automation. And so again, are there ways that we can automate things so that engineers don’t have to do the same thing over and over again? Obviously the security guardrails, looking at static analysis, scanning, those types of things are all intertwined. And then also just making sure that we don’t have a hundred teams creating the same type of automation. Again, it doesn’t necessarily provide anything special for three teams to do the same type of automation when we could do it once for everyone and have them be able to benefit from that.

Abi Noda: One other question I have around Paved Roads, and then I want to conclude with asking this question more broadly about your developer experience organization is, how do you measure the success of Paved Roads over time? Or how do you align that to the things you’re measuring more broadly in terms of your technology or developer experience strategy?

Michelle Swartz: Yeah, I think that’s probably an area that we aren’t as mature and we are just starting to measure. Obviously how many engineers are using them, what kind of activity is happening in the Slack channels, what type of changes are being asked, which usually means people are using them and looking for more or additional things in them. But I would say that I think that that’s an area we’ve talked about, thinking about how can we actually measure the utilization in a meaningful way.

Abi Noda: And speaking to your developer experience, organization and strategy more broadly, I’ve heard you describe some of the intended outcomes of all this investment in really inspiring and aspirational ways. Can you share how you think about the end goal and the overall business outcomes, what you’re trying to create at Amex through all this effort?

Michelle Swartz: Yeah, so when we think about at least what we’re trying to establish for this year, again, it’s all about how do we reduce the developer cycle time? How do we accelerate their success? How do we streamline their development journey? Allow them to go faster and safer. And I think when we think about how we measure that, that’s, we’ve got some developer productivity metrics. We are venturing into, we’re actually looking at the space. How do we make sure that we’re really thinking about all the facets, including sentiment to measure that developer journey. I think we also are looking at how do we increase our developer platform efficiency, always looking to see how we can ensure that we’re leveraging new platforms, new tooling that can help our engineers go faster. And we’ve got some internal telemetry tools that we’re using to measure that. How do we increase the quality and the risk posture of our code? That’s something that we are always going to be focused on. And so how do we make sure that we continue to elevate our code quality?

And those are guardrails that are actually built into the pipeline, not something that we want to measure after the fact. And then the two that I am extremely fond of obviously is how do we grow our developer community? And so how do we create an environment where people have fun, they learn, they grow, they share knowledge, they solve problems, and then they innovate. And then how do we elevate our tech cred? How do we make the engineers feel great about where they work and how do we engage with our external tech community, whether it’s establishing relationships through open source, being a part of key events and really showing up in the community with contributions and publications so people can feel proud that, again, maybe we’re a financial company, but we have a strong tech culture. And it’s a great place to be here if you’re an engineer.

Abi Noda: Well, speaking as an outsider who’s gotten several glimpses into the investment in developer experience and the leadership you have at Amex around this area, I’d say that your tech credit is pretty good in my book. I’m glad that we were able to have you on the show to help share more of your journey with the world. And I’m excited to continue to follow your journey and really appreciate your time today, and I think listeners are going to find this really valuable. So thanks again, Michelle.

Michelle Swartz: Thanks Abi. It was great being here. Thank you.