Justin Reock:
Welcome to this week’s episode of the Engineering Enablement Podcast. I’m your host, Justin Reock, and this week I’m joined by Sejal Amin, CTO at Priceline, and Pedro Gutierrez, Senior Director of Engineering. And we’re going to talk about rolling out the product operating model and how that intersects with DevEx and the impact that that’s had on culture at Priceline. But before we get started, can you both take a moment to introduce yourselves? Talk a little bit about your background and your role at Priceline, and we can start with Sejal.
Sejal Amin:
Hi, Justin. Thanks for having us here today. I’m Sejal Amin. I consider myself a career CTO. I’ve been doing this for a lot of years, and in my current role, I am the chief technology officer at Priceline.
Justin Reock:
Wonderful. Thanks. And how about you, Pedro?
Pedro Gutierrez:
Hey, thanks, Justin, for having us here. I’m Senior Director of Software Engineering. I’ve been an engineer for a number of years and been leading a few teams for years after that. So happy to be here today, Justin.
Justin Reock:
Thank you both so much. Really looking forward to today’s discussion. So Pedro, can you tell me a little bit about what inspired you to look into some of these changes and moving to this product operating model?
Pedro Gutierrez:
Yeah, great question. What inspired me? Well, I went to a tech leadership. I don’t know if it’s inspiration, but it just kind of dawned on me. But while I was there, I was listening to all the lectures, the sessions that we’re having. And there was a common theme that I was picking up, that everyone’s kind of measuring some qualitative type of measurement of their other workflows, if it’s SDLC or something related to infrastructure. So I was thinking to myself, I was like, “This is something I might bring back to Priceline.” And then coming home and sitting in some of the meetings, we’re doing a lot of things to improve productivity. And we had a project to really enable a number of engineers, and I saw that it was just a small sample size. And my thought was like, “Oh, how do we bring this to a larger scale?” So that was the first inclination of like, “We should definitely do this.”
And then also, and we had other things to improve productivity as well. We have quantitative type of platforms at the time as well, so we had a number of different things running there. So I ran two surveys, drafted the questions, really kind of derived what I saw on the conference itself. Participation for the first two were, we got the early adopters, we got good kind of feedback, but one of the biggest questions like participation, are we really getting the pulse of the organization to make those kind of changes? Kind of laying those three things. So at that point, ran two surveys. The organization is trying to move forward on a number of different initiatives to really improve the productivity of the engineers. And we also have some metrics here that some teams are using as well. And around this time, this is around when Sejal joined the organization.ext
Sejal Amin:
So when I joined as CTO, I stepped into a place that had some incredible people in it and there was a lot of good things going on. But at the same time, there was a sentiment that things weren’t as fast as they could be, but nobody could really put a finger on why. It felt like things were slow, but no one could really explain it. So when I came in, my first priority was just to listen and learn. I spent a ton of time understanding the organizational model, the operating model, understanding how people work together, what the working relationships were like between product and tech to help me get a better understanding of how ideas move through the system. And in doing that, I was digging around, just asking for developer experience metrics. And many in the organization asked me to call Pedro because he had been going at this for a while. And like he said, there were two rounds of collection. And I think while there was data and there was good learning, there wasn’t really wide scale adoption yet, and that data wasn’t yet being used to make decisions.
Justin Reock:
So what kind of participation rates did you see on that first survey, and what were some of the takeaways that helped you kind of build the next iteration of that?
Pedro Gutierrez:
The participations were in the high teens for the first one. And then the second one, we broke around 20%. So it was growing. And then the foundational work was the questions that were drafted and getting kind of the feedback that they were vague, we couldn’t take too many action on them. One of the questions was around prototyping, and some of the engineers gave kind of feedback directionally, what type of feedback I could build on top of that. So as an organization, we can move forward and kind of alleviate that. So that was going into the transition when we brought in DX, curating the questions or the questions that are already drafted really kind of answered the issues that I was having as the author of some of these questions.
And the original content came from that conference, so I was really kind of borrowing from these other teams. But yes, it was great to sit with the team eventually with DX and kind of understanding the science behind it and how to kind of drive change with these questions that are going to be asked for the future surveys.
Justin Reock:
I want to understand, so you’re at this conference and you’re kind of looking around and seeing what other people are doing. What were some of the specific challenges that you were noticing at Priceline that you felt could be directly addressed by making some of these changes?
Pedro Gutierrez:
I think one of the biggest takeaways from the survey, from the initial one, which we could build upon, was I think the engineers really kind of voiced the lower environment experience. They want that to improve. They want to move faster. So we highlighted that multiple times over, and that was like, okay, this is something we could grab on. We’re hearing a voice of the engineer, right? I want to advocate for them, try to make their lives easier. Let’s see what else we could uncover.
Justin Reock:
Okay, that’s really interesting. So now I know that these types of changes, I mean, you’ve really made deep organizational and cultural changes and we know that that doesn’t really happen overnight. When you started working with DX, tell me about some of the differences between the questions that you came up with to gather that voice of the engineer post working with DX and how that was different than the way that you’d structured the survey originally.
Pedro Gutierrez:
I think it’s more of a cultural question. First, like I mentioned earlier, there was something that we grabbed on. We know that we could change the culture in improving the environment or the productivity for the engineers. So I think Sejal and I had a conversation like, “How are we going to approach this?” I was very excited to, let’s roll this out to everyone immediately, but just because of participation from the survey that we’re learning, she recommended a phase approach, and not a pilot, a phase approach. The messaging was critical. So that was the first thing is like, let’s target some teams, right? Let’s learn in this first phase. So we took teams with large surface area, right? They have a lot of complexity, a lot of dependencies, larger teams. And then we also selected teams that are prone to jump on or to adopt to new technologies, and they could be champions for DX as well.
And simultaneously, we’re trying to craft the message and directing it to the developers. And I think talking to the DX team, DXI is the happiness score. And I started to kind of analyze, what does that really mean? There’s two types of outcomes at the end of the day that you really get. You’re either excited, like I did great work, I feel satisfied, I progressed on my initiatives, my projects, or there’s the opposite, right? You have tons of hurdles, obstacles, and that brings you down. It brings your mood down. So basically what we want to drive is we want to have those productive days more often than not. And that was kind of the messages to the engineers.
We’re trying to uncover that. So in circling back to your original questions, that’s what these questions are headed around, right? And that’s the part that it was missing. These are drivers, these are workflows that really showcases that this is what engineers need to feel productive at the end of the day.
Justin Reock:
Okay. I can really start to see this now crystallizing where it’s like almost the questions themselves and just thinking through this new process, all of a sudden you’re seeing these pain points kind of in a higher resolution, and then you’re realizing that there’s stuff that you can do about that to improve that. So Sejael, you mentioned that this really resonated with you when Pedro brought this to you, that you could look around and you could see some of this slowness. Tell me what it was like when you started to see some of these signals come in. Did you really start connecting the dots? And what was the driver to provide that kind of top down support that you clearly were able to give to Pedro?
Sejal Amin:
When I started, the sentiment was slowness, and I spent a lot of time at the beginning just listening and learning from the organization. And during that learning, a few things emerged that weren’t necessarily just about DevEx. I was learning about the organizational structure and how things worked. And in that learning, the biggest thing was is that the organization was structured primarily around functional excellence. And what I mean by that is front end, backend, QA, infrastructure. And while that created deep expertise on the teams, it meant that delivery required multiple handoff between teams.
And so as work moved from one function to another, natural cues and dependencies formed. I like to use the conveyor belt analogy. Work was being dropped off and sometimes it wasn’t always being picked up off the conveyor belt. Right? It was falling off because of the queuing that was going on and because of the waiting that was going on.
But in parallel to that, the more important thing I learned is that there wasn’t a shared explicit understanding of what the end-to-end developer experience was, what impact it had on people, and how that really influenced culture, speed, and all of the things that are important in a product development environment. So when I put the organizational challenges together along with, “Hey, we need to understand our DevEx.” It created an opportunity for us to align around a product operating model and start really thinking about DevEx as the core of that.
So that’s the journey that we started. So there was a ton of top down support at that point because we changed the narrative and people started to pick this up and I’m sure we’re going to talk more about that as we go, but that’s a little bit of the context and the background.
Justin Reock:
I think that that’s a perfect time maybe for the benefit of the audience for us to make sure that we’re really clear on our definition of what we mean by the product operating model. I really do want to hear more about how, at Priceline, that really dovetails with DevEx, because I think when you think about a more generic product operating model, that’s not always the consideration.
So Pedro, maybe could you tell me a little bit about how this product operating model is structured within Priceline? How does it differ based on what you were doing before?
Pedro Gutierrez:
How we worked previously is mostly project based. The work is coming kind of top down directionally with a product operating model. One of the biggest thing prior is, there’s a lot of dependencies before. We will sit down across the organization, try to measure capacity across the board. So that created a challenge.
One of the big principles of the product operating model is autonomy, trying to identify. So we staffed our teams accordingly. We applied the type of engineers that will be needed for that team to be successful, so to encapsulate as much of the work as possible.
We’re two quarters in, and I kind of report that that is taken away. There’s a lot more ownership that’s taking on right now. The teams are kind of driving, and it kind of correlates with DX itself because productivity is the outcome here that we’re looking for. So the teams are more empowered to do what they want, and they also can start measuring and understanding these are little obstacles that were happening that are not happening anymore. So it’s a good story that we’re in the midst of telling right now.
Justin Reock:
So I can see then how organizationally the way that you actually distribute work throughout the environment has changed fundamentally by moving to this model. But I want to understand the signals that you got when you began to work with DX and you started to see these issues with the developer experience. How did those signals lead you to understanding that the product operating model would be a good solution for some of these challenges?
Pedro Gutierrez:
Yeah, I think we have some good stories. I want to just rewind the tape a little bit here, like just explaining our phase approach and kind of the outcomes that we’ve done. So going from phase one, we had these teams and then once we got into phase two, we made it a broader audience, that gave us one cycle of DX. Before that, we sat with our managers. We tried to give them the layout of like, “These are the actions that we want”
For those managers in phase one, we asked them to actually, once they took the survey, they did the triage process. The triage process is when you take the results and you start writing action items against it. So for that phase one, we have the managers actually write down collectively. So as an organization, we get a better understanding what’s happening in these conversations.
So they wrote down things, action items for that quarter for address. Okay. We’re going to move forward to the end of the quarter, another survey’s taken and some good stories of work came about. I’ll try to align these to the product operating model before. So simply some teams, there’s some low-hanging fruit, like focus time. Let’s reorganize when we have our meetings so the engineers could really have those big blocks of time to really focus. That’s great. That’s fantastic.
Some other teams, we noticed that they lost some toolings. There was a migration project right there and we saw the scores go down. So that was kind of enlightening right there that, okay, they lost something, it had impacted them if the manager in that team knows exactly what they need to do to try to remedy that forward.
Then we have another story where it empowered engineer. We had two sibling teams working kind of hand in hand and this team was highly dependent on the other one for like PR reviews, documentations back and forth, and it was impacting one of the teams more than the other one.
So the survey, the DX, the content empowered that engineering manager to speak to its peers like, “Hey, our cross team collaboration, our dependency on this team has impacted my team negatively over time.” So they gave them the content, the fuel to have those conversations with tough conversations, and these things start to remedy on their own.
So going back to the product operating model, like I mentioned before, the main point of the product is really autonomy, right? DX offers that gives you the viewpoint within your team of what’s actually occurring if it’s speed? Innovation is one of the critical things, right? I think that drives a little bit more of the DXI score improving, because if an engineer is working on work that’s really challenging, technical debt day in and day out, it’s going to impact it negatively.
So highlighting those things for the engineering managers to take action is basically kind of one of the cornerstones of the product operating model that we want to kind of drive. You have your outcomes that you want to drive towards, you have total control to do that, and you have total control to foster the right culture within your team to drive those results.
Justin Reock:
So you’ve mentioned autonomy a couple of times as being really central to the product operating model. Can you explain to our audience a little bit how those signals from DX can become kind of that north star for alignment amongst teams while you’re also trying to increase their autonomy?
Pedro Gutierrez:
The autonomy, I think a good story here with the autonomy, just I came out of one of the triage sessions and my team is highly dependent on other teams as well, and they voice that as much as possible. So when we find an opportunity to provide ownership, like if it’s spinning off a new application that has specific ownership that they could drive, they could release, they can manage, I think that’s a good example of, “Hey, we got feedback from DX. Okay, we’re not being as fast as possible. Our PR throughput is not going because there’s a number of different steps.” It’s an external team kind of driving it. We want to bring it in house so we can manage ourselves and we can manage the speed that we’re moving.
Justin Reock:
So you’re able to then, as long as you agree on these metrics as what you want to improve, and as the right signals to be looking at, then you can give those frontline managers and your engineering managers the opportunity to decide kind of what to improve in a way that’s more autonomous and less top down?
Pedro Gutierrez:
Yeah, yeah, absolutely. They have the control to make those decisions. They have ownership of the tech stock, they could spin applications within their scope and they could move as fast as they want or as low if they want to control the change failure rate. Right? It’s a balancing act, but each team has that autonomy to drive that as they see fit.
Justin Reock:
Obviously, this wasn’t just like flipping a switch and all of a sudden every team is operating in this way. Sejal, maybe could you tell us a little bit about how, what was the process for prioritizing the order of which you rolled this kind of cultural change out to individual teams?
Sejal Amin:
Yeah, that’s a great question. Our journey to kind of realign ourselves around the product operating model, for any company, it’s a long one because so much thought has to be put and so much intention has to be put into the redesign. So we knew that the redesign was going to take time and all of the work that Pedro talked about, essentially, learning about developer experience and the experiences on the ground, we really just wanted to start doing that immediately rather than waiting for a full structural transformation because I knew at the time that was going to take up to a year.
And so rather than delaying our learning, we thought let’s just get the tool out there. Let’s get it rolled out to people so that we could get people used to it. People start making changes in their context, the types of changes that Pedro just did such a good job of describing.
And like I said, it started our learning journey and that was really, really important. And so we immediately, right, we got DX360 on, we got people onboarded, we got it running. Now that wasn’t without its challenges, because we had failed attempts before. It’s not as though they had tried it and it worked the first time.
There was friction at the beginning for lots of different reasons. I think engineers, just generally speaking, there’s something in the back of their head saying, “Oh, this thing is going to judge me, people or my manager is going to judge me because of what the data’s telling us.”
And so we really had to get in front of that narrative and be very explicit that it wasn’t being used for judgment. It wasn’t being used for individual performance. And to the point that Pedro was making, it was being used to improve the working environment, improve your shared experience, just make your life better.
And so managers, we had to make that point over and over again. We really had to drive that home. And so as we drove it home, we saw more and more adoption. And I think we’re super proud to say we have everybody participating at this point in the quarterly surveys, and our story continues.
Justin Reock:
So you’ve moved from that place of those original couple of surveys being, in that you mentioned in the teens and then in the low 20s, and all of a sudden you’ve got 100% participation.
Sejal Amin:
We do. We do.
Justin Reock:
Can you tell me a little bit about, how do you go from a position of really evangelizing this to your frontline managers to then there being able to really gain the trust of your engineers so that they can provide these strong signals? What do you think that moment was where you were able to establish that trust within these teams?
Sejal Amin:
So I think a lot of this is about repetition, a lot of repetition. You’ve heard the euphemism, that you have to say something seven times before people remember it, right? And so we had to do the same thing over and over again.
But one of the key things is talking about what we were using the tools for, and in a way staying true to that. And the way that I like to think about it and the way I like to talk about it to engineers and engineering managers and leaders is, we are helping you improve your performance.
I think all too often, the words productivity and performance, they become conflated and they’re used interchangeably. And when I think about the word productivity, it sometimes feels like you’re judging people or you’re measuring people for the number of things they’ve done or the output they’re creating.
But when you start to use different language, that we’re using this information and we’re giving it to you to autonomously manage, and it becomes your job to speed up your performance as a team and optimize your performance as a team, I think that the game changes because the reality is engineering and product development is a team sport. And when you err on the side of performance, I think it changes mindsets because just performance is a long-lived, long term, it’s a long term definition.
And then teams that stay together, they build performance over long periods of time and this tool and the environment helps you optimize for that. And so when people started to really grasp that, I think that’s when things changed.
Justin Reock:
Pedro, with this in place, getting these strong signals, starting to build these virtuous cycles for engineers, where they can feel the material impacts and improvements, tell me a little bit about the difference just in the general psychological safety of the culture now, as opposed to before putting these changes in place.
Pedro Gutierrez:
Yeah. I’ll attribute to what Sejal was mentioning, like the messaging, driving the message over and over again. One of the biggest things that we mentioned is like, this is the feedback loop, right? We kind of highlight it, we put it on a slide. We’re making changes to the system.
The system is the workflows that all the engineers are working through. So either two things are going to happen. You’re going to make micro changes within your team, or we’re going to escalate the changes up the chain to ensure that. Getting that is really kind of the changing of the culture. The other messages that Sejal was hitting on was like, this is team-based. She mentioned it’s a team sport, and that’s what we kind of drove as well.
So those two things are kind of changing the culture.
We want you collectively together, address, highlight what’s critical to make the team more productive. And then second of all, if there’s something higher that cannot sit within your team to really highlight it to your manager, or the manager’s surface up and to bring it to the tech leadership team so we can make changes.
And again, repeat this over and over again. Every quarter this is going to happen. So that builds trust with the engineers so far because the feedback’s there. They feel comfortable saying, “Hey, this is what I need to be successful.”
If an engineering manager can’t solve it, they should look for their manager to help out. So that was happening in the case, but this has accelerated that process.
Justin Reock:
And would you say that that’s led to an expansion then of the role of an engineering manager in terms of now having developer experience be top of mind as part of this role?
Pedro Gutierrez:
It’s naturally happening. I see messages on Slack, engineers like, “Hey, listen…” They’re highlighting things that happen within their sessions, their triage sessions, and like, “Let’s address this kind of moving forward.” So organically, this is fantastic that just engineering managers are taking this up and really want to make a change because at the end of the day, I think we started how an engineer feels once they leave work, that sense of satisfaction, we want that to happen more often than not.
Sejal Amin:
So I’ll jump in and add there that I think while it may not necessarily be an expansion of role, in a way, the engineering managers in the product operating model, the role is different when you move from a functionally aligned organization to one that is product aligned, because of the fact that that engineering manager is essentially responsible for a product and the services that support that product.
And as part of that, they’re responsible for the health of their team. And this is one of the many things that they learned to take on in this new operating model. And one of the big things that we did is, every manager actually took a goal for the quarter of moving their DXI metric.
The goal was to move it any way you will, because you’ve learned how to use the data, you understand what you’re looking at, and you’re making it part of your day-to-day.
We love to talk about our DevX metrics in public all the time. It comes up in all hands. We share the data quite openly in a lot of forums and throughout the quarter we’re showing those numbers and we’re showing how those numbers are moving. And so it’s more and more, it’s just become part of the DNA.
Justin Reock:
No, it’s becoming very clear to me now, you’re able to gather these signals first, you see that there are some challenges. You align on the product operating model as a way to address those challenges, and now we’re using the signals coming out of DX to really understand how these changes are impacting developer experience and ultimately impacting developer productivity.
So I think I really do understand now how these two things sort of dovetail. And it’s making me realize that our audience is probably listening to this, and they’re thinking about, this may be something that could address challenges in my organization.
What resources, and this is a question for really either of you, but what resources were you able to lean on to learn more about the product operating model and understand how to really roll it out within an organization? Where could our audience go to learn more about that if they wanted to start rolling this out themselves?
Sejal Amin:
Sure. I mean, first and foremost, there’s just so much content out there, a ton of it. Marty Cagan’s written a wonderful book about the product operating model, but as an extension of that, there’s so many other concepts, like Team Topologies, The Flow Framework, right? I mean, those are two other things as an extension of the product operating model, those practices are very much applied. And so by way of reading, like I said, Marty Cagan’s written that book, The Flow Framework by Mik Kersten, the Team Topologies, the Team Topologies framework, all of those are really, really helpful.
Now, one of the things that we also did here is we brought on coaching as well. So knowing that we were going through such a major change and the organization hadn’t seen the change before, we had to take some learning on, right?
And so part of what we did there was get a better understanding of what kinds of things we needed to teach and trying to remember off the top of my head, we did a bunch of engineering leadership classes, we did a number of architecture classes, we’ve done a bunch of content around how to run platforms and how those teams should work, so the service and consumer model. But the other big thing that we provided throughout the quarter was just a coach that was available to the teams, which teams could pull on.
It was a pull model rather than pushing coaching down. And so if they needed help, we had different ways for teams to engage with an external coach and get support where they needed it.
And so a lot of if they’re reading the data and they’re trying to understand where their bottlenecks are, but they needed someone to bounce ideas off of to help improve performance. That was an ongoing thing. We’ve done that for two quarters and we’re going to be wrapping that up pretty soon.
Justin Reock:
Interesting. So you’re really drawing resources from a number of different areas. And we’ll link those books in the episode description so that the audience can have a chance to check those out.
Pedro, how much larger is this effort now after going through these learnings and going through these iterations? I want the audience to maybe gain a little bit of perspective about your own learning here. You go to the conference, you’re introduced to this model, it looks like something that could be interesting. Now fast-forward to having implemented this.
How much more was there to learn between what you were able to pick up at that conference and what you’ve been able to put into practice today?
Pedro Gutierrez:
The amount that I learned kind of during this rollout phases, it was a lot.
It’s interesting because really don’t look under the hood necessarily in the past, right? You’re kind of just moving forward, projects, seeing, “Hey, what comes up at the surface, but what’s actually happening underneath?”
That content that your team has provided and those details with understanding what are these 14 to 16 drivers, where are the workflow, what’s the perception of the engineers, why that’s valuable, there’s a lot of content and there’s still a lot to learn as we are still charting or navigating, and so look forward to learning a lot more.
But now with the team, moving forward, now that it’s like a broad thing that we need to adjust, Sejal and the product operating model spun off a new team, just a DX team within that are going to address this kind of moving forward.
And this is just one arm of it, right? Now that I’m sitting outside and being a recipient of the DX platform team that we have, they’re addressing things that we want like the testing framework, how can we improve that? They’re sitting with my team, with the engineers, and kind of trying to solve these problems little by little for them to alleviate some of this pressure or make streamline a number of different processes for them.
So kind of moving forward, there’s a lot to learn. but yeah, it’s already kind of paying off having these resources, and there’s a lot that we learned on this journey as well.
Justin Reock:
I think that’s great. Yeah. Sejal, if you could maybe talk a little bit about how are you continuing this process now that it’s been incepted? What does it look like to be able to build a structure for continuity for these changes within Priceline?
Sejal Amin:
Yep. And so when we first started, Pedro was an engineering leader, and so he was the one kind of supporting the rollout, because in the previous operating model, he was the person that did it, but he had a day job.
And as we thought about scaling our organization and we set up the product operating model, one of the first things we did was to set up a developer experience team that he just mentioned.
And that team has taken on the ownership of the tool, but they have ownership of so many other things in addition to that. Their job is to provide tools to the organization based on the signals that they’re getting, based on the asks we have, based on what the data’s telling us.
And so they are tools, they are frameworks, they’re essentially an enablement organization. And that’s how we’re now keeping the momentum on all things developer experience, and that’s been a really good force multiplier for the organization.
Justin Reock:
I’m looking forward to hearing how this just kind of continues to progress. We’ll need to do a follow-up at some point.
I would like to understand how these kind of sweeping changes that we’ve all been going through in the industry around the use and integration of AI, how has that impacted this effort?
Sejal Amin:
In a great way. So I especially love that we have the tools in place, we have the metrics in place, and that we understand what our PR throughput is. And now that AI has come along, we are using that as a proxy to help us understand how AI tools are impacting teams.
And obviously there’s many things that impact PR throughput, all the little tweaks and changes that teams make, but at the end of the day, right now there isn’t really a way for us to separate the impact of AI tools from everything else. We just know that teams are working at speed, they’re improving flow wherever they can, and AI tools are part of that story.
Now, obviously that part of the story is going to get louder and louder as all of this takes speed. It was smaller last year and this year it’s picking up steam. But I think having the product operating model with the align teams in place, having the tools in place, having the metrics in place just helps us understand the impact on the big picture, from my point of view.
Justin Reock:
So we hear a lot from a lot of teams who are like, “We’re just shifting the bottleneck, we didn’t necessarily have a culture that was ready for all of this new influx for increasing our PR throughput.”
But would you say that these organizational changes and moving to the product operating model, it sounds like that this has actually been really good in terms of helping to deal with some of those inherent problems that some teams face when they all of a sudden just turn up the gas on pushing through way more PRs and that sort of thing?
Sejal Amin:
Absolutely. So look, I think the product operating model, rolling that out, getting it in place and getting the team structures and the tools in place, it happened at just the right time for us, so I’m really grateful for that. I couldn’t have predicted what’s happening now in the world, right? But hey, two quarters ago when we rolled this out, the timing was ideal.
Now, everything isn’t perfect here, right? Everybody’s talking about the fact that, “Hey, AI tools, great, we’re producing more code and so the bottleneck has shifted left or it has shifted right.”
Having these frameworks and tools helps us understand how the bottleneck is moving. It gives us visibility into that so that we can take the appropriate actions to keep the bottleneck moving left and right. I mean, you fix one problem and the problem just moves somewhere else, right? We’re just accelerating our learning at the moment.
Justin Reock:
Well, and we like to talk about AI as an accelerant of both good and bad, but it sounds like because you’ve made these good changes that the AI is really working out.
And I think that that could be a key takeaway here for our audience, that if you’re kind of feeling this crunch and you’re feeling bottleneck shifting as opposed to actually improving flow, that elements of the product operating model can help you with some of these issues.
Great. So as we close out here, I would like to hear just from each of you, maybe just a final question. You’ve been through this big change, things, obviously you iterate on things and they look a little bit different at the end than you might’ve envisioned at the beginning, but maybe, and we’ll start with Pedro, can you give us just one thing that you wish you’d known coming into these changes so that if our audience, if they decide to implement some of these things, that they don’t have to go through that same challenge?
Pedro Gutierrez:
I will just say focus on the messaging, right? You want to get buy-in and try to get that cultural shift as soon as possible. Tweak the messaging, try to drive it that it’s team-focused. I think that was one of the biggest takeaways from what we had before and then from when we moved to DX. Yeah, it’s a team sport, and drive that idea all the way to the top.
Justin Reock:
No, I love that. Thanks, Pedro. How about you, Sejal?
Sejal Amin:
So look, for any teams going through this type of transformation, whether it’s product operating model or whether it’s the adoption of AI into the product development workflow, I think the biggest thing that leaders can do is to make sure, engineering leaders, is to get your product leaders and your product partners and from the top down engaged in the conversation with you.
Showing them the tools, showing them what’s impacting the teams, showing them how to look at the data and making them part of the journey with you is just so important from the outset because all of the decisions for the teams are made locally.
And at the end of the day, any investments you need in the workflow, any investments you need in tools you have to prioritize. And that prioritization, look, it happens as a partnership because it’s a joint ownership story.
I think all too often developer experience metrics are seen as an engineering story, but I like to say it’s a product development story because product development’s a team sport.
And when you think about, you mentioned a few moments ago about AI and how the application of coding tools is moving bottlenecks left and right, it’s really about the entire workflow, right? And it’s about the entire product development workflow. And I think we’re going to find in the coming months that conversation is going to get louder and louder. What are we doing to optimize the entire experience from end to end?
Justin Reock:
I think that that is a wonderful note to end on. Pedro, Sejal, thank you so much for the conversation today. I’ve really learned a lot now about this relationship between product operating model and the nice effects it can have on DevEx, so thank you both so much for sharing your stories.
Pedro Gutierrez:
Thank you for having us, Justin.
Sejal Amin:
Thank you.