In this episode of Leaders of Code, Jody Bailey, Stack Overflow’s CPO, Anirudh Kaul, Senior Director of Software Engineering, and Paul Petersen, Cloud Platform Engineering Manager, discuss the U.S. Bank’s journey from traditional banking practices to embracing new technologies.
U.S. Bank has undergone a significant digital transformation, implementing a multi-cloud strategy to accelerate innovation and improve customer-focused development. Operating in a highly regulated environment, the bank must navigate the challenge of balancing innovation with strict compliance requirements while meeting the evolving demands and needs of customers and employees.
In this episode of Leaders of Code, Jody Bailey, Stack Overflow’s CPO, Anirudh Kaul, Senior Director of Software Engineering, and Paul Petersen, Cloud Platform Engineering Manager, discuss the U.S. Bank’s journey from traditional banking practices to embracing new technologies. The conversation covers the technical and organizational aspects of large-scale cloud migration, along with their leadership approach during this transformative period.
Key topics include:
Notes:
Eira May:
Hi everybody. Welcome to the Stack Overflow Podcast, today we have another episode for you of Leaders of Code, we are chatting with tech leaders about the work they're doing, the challenges, their teams, their customers, their use of AI, and so much more. My name is Eira May, I am the B2B editor here at Stack Overflow, and I am joined by Jody Bailey today. He is the chief of product and technology at Stack Overflow. How's it going, Jody?
Jody Bailey:
It's going well, thanks Eira. It's good to be here again, looking forward to another conversation.
Eira May:
Yeah, thanks for joining us again. We're chatting today with Paul Petersen, who's a cloud platform engineering manager at U.S. Bank, and we're also talking with Anirudh Kaul, who is senior director of software engineering at U.S. Bank. I'll turn it over to you, Paul, could you tell us maybe a little bit about how you got into the world of software and technology, and a brief version of how your path led to where you are today?
Paul Petersen:
Sure. I started 30 years ago, just on a help desk, and got in when, I graduated from college, didn't know what I wanted to do, and then just fell into different stages of tech, and mainly was doing desk side service and help desk stuff, and then I got into automation because we had to scale out builds for desktops and servers and networks. And so, I really got focused on a lot of the infrastructure, and then about, I started getting into automation really in the 2000s, and about 2010 was when I started to figure out that we were running out of ideas about how to automate things inside the data centers. And then, about 2015 or so we started to see other corporations use cloud as a mechanism to build different types of data center.
I'd always been situated in desk side, desktop, or data center technology. So, when I got into seeing the cloud and how people were building out things so much more quickly through automation, that's really where I got focused on that. And then, everything else around that came about. And because U.S. Bank was fairly behind in adopting some of those things, it was a huge opportunity for me to help push the cloud strategy, and that's how I really ended up doing cloud platform engineering, and that's where I'm today.
Anirudh Kaul:
Sure. I started off working in the software line of things, in a very different sector. I started off in the telecom sector, back in the day, work was heavily on-prem, working with telecom systems, and more of the application side of stuff, in the upper layers of the stack, if you will. Spent a lot of different roles and times and functions over there, then moved over into e-commerce, spent, I don't know how many years, a very, very long time in the e-commerce world, and then very similar to some of the things that Paul laid out, there was a great opportunity here with modernization and transformation, which also comes with its challenges, but all exciting, so took that on and that led me to U.S. Bank.
Jody Bailey:
I'm Jody Bailey, I'm the chief product and technology officer here at Stack Overflow. I joined here from Amazon, AWS specifically. My start was pretty similar to Paul's and maybe those of us that have been around long enough or have a lot in common where many of us got into the industry without a specific computer science focus. My original degree was in physics, had some electronics, some programming, and then I was working in the financial industry in kind of a MIS role. If you've been around long enough, you might remember the idea of information services. And then I started writing code and solving problems through code, and worked into a software development role. At this point in time, I can say the majority of my career has been in technical leadership as opposed to actual hands-on development and implementation. So, I qualify as a pointy-headed boss I suppose, in most circumstances.
But I've been here at Stack for a little over three years, and it's been a really interesting time, I took over product earlier this year. And yeah, it's super interesting all the stuff that's going on. And I know U.S, Bank is one of our Stack Overflow for teams customers, so I'm really excited about that, and look forward to that partnership, and really looking forward to the conversation today. So, with that, maybe can you orient me a little bit and tell me a little bit about the Shield platform team, what y'all are doing there? And maybe we can go from there.
Paul Petersen:
I'll start and then Anirudh can add in. So, if you think about our journey to the cloud, a big part of what we've learned through prior implementations was that the application teams needed more opinionated solutions to actually solve some of our governance requirements. So a big part of what we were doing was, being in financial services, heavily regulated, we had to bring a lot of our governance with us. And when I say governance, it's security control, it's giving people pre-configured templates in concept, but it wasn't good enough to say here's some configuration solution, you had to actually build it in and integrate it with all these other things.
So, a big part of the strategy was let's build that out by default, let's make it a platform, and platforms will enable us to scale, and that's a big part of it. So, it's really coupling the cloud infrastructure with the application developer, DevOps set of capabilities. And Anirudh's had a lot to do with that part, so I'll let him talk about that. But if you think about it, the idea was if we build a good secure platform, we'll enable scale and quicker adoption to the cloud. And Anirudh, I don't know if you want to add something there.
Anirudh Kaul:
Yes, thanks Paul. The one thing I would add there is, as we are doing all of this, it's also important to see where some of those frictions are, right? And try and automate a lot of that. So, if you think of it more from a fully automated CICD pipeline, just allows you to integrate continuously, continuously deploy, and really have that full stream of builder tools, how do you keep figuring out all of those pieces, which may be manual steps, or may require some sort of human intervention, and automate them to best possible way? While, of course, reducing some of the frictions that a developer has, but at the same time also passing them back the message on where they are in their whole build process, so that eventually, of course, the north stars the teams can focus primarily on building out their application and a lot of the other processes along the way are automated.
Jody Bailey:
Can you give me, or give us, an idea, when you say scale, I don't know how much you can say, but about how big is your engineering team? Because building platforms and getting people to adopt across a wide range of skills and people can be challenging. Maybe share a little bit about what kind of scale you're talking about.
Paul Petersen:
Yeah, I think if you look across all the teams involved, you're talking about several hundred people, because you're either cloud infrastructure, my team, where we're actually building out on multiple cloud providers, and creating the networks and the set of standard services that the F-teams consume, all the way up to what other teams, like Anirudh's are handling, with actually happening the DevOps tools, the skills to build and automate on top of that. And so, you're talking about several hundred people that are doing that. The intent is to handle a few thousand applications, right now we're kind of focused in on about 1000 that would be enabled by this.
But to keep in mind, we also do many things in our traditional data center, we're bringing some of these technologies back to that, and integrating our solutions so that we can get scale there as well. And the whole drive, like most of the industry right now, is to just really drive the efficiency, and so we're trying to make sure that automation's part of that.
Jody Bailey:
Okay. And when it comes to figuring out that automation and what pieces you want to build out, how do you identify the requirement? Are they top down, or are you bottom up, or some combination?
Anirudh Kaul:
I would say it's a mix of both, right? And Paul, you can chime in along the way. But it's three ways actually, of course, some of it is also context, around what are some of the challenges that have existed, there's also the feedback loop from the teams, and the consumers, people who are using that. And you'll often kind of see... You'll have these different forums where people talk about different things, and sometimes it may be tickets and all, but what you also need is some sort of mechanism to structure that feedback into either some sort of surveys or voice of the customers, so that you're able to land up with a good sort of prioritization, which tells you, okay, here are some of the frictions... And it doesn't need to be overly complex to define the value, it can just be here are some of the frictions that we have, it'll cost us so much to solve these, and this is what it fixes.
It's easier said than done, of course, just drawing out the table is easier than filling that out, filling out the values, but then at least that's a start. And then, you start saying that, okay, we have so many customers who may be wanting X versus Y, or so many customers are on a certain kind of pipeline or application. So, if we move them, it helps us save a larger portion of the cost, or a larger part of the effort, and that's kind of how we try and go about some of these things.
Paul Petersen:
The thing I would add there is, when you have a large program that we're currently under, to really migrate a lot of applications to the cloud from the data center, prioritization is a matter of how many apps, what do they require functionally, but also a non-functional requirement, like we have to have a security control embedded somewhere in there, and we don't want the app teams to worry about that, we'll solve it once and then scale it out. Those things are pretty transparent as far as priority, I think Anirudh touched on an interesting point where we start to enable a lot of those core functionality, and then the question is, well, what's next and how do we prioritize that? And so, now I think what we're getting to a point is we're talking about cost benefit analysis, which is why should we enable your use case or automate your use case?
And what I've learned over time, you can have somebody who has a really good idea for automation, but the amount of time you have to invest to automate it, which is usually at the higher scale of salary, very advanced engineering, may not pay you back in the frequency for those efforts, so you really have to look at things from a cost benefit perspective, which is, you want to automate everything, but it might be too expensive in some cases. So, I think we're trying to get to a point where cost benefit becomes more part of the conversation, versus just say, hey, we should just do this because you're there, right? Well, is it a good use of our resources also?
Jody Bailey:
Well, it sounds like you've got a lot of compliance components, I imagine part of the motivation of getting to the cloud is to allow people to innovate and move faster. So, how do you balance and how do you think about enabling the innovation while enforcing the compliance components?
Paul Petersen:
So, I think it's varying degrees of guardrails, right? So, I think if the teams that really want to get out there... AI is a good example because everybody's looking at it, and financial services is a little slower to adopt because of the governance requirements. A lot of what you'll find is if you bring your traditional data center requirements with you, you kind of fail in the cloud. Because the idea of perimeter and boundary is so fixed in the idea that's inside the data center, it's a very castle moat kind of structure. And so, as we've gotten into the cloud, it's how do you start to bring not only your network perimeter, but also let's say your identity as being a major piece of your strategy, so that when people come to innovate inside the cloud, they're going to do something with AI, or they're going to do, it used to be machine learning five years ago that we were talking about, right?
Or they just want to try a new product out quickly. It's kind of building it in with some guardrails so they can do that safely. That does limit their ability to try anything, it only lets them try some things. And we find that often the feedback we get is, it's too friction full, and they can't actually innovate to the fullest degree that they'd like to. So, we're trying to figure what that balance is. I can't say we've nailed that in all cases, but data exfiltration, other things like that, they just matter, because it may not be customer's data that we're working with, but if it's other data that might have brand impact, we have to really think about that quite a bit.
Jody Bailey:
I am curious, so we just completed the last of our cloud migration, if you will. So, stackoverflow.com was running in a data center for the past 15 years, and we optimized a lot of things to be really efficient and effective there, and just completed the migration. The team did a great job there. But there are so many pieces, and figuring out what things still matter and what things you have to migrate, what things you have to convert, how did that process go for y'all?
Paul Petersen:
I would say it's a work in progress, and it's difficult. Because what we started originally with our strategy, we are starting to think about how to modify that, as we've got through a certain number of applications, and then it became very fixed on here's the count of applications, and that's what we told our board, and that's what we built our funding model around. But then we found out, well, that actually may not be the best measure in all cases. So, what actually has the largest data center footprint? But I would say you have to be willing to pivot, and look at it, and it's always kind of being challenged to saying, is this still the right strategy? Now, you can't pivot that strategy that fast because you have so many parts and pieces and people doing it, when you look at the typical discussion that comes up about should I move to the cloud? Where's my value in doing that? Am I on the list, right? Meaning, I was forecasted to move, but then which cloud should I go to?
Because we have a multi-cloud strategy, that's one aspect, and then also what should I do in the cloud? How much should I transform? And am I just a lift and shift, and is that good enough to check the box, and I can maybe get a lower cost footprint? Or maybe because I lift and shift, I have a higher cost footprint? Or I don't have a good cloud-like equivalent. So, I think that's a lot of what comes in there, and probably all the things that you went through in your cloud migration strategy.
Jody Bailey:
How much do you empower the individual teams, the owners of the applications to decide when it comes to the migration or other projects? I'm just kind of curious how much top down versus autonomy do you give there?
Paul Petersen:
Quite a bit top down. A big part of what we're doing is letting them tell us what they need from a services perspective, and understanding the application architecture and get a sense of how much they want to transform. Many cases where they land is kind of dictated by some other criteria. Now, some people are challenging that, say, hey, well I feel more like I'm Azure, I feel like I'm more AWS, but here's why. And they have to really come up with good criteria and justification. But I think from that perspective, it's pretty centrally figured out for them. And then, people are allowed some exceptions or challenges based on if we're going to somehow disrupt their business.
Jody Bailey:
Makes sense.
Anirudh Kaul:
You know what else I feel helps in such situations also, right? Is if it's top down, you have to do it. And obviously there are broader goals and mandates, but kind of getting them in the loop sooner, and now having the inform happen sooner, and keeping them priced of, hey, we have a migration coming up, and just trying to give more time and more runway to plan, can help. Versus, if you came up to somebody's door and said, you have to wrap this up at the end of Q2, when you have only 14 days to do it now, that's disruptive. Sometimes, not always, 100% of it cannot be solved, right? There will always be teams, there are teams that are always pressed, and they have Firehose deliverables running through. If you have the informed steps and reach out to the stakeholders and pricing the plans, some of this can help, at least in terms of laying out and planning and keeping them in the loop of what's happening.
Jody Bailey:
I'm curious about getting them to adopt new practices. One of the things that I've experienced as we've embraced different ways of doing things, not just going from data center to cloud, but as we look at new ways to innovate and empower teams, and we shift the way we work, sometimes we're asking the teams to change how they work, and we have certain expectations of them, but oftentimes the changes are new to leadership too, and we don't always get it right the first time. And one of the things that I've seen be really important for us is, as leaders, to be fairly transparent and honest about, hey, yeah, we made a mistake here, and we're going to work with you and adapt, and we're learning together. I'm curious, do you experience the similar things or has that worked for you or have-
Paul Petersen:
I think the things that I've seen is, admit it when we don't get it right, be transparent. If it's hard, acknowledge your customer, engage with your customer. So, one of the things that we found was that if we just acknowledge where people are struggling, and said, that's what we're going to focus on, we got much better buy-in, right? It's pretty obvious, right? It's just good customer service, and it's just about being more product-oriented. I think also saying, hey, we're measuring our success, and it's 67% here, but 43% here, we know that's not good enough, but it gives some level of transparency that they can also watch those things. And then, the other part that I would say, if I look at some of the stories or my experiences with some senior leaders on the application development side, they might have used language early in the migration to say things like, you're doing this to me, you're making me do these things, and finally just with some hard conversations, which is, how do I get you to say things like, we're doing this with each other? And you have an open accountability.
Because in the end, I'm not migrating my application, you're migrating your application, but I need you to be successful for me to be successful. And I think part of it was there were so many people out there who were early adopters, who were so patient, we owe them such a deep debt of gratitude, because they stuck it out, and now they're some of our best advocates. They've invested, and they don't want to go back. There's cases where the business case did make sense to go to the cloud, and that was maybe a one-off, but the case where they've invested. So, we just did a town hall, right? Today. I looked to one of the other senior leaders, and one of the things I was so encouraged by was, it wasn't about, hey, why am I still going to the cloud? It wasn't buy-in, it was like, when's this next wave of services that enable me go further?
And that was super encouraging to me because what I read from that was, we were challenged really on future capabilities, hey, what are you doing with this part of the strategy? It just felt like a different conversation than it was a year ago. A year ago it felt like, why are you doing this to me? Or the last two years. I don't know, Anirudh, if you've experienced different things, you're often interacting with a lot of the app teams from your tooling perspective.
Anirudh Kaul:
Yeah. It goes by the same thing around just earning trust, and how do you share updates, communicate, keep stakeholders involved. But at the same time, to answer your question, it's also important as a leader to be willing to dive in and understand, taking the time to understand what the problem is, what are some of the limitations of different teams, and kind of going from there. And of course, you need mechanisms to effectively scale, but often putting yourself in the shoes of the customer also helps. If I was the customer on the other side, and I got to hear something like this, or I had to do something, what would've sounded better?
And it's an ever evolving process, it doesn't stop. Just continuing to have those mechanisms, and really leaning in with your stakeholder or customer, you build that trust along the way to work, and you see that somebody who's upstream to you or somebody who's helping solve a technical challenge for you is also aligning, and you're not kind of on the side of your problem versus mine. So, these are mechanisms, and then you keep thinking about how do you put in these mechanisms and slowly they start to scale.
Jody Bailey:
Yeah, I love that. And I think Paul hit on a couple of things that resonate for me. I'm curious, it sounds like they're largely the same for you, Anirudh. One of them is having a clear north star, helping people understand what the outcome is. Why are we doing this? And how is it going to be useful to you? And then, the other thing are those early adopters, that can be missionaries or the advocates. Do you see that in the tooling as well, Anirudh, where you go from the pushing to where they're pulling you, right?
Anirudh Kaul:
Yeah. Yeah. And you also work with teams which have a larger footprint, so you have to pick and choose who those first customers can be, because if you pick too small of a customer to begin with, you may choose a very small customer to start with, make sure things are working, and your process works, but then you also have to find the right bands between your customer that has a large enough footprint to be able to have other customers empathize, yes, they were able to do this at scale, so maybe we are also able to do this and push along the line.
Jody Bailey:
Especially in the dev tooling side of things, how are you thinking about the priorities? A lot of it is, it's top down it sounds like, at least on the cloud side, from a dev tooling perspective, how are you setting those? And how do you balance, implementing tools for thousands of applications, hundreds of developers, multiple clouds... Sounds a bit daunting, candidly.
Anirudh Kaul:
And it's a mix of different things. One is, of course, you may have top-down mandates, or you have mandates move to the cloud, but the other side you also look at other levers. For example, other opportunities to streamline your operational efficiency? And just be more operationally efficient. Which could mean using sprawl, or figuring out how can we utilize existing tools for more functionality. Kind of always being out there and see, okay, what is the trade-off and buy versus build, right? It's not always right to build versus it's not always right to buy. So, how do you look at some of that? Because at the end of the day, teams and resources are also finite, so you don't have all the capacity in the world to say that, okay, I have five different tools, and I want to take five different tools for five different functionalities.
So, you have to keep looking at the external angle of it, what are your internal requirements? What are some of the frictions that people are using with existing tools? And also, looking at tool compatibility. For example, if people are using a certain kind of pipeline to build, or a certain set of environments, how do other stores interact with it, or how do your other tools fit in that ecosystem? That becomes more of the longer term, when you think about, hey, for example, Paul spoke about things that moving to the cloud, and we want infrastructure there, so 12 months later or two years out, how would the existing infrastructure, existing set of tools look like, and what should that mix change? You have to look at all of these and then keep making the priorities. And then, of course, some things make the cut sooner, some things just get pushed out.
Jody Bailey:
In terms of innovation, whether it's across the company or within your own teams, how do you think about innovation, and how do you, assuming you think it's a good thing, how do you encourage it?
Paul Petersen:
I would say it's challenging because if teams are busy doing a lot of things that are routine for them, they're not going to make time for the innovation. So, one of the things that we've tried to do is give people permission to do it on the job. Let's not tell them how to do everything, let's not dictate all the methods, let's let them explore and carve that time out to do those things. One thing's also is just maybe setting goals for... This sounds very routine for people. But setting a goal that says, I want you to come back with a certain percentage of your code written with AI. Even if it's not good code, even if it's not that useful, I want to see certain percentage and I want you to tell me where to use this and where not to use this technology.
So, I think when you make it more of an on-the-job responsibility, and you give them the permission to not succeed, but try, that goes quite a ways. It sounds pretty self-explanatory, but when you're a high pressure environment and you've got to deliver, teams will cut out innovation first because they're just going to. So, the question is where do you create the room for it? In some cases I tell them, well, you're kind of an incumbent for innovation because you're bringing the bank forward, but the innovation that we're working on isn't new, cloud isn't a new concept, it's new to the bank and for some teams.
So, in a sense they are part of that solution, but even what I found is some of my engineering teams that have been working on this for a long time, they kind of skip machine learning and AI as technologies because they're so busy with cloud engineering. So, my bigger concern was, for their longevity and their careers, was giving them room to go and venture out into these other places, and then how could they bring them back and make it part of the job? I don't know, Anirudh, if you've had other strategies.
Anirudh Kaul:
We've tried a few sometimes with just cross-pollinating teams. And of course, it sounds so tricky because a lot of that balance has to start with leaders, and you figure out pockets where you can afford to maybe cross-pollinate, right? And gauge what the slip in velocity may be. Or maybe there isn't sometimes. But just by having a constant pulse, or trying to get a pulse on what are some of the new areas of technology that other people in the team may want to work on, and figuring out ways by which you can move them around, for smaller projects or smaller initiatives, just also helps them learn something new and innovate something new, that seems to help as well.
And also keeps people excited and motivated because they feel that yes, we are also learning something, we are making an impression in a new area, we are working on a new team... They may come back and say, oh, well, I think our own team is good, and we don't like the ways of working with the other team, or they may like the other team. So, I think that also does help in just keeping the spirits moving.
Paul Petersen:
I think that cross-collaboration and cross-pollination is a good point. I think the other thing that, when people see somebody else do something, you say, hey, why are we not doing that? So, sometimes I'll turn that around and say, why aren't you? What's blocking you? Do you feel like you're unable to go try that? And what's stopping you from doing that? Really put the pressure back on them. Now, are we creating an environment where they can do that is the other question. The other thing I would say is sometimes we get so hung up on innovation as a new capability, versus innovation might be an approach.
Having innovative, smart ways to deliver something that already exists with the same capabilities, there's merit in there, and I think there's other values there that we sometimes lose. It's a little bit more subtle and harder for people to understand, but it's how we don't get stuck in a, am I trying a new thing versus am I trying to deliver something a different way? And that innovation can lead to a lot of other benefits, I think, and sometimes you got to redefine that for people and give chance to think about it.
Jody Bailey:
I love what you're both saying. And the first thing I think that is key, and I've had this conversation with leaders in different organizations, I don't know how many times. When your boss comes to you and says, we need more innovation, it's like, well, we need to give the team time to think and to innovate. And if they're always busy spending 100% of their time delivering, you can't really expect innovation, especially if there's no tolerance for mistakes, to your point. Which is the other piece, you have to be willing to make some mistakes. So, defining those guardrails, understanding where it's okay, or where it's not, helping them understand. And then, another thing I think you touched on that I think is really important is visibility. So, for example, we have regular demos across the organization, where you can just demo whatever, and that's pretty good.
But what's one of the things we've done that's been really useful is just having a Slack channel, where everybody can share in one place, things that they're experimenting with, different ideas, even pointing to examples of things that they've done, just so that folks can get ideas from each other and riff off of that. Similar to your cross-pollinating and moving people between teams, even just sharing ideas, found to be pretty helpful. One of the challenges that I've experienced with platform tools and building them is actually getting people to adopt them. So, you may come up with things that you believe is going to help them move faster, but then people get accustomed to doing things the way they always have. I'm curious how you all manage and deal with adoption, is that a challenge for you, or what are the things you've found to be successful to get teams to adopt new platform capabilities?
Anirudh Kaul:
This is twofold, as I've seen this, right? The first up is just really defining what the value to customers would be, in terms of, if you're building something new and you're replacing something, there has to be some value that comes out, just trying to quantify some of that value. And value could be in many ways, it could be in reduced time to build, reduce time to deploy, reduced time around operations, better compliance, just better risk posture, for example, a bunch of different things, if you will. But the other thing also is about, yes, you talk about these values, are you able to show that to them? So, that's kind of where, as you're engaging with customers and giving them demos around what to come, are they able to see some of those values through demos? And then the last piece is of course, prioritization, which is, sure, okay, now I see the value, this is great, all of this is good stuff, but how do I prioritize this? Or I don't have the time to do this, or my leadership may not be aligned.
So, that's where building the customer trust, building the stakeholder trust, having prioritized roadmaps... Also making sure your own team is scaled, to be able to support something like this. So, you don't say that, okay, for example, this 50,000, 100,000, or whatever, just an imaginary number, you have so many customers out there, you don't tell everybody that we'll just migrate all of you today, or deprecate your old tools in favor of a new tool today. So, you kind of break that down. And then, one nuance here is you also have to be very cognizant about what is the work that they will need to do to move on, and how can you simplify some of that to a large extent?
Because at the end of the day, if you're moving them to a new tool, or a new tech, there will be steps that they have to take along the way to move off. Now, you cannot do 100% of the work for them, but how do you provide them the learning and the resources, which could be guides, user guides, or procedure books, or simplified steps, or automated scripts, or what you will, to actually be able to do that in the least complicated way. And again, you don't get this right the first time, but you just need to keep, at least have a template, have that boilerplate template, have the placeholders, and as you go, you keep filling that around, say, okay, this is what we learned in this round, and this is what we learned in round two, and you kind of keep iterating on that.
Paul Petersen:
I'm curious if you, Anirudh, or even Jodi yourself have run into understanding what's an incentive for people to change? Sometimes things are top-down and forced, there's a mandate or there's an obsolescence challenge when it comes to tools. I've had a variety of them, but they've been mainly in the data center space. We tend to get a lot of friction on some of our infrastructure's code today, because of the complexity. So, to Anirudh, your point there, it's about making it better for them and learning from that, and being open and transparent about, hey, we got this wrong... We got some of these part rights, we got some of these things wrong, let's fix it. So, I think that's part of it. But I'm just curious if you guys have run into cases where you have to determine what your customer's incentive is to change, and then work from there.
Jody Bailey:
Yeah, 100%, from my perspective, in fact, when I think about building platforms and tooling and stuff, it's kind of the golden pad, how can I implement something that's actually going to make their job easier so that they want to use it rather than feeling like they have to use it? And when you can't always do that, especially taking somebody from a data center to the cloud, initially, it may seem like more work or it's harder or whatever, I think you probably see it too, where, just sometimes change is hard and people are resistant. But I think figuring out the motivations is essential, because at the end of the day, you're trying to sell something to them, and you want to make sure that you're addressing their needs, and what's valuable to them.
Just playing on the selling metaphor. The other thing, and Anirudh, I think you were kind of talking to this a bit, is marketing, right? Is really making sure people even know that it's available, and that it exists. We've seen that even internally as we've tried to move more towards microservices, and building out the frameworks, and the tooling, and everything for that. And one of our leaders created a logo, and it has a name, Free Refills, and caricatures, and that advertising internally is really important, making sure it's front and center, people know what they can and can't do with it, to the documentation point. I'm curious though how you all think about that kind of internal marketing of what you're building in terms of actually making sure people know what's there and what they can do?
Anirudh Kaul:
For internal marketing, I think it's important to just reach out to all of the audiences. You may have certain discussions in a certain group, within a certain leadership group, but at the same time, it's also important to reach out to the wider parts of the organization, and folks eventually who you will work with on this. So, just making sure that a lot of the information dissemination happens across, versus, hey, somebody learns of it or hears of it in corridor, and it is third hand, fourth hand down, or you learn of it at a much later stage, I think having those meetings, prioritizations, quarterly plannings, and roadshows and demos will just target different groups of audiences and different numbers of audiences is important to just keep spreading the message about there is something out there, there's something that's coming up, here's how this will benefit you, here's what you would likely need to do, here's a rough sense of time, I know when this will happen, and then you just keep going over and over again with it.
Jody Bailey:
The old adage, if you're not tired of saying it, you haven't said it enough.
Paul Petersen:
I think that's right. I think we often forget that they need to hear it continuously, and they need to hear that message. And that's, a lot of times, we go, hey, I released that, I'm going to move on to the next, but we don't go back and say, hey, do you know that's still there? It's available to you. What do you think of it? That's a good point.
Jody Bailey:
Anything else that either of you'd like to bring up that you think we should talk about in terms of platform engineering and really empowering your teams?
Paul Petersen:
I think the one thing I find is there's many teams that I run into, they don't really know why we're doing platform engineering, and I really don't want to turn it into something like we exist for this reason, but I think more importantly is, we think there's an intrinsic value there in building these reusable capabilities, so we've spent some time just talking about those basics. Why are we doing this the way we're doing it? But then ultimately, in the end, that shouldn't matter, it should be about the products that they consume that we want them to consume. And so, I think we're trying to make that transition into a more product mindset, and so platform engineering might be the functional thing, but in the end, user functional thing is the product we consume on that platform.
And we've internally had to make it quite a transition from our skill sets because we come from traditional infrastructure management, there's some software engineering background with some of the team, and a lot of people have transitioned to that, but it's a foreign concept to many of us. So, I think we've learned over the last years, several years, about thinking more product, and thinking about end customer, and then also why building a platform important, not to build the platform, but it enables, right? And I think that's just a big transition for a lot of us, I think it's been interesting culturally too, just as far as our workplace.
Jody Bailey:
Yeah, 100%. Yeah. I think of it just like building external products, you're trying to find that product market fit, and once you do adoption, hopefully it flies and everybody's better off. How about you, Anirudh?
Anirudh Kaul:
I think that a lot of these transformations, one of the things I did observe is just understanding the existing culture, and challenges and context is important. Before you say that, okay, we'll do all of this, the point Paul's raised, if traditionally certain teams have skills in something, or they do something, you also have to understand why things are... And again, everything happens or is in place for a certain reason. Or if certain processes or technologies are existing in a place, they probably are there for good reason. Just because somebody doesn't know it, somebody is new enough to not understand, does not mean there isn't context. At the time there would've been context, so it's important to kind of understand that, and then figure out, if you have a certain plan in mind, you have to figure out again what the product is versus what is some of the transformation process, and the engineering that you're doing to build out that product, and then also how do you blend that into the culture of the organization? I think that is important.
Eira May:
Thank you for listening to Leaders of Code, I have been Eira May, I am the B2B editor at Stack Overflow. If you have any questions or suggestions for guests that you'd like to hear from, or topics that you'd like us to cover, you can email us at podcast@stackoverflow.com or you can find me on LinkedIn at Eira may.
Jody Bailey:
Thanks, and you can find me probably, the best place is on LinkedIn, it's Jody Bailey at LinkedIn.
Paul Petersen:
Yeah. Hey, it's Paul Petersen at U.S. Bank, cloud engineering and operations, you can find me at LinkedIn at Paul Petersen at LinkedIn. And that's three Es on Petersen.
Anirudh Kaul:
Thanks, this is Anirudh, thank you for having me on this podcast, and you can find me on LinkedIn at Anirudh Kaul at LinkedIn.
Eira May:
Thanks for listening, we'll see you next time.