Justin Reock:
All right. That was awesome. We just heard from three companies. Obviously, three very different contexts, and yet somehow all the same core challenges underneath it. So hopefully, that’s something that’s relatable to everybody in the audience. That’s what I love about a good conversation like that. So we’ve been talking about what the AI native organization looks like, and our next speaker is going to really push that question even further. So Jen St. Pierre is Vice President of Software Engineering at Dell. She’s been doing the hard and maybe even unglamorous work of evolving a large scale engineering team from the inside. Please give Jen a warm welcome.
Jennifer St. Pierre:
We were debating doing a fancy handshake on the stage here, but we opted just for the very casual. So good morning, everyone. I want to start with a quick thought experiment for everyone in the room. I want you to imagine it’s three years ago, and you walk into your CEO, your CIO, or your head of engineering’s office, and you tell them in the near future how we build software is going to transform.
Our work is no longer going to be measured by what a team of developers can deliver, but they’re going to shift to where our developers become orchestrators of agents, and our agentic systems will generate production-ready code, refactor entire repositories, write our test suites, and explain legacy systems better than our best developers can today.
Now, I don’t know about all of you in the room, but three years ago, I would have been laughed out of the office and my credibility would be in question, and yet here we are today having this exact conversation in this room. And apologies, I lost my voice last night, so if I come in and out, it’s because of that.
Agentic-driven development is no longer theoretical, right? You heard it from everyone up on the stage here today. The transformation is happening now, and it’s happening in all verticals and in all industries. And it’s bigger than just a tool, right? It’s not just the technology and it’s moving beyond experimental.
The innovation and advancements that are happening right now in AI are changing how our software is being developed today and how our work is going to flow, and it’s going to be in more continuous loops versus discrete handoffs in terms of how we work today.
AI and agents are going to change how we think about value and how it’s created, how our workflows are going to change, and most importantly to the conversation I think all of us are having is how our engineers are going to define themselves. And I bet most of you are already having these debates exactly in your organizations today.
And those conversations, I’m going to go on a limb here and say those conversations for all of you are going to be both exciting about the opportunity in which the technology unlocks from an innovation standpoint, but also paired with the apprehension of how do we get there and when we get there, what will that mean for our organization? And this is a strategic change in every organization and every organization in this room is going to have to define what that looks like for your organization.
Now, I’m going to make the case to all of you that this is not the first time that we’ve been here, that we have as organizations in software development, we have gone through tremendous amount of change and that organizations who get through this are the ones that don’t just look for the best tools. They’re the ones who understand that technology transitions are really people transitions. But knowing this pattern doesn’t make living through it for us today any easier, right? Especially with the narratives, filling your organizations right now and pulling their teams in opposite directions.
Think about the developer who learned how to program on punch cards, right? They submitted their jobs, you waited, sometimes you waited overnight, and then one day terminals arrived, interactive, immediate, and suddenly you had to think in real time. Some of our developers at that time didn’t make that shift. The ones that did never looked back.
Then compute stopped being scarce for our teams. They had a machine on everybody’s desk and suddenly the developer’s relationship to the machine became intimate in a way that it had never been before. Entire new categories of software emerged and with them, entire new definitions of what a developer was. Then the internet arrived and changed the unit of delivery overnight, right? You weren’t shipping a box anymore, you were running a service. The job didn’t shrink. It expanded into operations, uptime and deployment, and more responsibility and more complexity came with that in addition to more value.
Then DevOps said, “You build it, you run it.” That wasn’t a technical shift, that was a Cultural Revolution of how we thought about software development, and the architecture of software started mirroring the architecture of our teams. So every single time, the technology moved faster than the people. And so we’ve been here before. I would argue though that the details are the same, the patterns tend to follow the same thing, and that in every major shift that we’ve had, engineering has generally followed kind of this pattern.
We have a lot of excitement. Then we move to high amounts of skepticism. Then the organization goes to fear of what does this mean, and then we jump to productivity. And then we pretend that we have always done it this way, and we question how we ever did it this way before. Agile changed how we thought about process. DevOps changed how we thought about collaboration in our teams and cloud changed the infrastructure ownership. And now here we are again, and AI is going to change how our unit of work is completed. Now, for decades-
Jennifer St. Pierre:
… work is completed. Now, for decades, the core atomic activity of software development has been writing code and is thought of as one of the most cognitive heavy jobs in the industry. The activity of coding has also been largely insulated from levels of change. Sure, we might have transitioned from waterfall to agile, which changed how the unit of work was defined, but software development has largely been thought of as a protected skill, and developers have been viewed as the individuals with captive knowledge in our organization. And this protection is starting to dissolve, not because our developers are becoming less valuable, but because the barriers that have made their knowledge captive is being removed. And the question all of us have to answer is what fills that space.
So machines can generate large portions of code instantly, learn how a system operates, and make suggestions on way we can improve what we’ve built. That is going to create tension in your organization today. I am sure you have developers in your team today asking, “Am I being replaced?” And I think those of us as leaders are asking ourselves, “Are we moving too fast or are we moving too slow as we go through this transition?” When both sides experience uncertainty, something very predictable happens in all of our organizations. Narratives fill the vacuum, and those narratives tend to be paralyzing for an organization. You have one extreme that’s going to say, “AI is going to replace developers.” You’re going to have another extreme that says, “This is just hype. Nothing fundamentally is going to change.” Both extremes are going to be emotionally convenient and frankly, both are going to show up in your organization. Sometimes you’re going to even see them show up in the same meeting that you’re sitting in.
And they simplify the complexity, but neither is accurate. AI does not eliminate developers. It changes what they spend their time on, what fills their day, how they add value, and where their judgment is going to get applied. It elevates the level at which they have to operate. But elevation can feel very destabilizing before it feels empowering to our engineers. And that destabilization phase is where change management lives. If we ignore it, we get resistance. And if we address it, we get transformation.
Now, if all of us in this room treat AI as a tooling rollout, you heard it on the stage earlier, you’ll get compliance. You can check a box, you can look at usage, you can do all of that. If you treat this as a human transformation, you will get commitment, and those outcomes are not the same within your organization.
So what does it take to get commitment? What does that look like rather than compliance? So I’m going to take you through today. I’ve seen a lot of organizations navigate this, some that have done it really, really well, and I’ve seen some that have failed badly. And the ones that fail treat it as an IT rollout, and the ones that succeed treat it as a leadership challenge for all of us in this room. And the difference comes down to five things that I’m going to talk to you about today. Not theories, they’re kind of operational necessities that I think all of you need to be thinking about within your organization for how you go drive this transformation.
It starts with developing a shared understanding of why shifting to agentic driven development is good for me. It starts with the individual. If developers don’t understand why AI adoption is happening, they will assume it’s about cost reduction in your organization. And if leaders don’t understand developer concerns, they may view that resistance as complacency of their teams. Both interpretations of that are extremely dangerous to your organization. Shared understanding means that we create transparency about why this is happening, about the competitive pressures that exist, the market acceleration that this opens up, and the strategic intent behind what we’re doing. It’s not the sanitized version. It has to be the real version for your team.
I’m going to give you an example. Imagine two companies adopting coding tools today. Company A says to their teams, “We’re rolling this out because it increases productivity.” And company B says, “We’re adopting AI because our market is accelerating. We need to deliver more experimentation, faster iteration, and higher quality solutions. AI is going to give us the ability to elevate engineers into more strategic problem solving roles.” Same tool, different framing, and I don’t know about you, but I’d much rather be in company B than company A in that rollout. It’s going to give you a completely different emotional response from your organization in the way in which you articulate what you are doing.
In every transformation I’ve seen stall, the why was either missing or it was dishonest for the team. People in your organization can handle the hard truth of what this means. What they don’t want to be is managed through their adoption of a tool.
Shared understanding also doesn’t mean that everyone is going to agree. It’s going to mean that everyone is working from the same honest position of reality. Now, part of your shared understanding is having a clear vision of what does the future state look like that we are trying to achieve. People don’t resist the change itself, what they resist is the uncertainty of what that change means, that they can’t see the picture of where you’re going, they’re going to resist. And in AI transformation, uncertainty is everywhere right now. So leaders who stay vague, thinking that they are protecting their teams, are actually doing the opposite.
In the future, our development roles is undefined. People are going to imagine replacement if they don’t understand what their role looks like in the future. If our career paths are blurry, people are going to imagine stagnation in where they are in their careers. And if the skill roadmap is vague, people are going to imagine obsolescence in what they do.
So in defining your future state, you have to be explicit about these things. A clear future state answers three things for your team. Sorry. Three things for your team, and these are the things your team are actually asking themselves today and looking for answers on. It’s, what will my work look like? What will be rewarded in the future? And what or who is going to go away? And that last one is going to be uncomfortable. But if you don’t answer that question for them, they are going to answer that question for themselves. And their version is usually going to be far worse than what the truth actually is.
So when people can see themselves succeeding in the new world that you envision, engagement rises dramatically, change becomes aspirational instead of threatening. And so I want to start with how do you think about this in your organization? And I’m going to give you guys a non-technical example, right? I’m heading on vacation next week with my family, and I want you to imagine that I tell my family, “We’re going on vacation and it’s going to be somewhere warm.” Now, all of their ears are going to perk up. It’s been a very long New England winter. And then I tell them, “There may or may not be running water. We haven’t decided how we’re getting there. Pack everything.” So suddenly my family is a little less excited to be going on this vacation with me.
Clarity matters in how you articulate these things, right? This is not new to their teams. And I’m sure all of you have been here before. And for some of us, it could be more recent than others.
I’ll give you an example that I’m sure all of us could sit in, and it’s not tied to AI, but we’ve sat here before and it’s very relevant for how we think about role changes. Imagine you’re in an engineering organization, we declare we’re going to become product led and agile. Teams adopt scrum, standups happen, story points get tracked. Velocity metrics improved. But decision rights stayed centralized. Funding cycles stayed annual. We didn’t actually change them. And releases still need executive approval. The process changed, but the operating model didn’t. And two years later, you look at your teams and they’re still running faster, but they’re inside the same cage. That’s not an agile failure, that’s a vision failure around what the operating model needed to be and how that needed to change.
And nobody defines what autonomy actually looks like in the new world. So teams are going to optimize for the metrics that they had, not the outcomes anyone is actually looking to achieve. You have to measure for the outcomes you want to achieve.
So what do I mean by a clear future state? I don’t mean a slogan. Don’t come up with a catchphrase. Don’t come up with a slogan. You have to drive specificity in how you talk about this. In the AI coding context, I’ll give you an example of how you could phrase this. You could say, “Developers are going to use AI tools,” but a better way might be to say, “Within 12 months, we want 80% of new code to be generated through agentic AI workflows. Developers are going to spend more time defining, architecting, and validating code, and code reviews are going to shift from syntax correction to design validation.” Now you have a vision that people can actually see themselves within. They may not all like it, but they can see the picture.
And I want to be honest about something. Creating a clear future state means answering questions that most of us sometimes want to avoid. What roles are going to shrink? What skills are going to become irrelevant in the future? And what sacred processes that we have are going to disappear? These are going to be hard conversations for all of us to have.
But here’s one of the things I’ve learned in going through this is your teams are already having them, they’re having them without you, and without the accurate information of what this actually means. And if people can’t picture themselves succeeding in the future you’re describing, they will subconsciously try to preserve the present because that is what is comfortable to them.
Now, once you have a clear vision, you need to deliver clarity around the roles within that vision. How do product management, CTO, and engineering evolve? Do lines blur and are new capabilities needed in the organization that we need to build out? Declaring new expectations without equipping people to meet them isn’t just poor change management, it’s a breach of trust as us as leaders to our organization. You cannot say to someone be more strategic without training them in what systems thinking really is. And you can’t say use AI responsibly without defining the validating standards that you want them to follow in the organization. Expectations plus the enablement, plus the reinforcement of what you’re asking them to do have to align in a transformation like this. Otherwise, you’re going to have anxiety replacing motivation in your organization.
I’m going to describe something most of you have either lived or witnessed. And I think most of us in this room have seen this. You have a brilliant senior architect, deep system thinker in the organization, sees around corners technically, and is respected by everyone in the organization. A director role opens up in the team and it seems obvious, you promote them into the role. And three months later, something feels off, right? They’re still deep in pull requests, still in every architectural debate. Meanwhile, roadmaps lack clarity, cross team dependencies are slipping, performance conversations aren’t happening. Nobody failed in that scenario, but the role changed for the individual and nobody redefined it for them. Nobody said what to stop doing, what decisions now lived at their level, and what success actually looked like in moving from an individual contributor with deep system expertise into that director level role. And nobody invests in building the capabilities of what that new role was for them. Because as an organization, sometimes we assume that capabilities transfer with promotion or change in job title, and it doesn’t.
And this is exactly what’s happening right now at scale with AI adoption. Organizations are telling developers that they need to focus on higher value work, to operate more strategically, to move up the value chain. And those are the right instincts. Those are the things that we need them to go do. But if AI is generating all of your first draft code, you haven’t just changed a tool for the developer, you’ve changed their job. And if you haven’t defined for them what you want that new job to be and what it actually is for them, what skills it requires, how performance gets measured in that new job, and what their success looks like, you haven’t transformed anything. You’ve just destabilized your organization.
Strategy changes without role clarity will create anxiety in your team. Role changes without capability building is going to create fear amongst your developers. And capability building without clarity creates wasted investment in our teams. All three of these must move together as you work through this transformation. Every strategy shift that creates role tension, if we don’t define the new expectations explicitly, people are either going to cling to the old definitions or they’re going to guess at what you want the new definitions to be.
And I want you to ask yourself this as you go through this journey with your own organizations, if you were to ask 10 developers on your team, right now today, what their job would look like in 18 months, would you get the same answer from all of them? And if you don’t, if that’s not the answer, it’s not the same, that’s not their problem, that’s our problem as leaders. That’s the work we have to go fix.
Now, with any change involving people, one of the biggest indicators of success comes down to the psychological safety that you can create within your team. AI adoption will require experimentation. You heard it on stage here this morning before me. And experimentation has to allow for mistakes. And with mistakes, we must create the safety for teams to make them and then learn from them. And yet, most organizations are unknowingly doing the opposite. If engineers fear being judged for using AI incorrectly, they won’t explore. If they worry that their AI proficiency will be used against them in performance reviews, adoption and collaboration is going to erode in your organization. And if engineers can’t say this model output is unreliable or this timeline is unrealistic without political consequences, you as leaders are going to end up operating on incomplete information. And incomplete information at the executive level scales and multiplies cost for what it takes you to get through this.
And this isn’t just change management and fluff. I’ll use an example from Google. Google spent years studying what actually made their highest performing teams different. And Project Aristotle studied 180 plus teams, and they looked at seniority, they looked at talent density, they looked at the team structure, and they looked and said that the number one predictor of team effectiveness was the psychological safety that was created on that team. Not the smartest engineers, the ones who felt safe speaking up. What this means is that some of the most successful teams will look the worst on paper because team members are not going to be afraid to raise issues. I use that as the, if everything’s green, you should be most skeptical. When things are red, you know you’re getting the full picture.
And in an AI transformation, this becomes even more critical, because the technology is evolving in real time, the ethical implications are going to be real to your organization, and the job impacts are emotionally loaded right now. The stakes for silence are higher than they have ever been.
All of you should reflect on your own leadership meetings. If they are calm all of the time, don’t assume you have alignment. You should assume that you have the filtered picture of what is actually happening amongst your team.
Psychological safety doesn’t mean harmony. It means candor without retribution, it means people can disagree without reputational damage in your team, and it means that concerns are treated as data, not resistance. I’ll translate this into software development for all of us. Psychological safety ultimately shifts your defect detection left, not in your code, but in your conversation. And as leaders, we don’t build that psychological safety by asking for feedback once. You should ask yourself these questions on a regular basis. How have I responded to bad news recently? How did I treat the person who surfaced risk in a project? And did the candor from my team actually change decision or was it just noted and ignored?
And the wrapping around any transformation, and very fitting for a conference here that is sponsored by DX, is how you reinforce through structure and metrics. So I’ll start by asking you all something. How many of you are still measuring developer productivity with metrics that were designed before AI existed? Yeah, we all are, right? Because if we’re still measuring lines of code, if we’re still measuring individual heroics, and we’re still measuring firefighting speed, AI is simply going to accelerate our old bad behaviors. It’s going to be faster, it’s going to be at scale, and it’s going to be in the wrong direction.
This principle is mostly around organizations, and most organizations want to skip this step because it’s the hardest one of all to measure. And you heard it on stage here. In some ways, we don’t know exactly what to measure right now, and so that can make it exponentially more challenging. But that’s exactly why this matters the most.
Measuring lines of code is simple, right? We’ve had this conversation, I’m sure all of us here with DX as we’ve talked about this. Measuring architectural quality, business outcomes and team enablement is genuinely hard, especially in engineering organizations that have optimized for quantitative metrics for decades. This is going to be the most challenging for all of us to get right because there is no one answer, and it’s going to be unique for each of our organizations. But the difficulty isn’t a reason to avoid it. It’s a reason to start thinking about it now.
And AI is going to make this measurement of metrics in your operating model more complex, not less. We now have entire new cost models and consumption dimensions that we need to take into account that didn’t exist two years ago. Token economics, model routing, and workflow costs that we didn’t have to think about two years ago, but we do today.
And most organizations don’t have frameworks for any of this yet. The gap is a risk, but metrics alone will not be enough. The real question is whether your entire operating model is going to reinforce the new behaviors that you want to see from your teams.
Are governance structures reflecting the new model? Is funding enabling the new ways of working in your organization? And are incentives rewarding the future state or the old one? Metrics and structure have to move together. Otherwise, we’re asking people to change while the organization stays the same.
And here’s the test. If you stop talking about the transformation tomorrow within your organization, would your structure still drive the behaviors that you want to see? If the answer is no, you don’t have transformation, you have an initiative in your organization. If the answer is yes, you have created durable change in your team.
Now, every one of these principles requires someone in this room to go first. Not after the strategy is perfect, not after the tools are proven, but now while it’s still uncertain, and that’s all of us in this room. And as leaders, our role in this transformation isn’t just to sponsor it. It’s to model, it’s to narrate it, and it’s to stay present in it. You have to know the good, the bad, and the ugly from your teams directly, and you have to sit in it with them. You have to reward experimentation even when it fails. You have to use the tools yourself, visibly, imperfectly, honestly, and it means narrating the changes continuously, not just announcing it once and moving on.
You’re going to have to make the career paths of your individuals explicit, not conceptual. You have to make it very specific for them on what that means, because developers are quietly asking questions that we’ve not answered yet for them. They’re going to ask questions on, can I grow here without becoming a manager? Is deep technical expertise still valued if AI can replicate my output? And what does mastery mean when tools are changing this fast? If we don’t answer these questions intentionally, people are going to answer them for themselves, and the best ones, the ones with options, will answer them by leaving.
And it will be table stakes for all of us in this room to stay emotionally present in a transformation of this size. Not just strategically engaged, but emotionally present for our teams. Because your team doesn’t just need a sponsor, they need a leader who understands what this actually feels like, and they need to understand what is challenging the teams the most.
Now, the one thing all of us can be certain of when we walk out of here today is that AI is going to change how software is developed. And if not managed intentionally, this change risks being internalized as a reduction in a value of our developers to the organization. When the truth is exactly the opposite. This transformation will elevate at the level at which they operate, but elevation is going to require intentional change management. And the organizations that succeed are going to redefine their roles, they’re going to redesign the career paths in their organization, and they’re going to rehumanize engineering. Because at the end of the day, AI will generate code. Humans are going to generate the direction. AI is going to accelerate execution, and humans are going to define the meaning behind what we build, and meaning is still the most valuable system that we build.
I will end where I started. Three years ago, that conversation would have ended my credibility at Dell. Today, not having it would put your organization at risk. That’s how fast this is moving, which means that the window to lead this intentionally, rather than react to it, is right now. Thank you.