Jeff Schnitter:
I liken it to a basketball coach. A really good basketball coach is doing his work at practice. When he's on the sidelines, he shouldn't be screaming and hollering, because he trusts his team to do the work that they need to do. Same thing with an engineering leader. This is what we're going to do. You have those discussions. Stand out of the way. Don't holler from the sideline, and allow those rituals to show the progress that's being made.
Ganesh Datta:
You're listening to Braintrust by Cortex, where we explore how engineering leaders blend AI, platforms, and culture to build high performing software teams. I'm your host, Ganesh Datta, CTO and co-founder of Cortex, an internal developer portal designed to help engineering teams ship reliable software faster with AI. In each episode, we go deep with CTOs, VPs of engineering, and technical leaders who have been in the trenches, navigating the tension between speed and quality, building reliability at scale, and figuring out how to lead through major platform shifts. Whether you're running a team of 10 or 1,000, this is your space to learn from people who have made the hard calls and lived to talk about it.
Hey, welcome to the podcast. I'm Ganesh. I'm the co-founders and CTO at Cortex. You want to introduce yourself real quick?
Jeff Schnitter:
Yeah. Hey, Ganesh. I'm Jeff Schnitter. I'm a solution architect at Cortex, as you know. You and I met, I was a customer of Cortex at Workday, where I worked in developer experience, developer productivity, release engineering, test automation, those types of areas.
Ganesh Datta:
Thanks so much for joining the podcast today.
Jeff Schnitter:
Thanks for having me.
Ganesh Datta:
Well, today I want to talk about a very broad topic, which is how do you change the culture of an organization? And I think this topic is really interesting today because a lot of organizations are thinking about this, particularly from the lens of AI, which is how do we adopt more AI? How do we get our organization to think about it? But we see this happen a lot with other things as well. We want to create a culture of reliability. We want to create a culture of security, of shipping fast, of quality, all these kinds of things.
And so, this idea of changing culture I think is really interesting, and it's one that's not really talked about a lot. And so, in your role, you've had the opportunity to really think about, how do you change the culture of an organization? How do you shift it to something that hasn't really been done before? And so that's what I want to spend some time talking about today.
Jeff Schnitter:
Yeah, I love talking about it.
Ganesh Datta:
All right. Well, maybe at the very top, how would you define culture? How does it play out? Because I think we need to start there before we can talk about how to change it.
Jeff Schnitter:
Yeah. I think when I think about culture, it is about the attitude that the organization has about addressing those problems. Are people aligned to solve the same types of problems in the same types of ways? Because if you're not aligned culturally, it's going to make it very difficult to implement the type of change that you want.
Ganesh Datta:
That's really interesting. Yeah. The one that I've heard is, how do people behave when you're not in the room? As a leader in particular, if you're there, you make a certain type of decision. If you're not there, does the organization do it the same way? And I think that's a more leadership-oriented version of that same thing, but I think it touches on the same concept, which is the behaviors, the attitude, the way the organization thinks. Why do you think different organizations have different cultures?
Jeff Schnitter:
I think they have different motivations. Is security the key thing? In my background, we were a key HR application running in the cloud. Zero reportable security vulnerabilities. That was core to everything that we did. Every ritual, every meeting that we had, we started off with zero vulnerabilities. We were all about security.
I think other organizations, as I've got to know them, it's about shipping faster. Maybe you're out in the commerce industry, you got to get to market faster, you're fighting other competition. So I think, depending on where your focus is, you're going to have a different type of culture.
Ganesh Datta:
Why would an organization want to change their culture?
Jeff Schnitter:
They know that they have problems. I think every organization wants to change their culture because they see little problems that creep in. The interesting thing about software and organizations is they're so organic. They're never the same day-to-day. It's a constantly evolving thing. So what might've been your culture a couple months ago, a year ago, it morphs into something else requiring change. And so I think it's this constant analysis that you have to take a look at. How do I need to run my business?
Ganesh Datta:
In your experience, have you seen the culture of an organization reflect all the way through, or do you think different teams have different cultures, and are those things in conflict at times?
Jeff Schnitter:
I think they're always in conflict, because I like your analogy about how do you act when no one else is in the room? How do you manage things? I think different teams are going to organize in a different way. They're going to operate in a different way. Now, you might have rituals that you meet every quarter, maybe every six months, your all-hands. You're getting the messaging, but it doesn't always permeate throughout the course of the year. So I think there's a little bit of variance that you're going to see as each team operates, because they operate individually and then they'll come together only from time to time. And so, that's where you start to see things fall apart, where teams aren't all operating underneath that same umbrella of the things that you're trying to achieve.
Ganesh Datta:
Can it be a good thing if some teams don't have the same culture as the broader organization?
Jeff Schnitter:
I think absolutely. Because this is a battle I've fought in the past. I thought you got to standardize, use the same tools, everybody do the same thing. And I learned really the hard way, that you don't tell people the way that they should run the business, the tools that they should use. And I realized that the outcome should be the key that you're looking at. Now, how you get there might vary a little bit. That might have some variability in the culture, as well. If you agree that there are some non-negotiables that you have to adhere to, fine. But you know that your ultimate goal is, we're going to ship particular time, particular way, ability to support whatever we're building. I think if you can reach that goal, it's okay to have that variability. I didn't know that when I first started my career. Like I said, I learned the hard way, but I think if you allow people to evolve and run their teams the way they want to, you're going to have a smoother running organization.
Ganesh Datta:
That makes sense. And I would assume as well, if you are trying to change the global culture of the organization, having some teams that are operating differently may give you the opportunity to showcase or use some teams as examples of the new culture that you're trying to create, and maybe gives you a bit more flexibility to produce that culture across the org.
Jeff Schnitter:
Yeah. That was one of the things that was really appealing when you and Cortex came in to talk to us about the tooling that you were building. Gamification was really interesting to me, because that's kind of that topic that you're talking about. It's how can other teams perhaps operate differently? I'm using a different GIT tool. I'm using a different review tool. Everyone had different types of tools that they wanted to use, but who's going to get there faster? Who's going to get there with better quality? Instead of me trying to fight that standardization problem, allow these teams to run independently, improve through data, through gamification, what works better.
Ganesh Datta:
That makes sense. Let's shift gears to talk about changing culture now. You mentioned culture is a lot about focusing on outcomes. Is that where you would start if you wanted to change the culture in an organization? Do you change the outcome that you're driving towards? Where do you even start?
Jeff Schnitter:
I like to center on the problem. So it's not always outcome-based for me. It's going to lead to an outcome. But when I talk to prospects, when I talk to customers, I always want to ask them, "What's the business problem you're trying to solve?" Now, inevitably it'll have an outcome attached to it, but I think when people start to talk about pain, then you can talk about the types of things that you want to implement that will help it. I always want to start with the pain. Let's just talk about that before you jump into solutioning.
Ganesh Datta:
Because people understand what pain they have. You can then get them to articulate what it's preventing them from accomplishing, and that becomes the outcome in some way.
Jeff Schnitter:
Everybody has pain. It's interesting. It is really interesting to talk to people about the issues that they're facing. You can just ask them that single question. "What is a part of developer friction that exists in your organization?" I get smirks, people laughing, because they know it. They internalize it, and it's frustrating. And so, they really are looking for ways that they can combat that. And I think that's where you start with that question, the responses that you get, and that's going to lead ultimately to the outcomes.
Ganesh Datta:
Maybe this is a crude way of describing it, but it feels sometimes that organizations have Stockholm Syndrome. They know they have pain, but they're like, "This is great. This is totally fine." So how do you convince them that that pain is not good, that they should do something about that pain?
Jeff Schnitter:
That's a great way to put it. I think that when new people join an organization, I'm not quite answering your question yet, they're very valuable, because they see a team, an organization, rituals, tools, through a new lens. And you're often never more valuable than you are when you first start, because you're going to come in and question things. They don't have the Stockholm Syndrome yet because they haven't been there long enough.
And you need someone to question. You need people to stand up and ask those questions, "Why are we doing it this way? Why are we having the problems that we have?" I'm sure you've probably worked places where people say, "Yep, that error is normal. You just overlook that. That's just the way it is." And you got to avoid that, like, okay, these are the things that I'll deal with to get past that.
So it's not easy, but you have to question everything that you do all the time. Earlier, we talked about orgs always morphing. They're always changing. People have to be willing to stand up and say, "Why are we doing things this way?"
Ganesh Datta:
You see this in startups sometimes. Some of the most interesting startups are built by outsiders for the same reason, I think. It's like, they go in and they're like, "This can't be the way things are done. There must be a better way." And sometimes you learn, no, there's a good reason for it, but we can do it better and iterate on it. But I think it's a very similar paradigm that we're seeing there.
But I guess, okay, so now you have an outsider that's coming in and say, "Okay, the way we're doing things sucks, because I haven't lived like this before and this is really painful." How do they now go and convince the other people that like, "Hey, you should not be living like this. There is a better way to live." How do you do that?
Jeff Schnitter:
That's why I start with the pain. What is your individual pain?
Ganesh Datta:
Yeah.
Jeff Schnitter:
And I want to address it that way. I want to collect all the data from the people that I talk to. We talk a lot about carrot and the stick, and I am not a big fan of the stick. I am not a big fan of telling people what they should do, telling them it's good for you.
I'll give you an example. Growing up, mom always said, "Brush your teeth." I'm like, "I don't know if I'm going to brush my teeth." I now pay my own dental bills, okay? So I understand why I should brush my teeth myself, not because someone's telling me. I'm not super incentivized that way. And that's why I want to start with the incentives that the people who are going to be implementing those things that you're talking about, how they're going to be able to reap the rewards of that.
Ganesh Datta:
That's a really interesting point. You touched on something I wanted to ask about, which is, how do incentives play into this? So now, we talked about individual pain. How does an organization incentivize them to fix that pain? Why would I want to do something that maybe is a different team's pain, or a different person on my team's pain? How do you design these incentive structures the right way?
Jeff Schnitter:
I think you have to design the process correctly.
Ganesh Datta:
Okay.
Jeff Schnitter:
One way that I think about it is ownership of a service, let's say. You've seen cases where you own a service and then maybe you throw it over the wall. DevOps owns it. They have to deploy it. The team that builds it is not necessarily incentivized to make sure that it's an efficient deploy or easily supported after it's deployed, taken a look at initial issues that might roll out.
So, you might take a look at your process and decide that I want a team to own the service from design to deploy. A team that has ownership all the way through will be fully incentivized to build better processes, to make sure that things work all the way through each part of the deployment process.
Ganesh Datta:
Do things like metrics or SLOs or things like that play a role here?
Jeff Schnitter:
They have to. They have to. I mean, you want to make sure that you're getting the signals that are important to take a look at and measure to prepare and prevent for things that might be happening. So, you're inundated with data. You have to take a look at the data. I think the key way that I would look at it is to look at the right things, measure what matters, so you can react to it. Because you'll run into another problem where you've got too much data, and then what do you do? You have to work through the weeds.
Ganesh Datta:
That makes sense. You mentioned earlier, compliance being an interesting use case, or a cultural value. Would you think about compliance issues or vulnerabilities being the metric? What is a metric that can trickle down all the way to an individual team that then changes their own culture to reflect that outcome?
Jeff Schnitter:
I'm often thinking about what is something catastrophic that's going to happen. So what if I have a compliance issue that gets out into the wild? That's a metric that I'm going to want to be able to measure, a vulnerability that gets out to public, because I need to be able to prevent those. So I'm always thinking about perhaps the worst case that can happen, and think about how can I catch and measure that worst case? So I guess I'm looking for things in my pipeline, as it's being developed, to try to catch those things. So the SLOs, the vulnerabilities, any of the issues that you might find, I want to find them earlier.
Ganesh Datta:
Kind of expand the scope a little bit now. So we talked about the individual pain, the culture of an individual team, but in many cases, you need multiple teams to come together to create that change. Either you are blocked by a different team or you need multiple teams to adopt a new way of working so that that will then trickle down to the rest of your organization. How do you get other teams on board, just all your own pain or their own pain?
Jeff Schnitter:
I think you have to figure out a way to figure out that incentivization problem that exists within the team, and figure out whatever that overlap is. Both teams have to be incentivized. If we work on this together, if we have a solution that we can work on together, Team B, you're going to have fewer incidents. Team A, you're going to have fewer opportunities where you're going to have to redesign or rewrite.
So you have to find out, I think, where the shared pain point is. It's probably a Venn diagram that you're trying to take a look at. Again, not saying that it's easy, but both teams have to be incentivized. It's kind of a human problem that you're dealing with. Why am I going to do something that doesn't ultimately benefit me? You like to think that you're altruistic, but I think it's just the things that are driving you to do the things that you have to do.
Ganesh Datta:
And this sounds very much like the tech debt problem, which is why should I prioritize this massive tech debt thing when I'm also getting pressure for other features, or this other team is the one that's relying on our service and that's their problem if our service sucks to some degree. And so, it sounds very much like a tech debt problem. And I think what you're hinting at is, you want to be able to tie that back to something that that team cares about as well, which is, can you show immediate value? You're going to spend less time on the annoying parts of your work, or something like that. So it sounds like there's a lot of overlap with how companies should think about that from their own technical platform issues, as well.
Jeff Schnitter:
You have to design your process such that your IDP can help address that problem. I talk to engineers all the time. Why should I work on tech debt when I have to get this feature done by this time? That's what I'm being graded on. So I think you also have to grade on the tech debt, and it's not an easy thing to do. How do you grade against that? Is it number of issues, number of vulnerabilities?
People know that they've got ticking time bombs sitting in the code base. They know it, and they're trying to balance, well, I've got to get these features out. I have to get to the market faster than my competitor. And you always seem to push it off. You push it off. And a lot of times it reaches a crescendo. We know we are in such a big problem right now.
I've seen companies that will put a pause. Three months, we're doing nothing but cleaning up this tech debt, which is a really hard thing to say and to sell. You're setting yourself up for the future. It's saving your money and spending it all as soon as you get it.
Ganesh Datta:
Should you optimize for big swings like that, where it's like, hey, we're going to solve the biggest thing all at once. We're going to spend three months doing it. Or do you start with something small? What has a higher impact on being able to change culture?
Jeff Schnitter:
You got to start small. You got to prove that you can make the types of changes that you're talking about. Now, you can say it's a good idea to take a three-month pause and we're going to fix everything. What if you don't finish it? That's a horrible idea, then. You've bitten off something way too big, and now it's even worse, right? Maybe you get halfway through fixing that big thing and then you say, "Oh, that's a bad idea. Let's keep going." And now you've doubled your tech debt.
So I say you have to build out the rituals, you have to prove that you can do it. People will believe and buy in. I really think that software and development, as crazy as it sounds, is more of a faith-based business than a tech business, because you have to prove to your engineers, they believe in you. They believe in the org, they believe in the processes. Then they'll do it again. Sure, you can manage with data, you can show them numbers, you can show them all of that. You talk to anybody, and it's what's in the heart, and that's what they're going to do. So I would never go big. I'm always going to start small. You start to prove out the little wins, people start to believe, and then you go from there.
Ganesh Datta:
The corollary to that is probably the importance of celebrating wins. So let's talk about that a little bit. When do you celebrate wins? Is there a stage you should do that at? How much should you celebrate those wins? Does that play a role in changing culture?
Jeff Schnitter:
I think it does. And you got to be careful. There's a balance. You can't celebrate every PR. You can't celebrate, I just did a commit. Although I tell my mom after I did stuff like that. But I think that you balance the wins with the work. So you got to put in the time, and you want to be rewarded for doing a good amount of work, and then I think you reward it. If you're always complimenting people, if everybody's always winning... I know people like to say everybody shouldn't get a trophy. If you do that, you lessen the message that you're putting out there when somebody wins.
So I think you look for key things that the organization has agreed on are key deliverables, and then you hit those deliverables. It's not just, "Hey, I did three week sprint and had no bugs or anything like that." That doesn't prove value. Show value. Teams will get behind that. Teams will get incentivized because they want to be recognized as well.
Ganesh Datta:
That makes sense. You mentioned a couple times the importance of messaging. So I want to talk about that from a leader's perspective. What is a leader's role in an engineering organization when it comes to changing culture? What messaging do they own? What kind of stories do they need to tell? Starting from the very beginning of this process to the wins, what is their role in all of this?
Jeff Schnitter:
They have to have buy-in from the beginning, and they have to sell it that they're behind the initiative. I've seen these things fail a lot when it's a groundswell. It's built from the bottom up, and the engineering leader might hear about it, but they're never professing what's being done. So I think it starts with the engineering leader talking about the goal, what they're trying to achieve, why they're doing it. And then a great leader, I think, gets out of the way. They allow their teams to do the work that they need to do, and then they'll come back from time to time.
You mentioned the wins. I think that leader has to talk about the progress. They have to talk about what's going on, celebrate some of those small milestones along the way. I liken it to a basketball coach. A really good basketball coach is doing his work at practice. When he's on the sidelines, he shouldn't be screaming and hollering, because he trusts his team to do the work that they need to do. Same thing with an engineering leader. This is what we're going to do. You have those discussions. Stand out of the way. Don't holler from the sideline, and allow those rituals to show the progress that's being made.
Ganesh Datta:
No broken clipboards on this.
Jeff Schnitter:
Easier said than done.
Ganesh Datta:
No, absolutely. Let's talk about reliability as a specific, maybe, use case for all of this. The culture of reliability I think is really interesting, because it's something that a lot of organizations understand, but maybe don't have. But most organizations aspire to. Maybe there's some organizations that really don't care and just want to ship fast, but most organizations care about reliability to some degree. Is there any particular advice you would share for cultural change, specifically when it comes to reliability?
Jeff Schnitter:
I love reliability. I love reliability. Now, I'm in DevX. I work with customers. I'm a solution architect, so I'm not developing a lot myself, but I think it is important to think like a developer and be a developer.
When I joined Cortex, I wrote a command line interface, and I'm not the greatest programmer. I shouldn't tell you that live on the podcast, but too bad. It's written in Python. And one of the things that I wanted to feel when I was developing it is that I want to have confidence when I make a change, I haven't broken anything. So key to me was the test suite. When I make a change, I want to make a commit, fully automated tests so that I don't have to worry that, what's going to happen. This is going to have a big impact to people.
So I can at least think like a developer. That's my mindset. And so, when it comes to reliability, I want to have a high degree of confidence when I make a change that I'm not impacting my system somewhere. The bigger the system, the bigger organization, you often don't know where you might have a vulnerability. You might have a connection that you're not even aware of.
So my key is, I want to be able to work with teams that can make changes, and not be worried, is it okay that we touch this part of the code? Is it going to be all right that we roll this out on a Friday afternoon? Do we have any concerns about it? And so, it's a lot like the basketball coach analogy. You do the hard work. It's the testing, it's the planning, it's the design, such that once you do make those changes, you feel comfortable about them. You're not worried about them.
If you've ever worked someplace where you say, "Don't touch the code," or, "We can't do a deploy. We don't trust it." Again, it comes back to that faith-based idea that I'm talking about, that if your teams don't believe in the work that you're doing, you're going to start to have a culture of fear, which is going to be detrimental.
Ganesh Datta:
It sounds like one of the things that, if I had to distill that idea, is this idea of a shared concept of what good looks like. You mentioned things like we're not scared to deploy, we have good test coverage. These are all things that maybe an organization needs to come together and say, "These are things that we define to be good. This is what good looks like." Would you agree with that? Do you think having a shared definition of good is important? How does that play a role in culture?
Jeff Schnitter:
I think so, because there's some norms that we should accept, and I think we do. How many vulnerabilities? How many rollbacks? How many failed deploys? We have some pretty standard metrics that we can talk about. There's a lot of different ways to get to good, but I think that shared definition of what it looks like, I think we have an idea, again, in here of what it feels like. I'm not going to get a ping at 3:00 in the morning. I feel okay about doing my deploy. I'm not worried about an end of life service all of a sudden being gone. Having confidence in the stuff that you're building and deploying, and not having that fear. So I think the shared definition is a good thing.
Ganesh Datta:
Can that be automated? How do you drive visibility in that shared definition of good? Is that the leader's responsibility to talk about that? Like you mentioned at the beginning, giving visibility into it. Is it shifting left and making that visible at the time of PR? What does that mean for practical purposes?
Jeff Schnitter:
That's a great question. Honestly, I think that's why I joined Cortex, because I don't know if we can solve that problem. I want to get closer to being able to solve that problem. In my experience, I knew I wanted to automate it, but there were so many manual touchpoints. There were so many manual attestations. "Hey, team, do you have a good load test? Do you have great performance tests?" It's hard to automate.
I'm not saying it's not possible, but the way that I've thought about that problem is, what are all the things that I have to do? What is a golden path? How do I get to production readiness? How many of those things can I automate? I think, can I fully automate it? Never say never.
Ganesh Datta:
It's hard.
Jeff Schnitter:
Never say never. It's software. So, I think it's possible. It's probably an 80/20 rule. There's a lot of them in software. I'm going to take the 80% that are easy. I think you can automate those. And then I'd love to get to the point where I've automated all of those, so that I can work on the hard parts.
Ganesh Datta:
That's really interesting. Obviously, you mentioned in your past you've done things like test automation and rolling those kinds of things out across the organization. How did you get people to adopt it? Walk us through a war story.
Jeff Schnitter:
Oh, man. I think they're all war stories. Well, I'm trying to figure out if I have major successes, because I think they all had certain roadblocks, or they ran into problems as you rolled them out, that they weren't complete because the technology was changing.
A good example probably was when I was at Workday, they were trying to break out a monolith into microservices. Now, it wasn't necessarily something that I was driving. Everyone was behind it, because... Well, this is another not proud moment of my career, but I started as a build engineer. The build took about a minute when I started. After about 10 years, it took like an hour and a half, under my watch. So, well done.
And the problem was, it was getting more and more complex. We were always looking for places where we could trim time and make it run faster. Everyone thought, let's break out the monolith. Let's get these microservices out. You'll have these builds that are 90 seconds, but you can horizontally scale them. No problem. We'll get back to the time when I first started.
Well, we got about a third of the way through breaking out the monolith, but there's certain parts that are so hard to break out. Now you're halfway through that and you're like, I'm not sure if we're going to be able to complete this. So you're going to move on to the next thing that you try to do. So honestly, most efforts, I think, ended with like, 75% or 80% completion. So they're all war stories.
Ganesh Datta:
Do you think that 80/20 rule applies there? Was that good enough?
Jeff Schnitter:
I don't think so, but yes. I worked at a super successful company.
Ganesh Datta:
Yeah.
Jeff Schnitter:
Super successful. Now, was 80% good enough? For sure. Workday is a fantastic company, really profitable. But if you talk to Workday engineers, they're going to know right again, here, what are the problems? What are the things that you're trying to deal with? It's that same morphing that I talked about. The morph of a one-minute build to an hour and a half, partially breaking up the monolith into microservices. There's so many of these things that you have to deal with.
Ultimately, if you're talking about success of a company, 80% is good enough. It's not good enough for me. I want it to be better, and then it's just picking and choosing. Where am I going to try to look at some of those failed projects or partially completed projects? I never want to stop. I think the North Star should be 100%. 80% is good enough, and so maybe you can measure to that. I'm always going to aim for 100%. I know it's a little bit corny. Shoot for the moon. If you don't make it, you can land in the stars.
Ganesh Datta:
Absolutely. Now, we talked about your role helping customers and organizations drive this kind of change and adopt new capabilities. If you had a chief of staff who could help you with this role, what would that chief of staff do for you?
Jeff Schnitter:
I would love to ask the chief of staff, "Where should I be concerned? Where do I have potential problems?" I don't want to be dealing with things retroactively like, "Oh, great. We can fail fast and I'm going to fix some vulnerability." I want to ask that chief of staff, "Take a look at my ecosystem. What's going on? Where should I be concerned six months from now?" Another sports analogy, if you'll bear with me.
Ganesh Datta:
I love it.
Jeff Schnitter:
A quarterback's got to throw to where the wide receiver's going to be. You don't throw where they're at. And so when I think about working with an organization, working with software, where is that evolution, which is constant? Where are we going to be in six months?
Ganesh Datta:
Yeah.
Jeff Schnitter:
I don't want to be reactive in six months. I want to be throwing the ball to that point. That's what I want to ask my chief of staff.
Ganesh Datta:
I love that. Being proactive, rather than reactive. Well, thank you so much for being on the podcast. Just to summarize, when you're trying to change the culture of an organization, you want to start with pain, what sucks right now. Maybe get an outsider's perspective. Go from that pain to outcomes, like what is this going to do for me? What is it going to do for my team? Create visibility, get leadership buy-in, have the leaders tell those stories, have the team tell those stories, celebrate those wins incrementally. Anything else you would add to that?
Jeff Schnitter:
Iterate. Rinse and repeat, because it's going to change. Whatever those wins were, the organization's going to morph, and because you've done it before, you know you can do it again, and you're ready to go.
Ganesh Datta:
So much insight there. Well, thanks so much for joining me on the podcast. It was great having you.
Jeff Schnitter:
Thanks for having me.
Ganesh Datta:
Thanks so much for listening to this episode of Braintrust. If this resonated with you, do me a favor. Share it with another engineering leader who's wrestling with these same challenges. And if you want to continue the conversation or learn more about how we're thinking about internal developer portals at Cortex, reach out to us at cortex.io. Thanks for listening, and we'll catch you on the next one.
I liken it to a basketball coach. A really good basketball coach is doing his work at practice. When he's on the sidelines, he shouldn't be screaming and hollering, because he trusts his team to do the work that they need to do. Same thing with an engineering leader. This is what we're going to do. You have those discussions. Stand out of the way. Don't holler from the sideline, and allow those rituals to show the progress that's being made.
Ganesh Datta:
You're listening to Braintrust by Cortex, where we explore how engineering leaders blend AI, platforms, and culture to build high performing software teams. I'm your host, Ganesh Datta, CTO and co-founder of Cortex, an internal developer portal designed to help engineering teams ship reliable software faster with AI. In each episode, we go deep with CTOs, VPs of engineering, and technical leaders who have been in the trenches, navigating the tension between speed and quality, building reliability at scale, and figuring out how to lead through major platform shifts. Whether you're running a team of 10 or 1,000, this is your space to learn from people who have made the hard calls and lived to talk about it.
Hey, welcome to the podcast. I'm Ganesh. I'm the co-founders and CTO at Cortex. You want to introduce yourself real quick?
Jeff Schnitter:
Yeah. Hey, Ganesh. I'm Jeff Schnitter. I'm a solution architect at Cortex, as you know. You and I met, I was a customer of Cortex at Workday, where I worked in developer experience, developer productivity, release engineering, test automation, those types of areas.
Ganesh Datta:
Thanks so much for joining the podcast today.
Jeff Schnitter:
Thanks for having me.
Ganesh Datta:
Well, today I want to talk about a very broad topic, which is how do you change the culture of an organization? And I think this topic is really interesting today because a lot of organizations are thinking about this, particularly from the lens of AI, which is how do we adopt more AI? How do we get our organization to think about it? But we see this happen a lot with other things as well. We want to create a culture of reliability. We want to create a culture of security, of shipping fast, of quality, all these kinds of things.
And so, this idea of changing culture I think is really interesting, and it's one that's not really talked about a lot. And so, in your role, you've had the opportunity to really think about, how do you change the culture of an organization? How do you shift it to something that hasn't really been done before? And so that's what I want to spend some time talking about today.
Jeff Schnitter:
Yeah, I love talking about it.
Ganesh Datta:
All right. Well, maybe at the very top, how would you define culture? How does it play out? Because I think we need to start there before we can talk about how to change it.
Jeff Schnitter:
Yeah. I think when I think about culture, it is about the attitude that the organization has about addressing those problems. Are people aligned to solve the same types of problems in the same types of ways? Because if you're not aligned culturally, it's going to make it very difficult to implement the type of change that you want.
Ganesh Datta:
That's really interesting. Yeah. The one that I've heard is, how do people behave when you're not in the room? As a leader in particular, if you're there, you make a certain type of decision. If you're not there, does the organization do it the same way? And I think that's a more leadership-oriented version of that same thing, but I think it touches on the same concept, which is the behaviors, the attitude, the way the organization thinks. Why do you think different organizations have different cultures?
Jeff Schnitter:
I think they have different motivations. Is security the key thing? In my background, we were a key HR application running in the cloud. Zero reportable security vulnerabilities. That was core to everything that we did. Every ritual, every meeting that we had, we started off with zero vulnerabilities. We were all about security.
I think other organizations, as I've got to know them, it's about shipping faster. Maybe you're out in the commerce industry, you got to get to market faster, you're fighting other competition. So I think, depending on where your focus is, you're going to have a different type of culture.
Ganesh Datta:
Why would an organization want to change their culture?
Jeff Schnitter:
They know that they have problems. I think every organization wants to change their culture because they see little problems that creep in. The interesting thing about software and organizations is they're so organic. They're never the same day-to-day. It's a constantly evolving thing. So what might've been your culture a couple months ago, a year ago, it morphs into something else requiring change. And so I think it's this constant analysis that you have to take a look at. How do I need to run my business?
Ganesh Datta:
In your experience, have you seen the culture of an organization reflect all the way through, or do you think different teams have different cultures, and are those things in conflict at times?
Jeff Schnitter:
I think they're always in conflict, because I like your analogy about how do you act when no one else is in the room? How do you manage things? I think different teams are going to organize in a different way. They're going to operate in a different way. Now, you might have rituals that you meet every quarter, maybe every six months, your all-hands. You're getting the messaging, but it doesn't always permeate throughout the course of the year. So I think there's a little bit of variance that you're going to see as each team operates, because they operate individually and then they'll come together only from time to time. And so, that's where you start to see things fall apart, where teams aren't all operating underneath that same umbrella of the things that you're trying to achieve.
Ganesh Datta:
Can it be a good thing if some teams don't have the same culture as the broader organization?
Jeff Schnitter:
I think absolutely. Because this is a battle I've fought in the past. I thought you got to standardize, use the same tools, everybody do the same thing. And I learned really the hard way, that you don't tell people the way that they should run the business, the tools that they should use. And I realized that the outcome should be the key that you're looking at. Now, how you get there might vary a little bit. That might have some variability in the culture, as well. If you agree that there are some non-negotiables that you have to adhere to, fine. But you know that your ultimate goal is, we're going to ship particular time, particular way, ability to support whatever we're building. I think if you can reach that goal, it's okay to have that variability. I didn't know that when I first started my career. Like I said, I learned the hard way, but I think if you allow people to evolve and run their teams the way they want to, you're going to have a smoother running organization.
Ganesh Datta:
That makes sense. And I would assume as well, if you are trying to change the global culture of the organization, having some teams that are operating differently may give you the opportunity to showcase or use some teams as examples of the new culture that you're trying to create, and maybe gives you a bit more flexibility to produce that culture across the org.
Jeff Schnitter:
Yeah. That was one of the things that was really appealing when you and Cortex came in to talk to us about the tooling that you were building. Gamification was really interesting to me, because that's kind of that topic that you're talking about. It's how can other teams perhaps operate differently? I'm using a different GIT tool. I'm using a different review tool. Everyone had different types of tools that they wanted to use, but who's going to get there faster? Who's going to get there with better quality? Instead of me trying to fight that standardization problem, allow these teams to run independently, improve through data, through gamification, what works better.
Ganesh Datta:
That makes sense. Let's shift gears to talk about changing culture now. You mentioned culture is a lot about focusing on outcomes. Is that where you would start if you wanted to change the culture in an organization? Do you change the outcome that you're driving towards? Where do you even start?
Jeff Schnitter:
I like to center on the problem. So it's not always outcome-based for me. It's going to lead to an outcome. But when I talk to prospects, when I talk to customers, I always want to ask them, "What's the business problem you're trying to solve?" Now, inevitably it'll have an outcome attached to it, but I think when people start to talk about pain, then you can talk about the types of things that you want to implement that will help it. I always want to start with the pain. Let's just talk about that before you jump into solutioning.
Ganesh Datta:
Because people understand what pain they have. You can then get them to articulate what it's preventing them from accomplishing, and that becomes the outcome in some way.
Jeff Schnitter:
Everybody has pain. It's interesting. It is really interesting to talk to people about the issues that they're facing. You can just ask them that single question. "What is a part of developer friction that exists in your organization?" I get smirks, people laughing, because they know it. They internalize it, and it's frustrating. And so, they really are looking for ways that they can combat that. And I think that's where you start with that question, the responses that you get, and that's going to lead ultimately to the outcomes.
Ganesh Datta:
Maybe this is a crude way of describing it, but it feels sometimes that organizations have Stockholm Syndrome. They know they have pain, but they're like, "This is great. This is totally fine." So how do you convince them that that pain is not good, that they should do something about that pain?
Jeff Schnitter:
That's a great way to put it. I think that when new people join an organization, I'm not quite answering your question yet, they're very valuable, because they see a team, an organization, rituals, tools, through a new lens. And you're often never more valuable than you are when you first start, because you're going to come in and question things. They don't have the Stockholm Syndrome yet because they haven't been there long enough.
And you need someone to question. You need people to stand up and ask those questions, "Why are we doing it this way? Why are we having the problems that we have?" I'm sure you've probably worked places where people say, "Yep, that error is normal. You just overlook that. That's just the way it is." And you got to avoid that, like, okay, these are the things that I'll deal with to get past that.
So it's not easy, but you have to question everything that you do all the time. Earlier, we talked about orgs always morphing. They're always changing. People have to be willing to stand up and say, "Why are we doing things this way?"
Ganesh Datta:
You see this in startups sometimes. Some of the most interesting startups are built by outsiders for the same reason, I think. It's like, they go in and they're like, "This can't be the way things are done. There must be a better way." And sometimes you learn, no, there's a good reason for it, but we can do it better and iterate on it. But I think it's a very similar paradigm that we're seeing there.
But I guess, okay, so now you have an outsider that's coming in and say, "Okay, the way we're doing things sucks, because I haven't lived like this before and this is really painful." How do they now go and convince the other people that like, "Hey, you should not be living like this. There is a better way to live." How do you do that?
Jeff Schnitter:
That's why I start with the pain. What is your individual pain?
Ganesh Datta:
Yeah.
Jeff Schnitter:
And I want to address it that way. I want to collect all the data from the people that I talk to. We talk a lot about carrot and the stick, and I am not a big fan of the stick. I am not a big fan of telling people what they should do, telling them it's good for you.
I'll give you an example. Growing up, mom always said, "Brush your teeth." I'm like, "I don't know if I'm going to brush my teeth." I now pay my own dental bills, okay? So I understand why I should brush my teeth myself, not because someone's telling me. I'm not super incentivized that way. And that's why I want to start with the incentives that the people who are going to be implementing those things that you're talking about, how they're going to be able to reap the rewards of that.
Ganesh Datta:
That's a really interesting point. You touched on something I wanted to ask about, which is, how do incentives play into this? So now, we talked about individual pain. How does an organization incentivize them to fix that pain? Why would I want to do something that maybe is a different team's pain, or a different person on my team's pain? How do you design these incentive structures the right way?
Jeff Schnitter:
I think you have to design the process correctly.
Ganesh Datta:
Okay.
Jeff Schnitter:
One way that I think about it is ownership of a service, let's say. You've seen cases where you own a service and then maybe you throw it over the wall. DevOps owns it. They have to deploy it. The team that builds it is not necessarily incentivized to make sure that it's an efficient deploy or easily supported after it's deployed, taken a look at initial issues that might roll out.
So, you might take a look at your process and decide that I want a team to own the service from design to deploy. A team that has ownership all the way through will be fully incentivized to build better processes, to make sure that things work all the way through each part of the deployment process.
Ganesh Datta:
Do things like metrics or SLOs or things like that play a role here?
Jeff Schnitter:
They have to. They have to. I mean, you want to make sure that you're getting the signals that are important to take a look at and measure to prepare and prevent for things that might be happening. So, you're inundated with data. You have to take a look at the data. I think the key way that I would look at it is to look at the right things, measure what matters, so you can react to it. Because you'll run into another problem where you've got too much data, and then what do you do? You have to work through the weeds.
Ganesh Datta:
That makes sense. You mentioned earlier, compliance being an interesting use case, or a cultural value. Would you think about compliance issues or vulnerabilities being the metric? What is a metric that can trickle down all the way to an individual team that then changes their own culture to reflect that outcome?
Jeff Schnitter:
I'm often thinking about what is something catastrophic that's going to happen. So what if I have a compliance issue that gets out into the wild? That's a metric that I'm going to want to be able to measure, a vulnerability that gets out to public, because I need to be able to prevent those. So I'm always thinking about perhaps the worst case that can happen, and think about how can I catch and measure that worst case? So I guess I'm looking for things in my pipeline, as it's being developed, to try to catch those things. So the SLOs, the vulnerabilities, any of the issues that you might find, I want to find them earlier.
Ganesh Datta:
Kind of expand the scope a little bit now. So we talked about the individual pain, the culture of an individual team, but in many cases, you need multiple teams to come together to create that change. Either you are blocked by a different team or you need multiple teams to adopt a new way of working so that that will then trickle down to the rest of your organization. How do you get other teams on board, just all your own pain or their own pain?
Jeff Schnitter:
I think you have to figure out a way to figure out that incentivization problem that exists within the team, and figure out whatever that overlap is. Both teams have to be incentivized. If we work on this together, if we have a solution that we can work on together, Team B, you're going to have fewer incidents. Team A, you're going to have fewer opportunities where you're going to have to redesign or rewrite.
So you have to find out, I think, where the shared pain point is. It's probably a Venn diagram that you're trying to take a look at. Again, not saying that it's easy, but both teams have to be incentivized. It's kind of a human problem that you're dealing with. Why am I going to do something that doesn't ultimately benefit me? You like to think that you're altruistic, but I think it's just the things that are driving you to do the things that you have to do.
Ganesh Datta:
And this sounds very much like the tech debt problem, which is why should I prioritize this massive tech debt thing when I'm also getting pressure for other features, or this other team is the one that's relying on our service and that's their problem if our service sucks to some degree. And so, it sounds very much like a tech debt problem. And I think what you're hinting at is, you want to be able to tie that back to something that that team cares about as well, which is, can you show immediate value? You're going to spend less time on the annoying parts of your work, or something like that. So it sounds like there's a lot of overlap with how companies should think about that from their own technical platform issues, as well.
Jeff Schnitter:
You have to design your process such that your IDP can help address that problem. I talk to engineers all the time. Why should I work on tech debt when I have to get this feature done by this time? That's what I'm being graded on. So I think you also have to grade on the tech debt, and it's not an easy thing to do. How do you grade against that? Is it number of issues, number of vulnerabilities?
People know that they've got ticking time bombs sitting in the code base. They know it, and they're trying to balance, well, I've got to get these features out. I have to get to the market faster than my competitor. And you always seem to push it off. You push it off. And a lot of times it reaches a crescendo. We know we are in such a big problem right now.
I've seen companies that will put a pause. Three months, we're doing nothing but cleaning up this tech debt, which is a really hard thing to say and to sell. You're setting yourself up for the future. It's saving your money and spending it all as soon as you get it.
Ganesh Datta:
Should you optimize for big swings like that, where it's like, hey, we're going to solve the biggest thing all at once. We're going to spend three months doing it. Or do you start with something small? What has a higher impact on being able to change culture?
Jeff Schnitter:
You got to start small. You got to prove that you can make the types of changes that you're talking about. Now, you can say it's a good idea to take a three-month pause and we're going to fix everything. What if you don't finish it? That's a horrible idea, then. You've bitten off something way too big, and now it's even worse, right? Maybe you get halfway through fixing that big thing and then you say, "Oh, that's a bad idea. Let's keep going." And now you've doubled your tech debt.
So I say you have to build out the rituals, you have to prove that you can do it. People will believe and buy in. I really think that software and development, as crazy as it sounds, is more of a faith-based business than a tech business, because you have to prove to your engineers, they believe in you. They believe in the org, they believe in the processes. Then they'll do it again. Sure, you can manage with data, you can show them numbers, you can show them all of that. You talk to anybody, and it's what's in the heart, and that's what they're going to do. So I would never go big. I'm always going to start small. You start to prove out the little wins, people start to believe, and then you go from there.
Ganesh Datta:
The corollary to that is probably the importance of celebrating wins. So let's talk about that a little bit. When do you celebrate wins? Is there a stage you should do that at? How much should you celebrate those wins? Does that play a role in changing culture?
Jeff Schnitter:
I think it does. And you got to be careful. There's a balance. You can't celebrate every PR. You can't celebrate, I just did a commit. Although I tell my mom after I did stuff like that. But I think that you balance the wins with the work. So you got to put in the time, and you want to be rewarded for doing a good amount of work, and then I think you reward it. If you're always complimenting people, if everybody's always winning... I know people like to say everybody shouldn't get a trophy. If you do that, you lessen the message that you're putting out there when somebody wins.
So I think you look for key things that the organization has agreed on are key deliverables, and then you hit those deliverables. It's not just, "Hey, I did three week sprint and had no bugs or anything like that." That doesn't prove value. Show value. Teams will get behind that. Teams will get incentivized because they want to be recognized as well.
Ganesh Datta:
That makes sense. You mentioned a couple times the importance of messaging. So I want to talk about that from a leader's perspective. What is a leader's role in an engineering organization when it comes to changing culture? What messaging do they own? What kind of stories do they need to tell? Starting from the very beginning of this process to the wins, what is their role in all of this?
Jeff Schnitter:
They have to have buy-in from the beginning, and they have to sell it that they're behind the initiative. I've seen these things fail a lot when it's a groundswell. It's built from the bottom up, and the engineering leader might hear about it, but they're never professing what's being done. So I think it starts with the engineering leader talking about the goal, what they're trying to achieve, why they're doing it. And then a great leader, I think, gets out of the way. They allow their teams to do the work that they need to do, and then they'll come back from time to time.
You mentioned the wins. I think that leader has to talk about the progress. They have to talk about what's going on, celebrate some of those small milestones along the way. I liken it to a basketball coach. A really good basketball coach is doing his work at practice. When he's on the sidelines, he shouldn't be screaming and hollering, because he trusts his team to do the work that they need to do. Same thing with an engineering leader. This is what we're going to do. You have those discussions. Stand out of the way. Don't holler from the sideline, and allow those rituals to show the progress that's being made.
Ganesh Datta:
No broken clipboards on this.
Jeff Schnitter:
Easier said than done.
Ganesh Datta:
No, absolutely. Let's talk about reliability as a specific, maybe, use case for all of this. The culture of reliability I think is really interesting, because it's something that a lot of organizations understand, but maybe don't have. But most organizations aspire to. Maybe there's some organizations that really don't care and just want to ship fast, but most organizations care about reliability to some degree. Is there any particular advice you would share for cultural change, specifically when it comes to reliability?
Jeff Schnitter:
I love reliability. I love reliability. Now, I'm in DevX. I work with customers. I'm a solution architect, so I'm not developing a lot myself, but I think it is important to think like a developer and be a developer.
When I joined Cortex, I wrote a command line interface, and I'm not the greatest programmer. I shouldn't tell you that live on the podcast, but too bad. It's written in Python. And one of the things that I wanted to feel when I was developing it is that I want to have confidence when I make a change, I haven't broken anything. So key to me was the test suite. When I make a change, I want to make a commit, fully automated tests so that I don't have to worry that, what's going to happen. This is going to have a big impact to people.
So I can at least think like a developer. That's my mindset. And so, when it comes to reliability, I want to have a high degree of confidence when I make a change that I'm not impacting my system somewhere. The bigger the system, the bigger organization, you often don't know where you might have a vulnerability. You might have a connection that you're not even aware of.
So my key is, I want to be able to work with teams that can make changes, and not be worried, is it okay that we touch this part of the code? Is it going to be all right that we roll this out on a Friday afternoon? Do we have any concerns about it? And so, it's a lot like the basketball coach analogy. You do the hard work. It's the testing, it's the planning, it's the design, such that once you do make those changes, you feel comfortable about them. You're not worried about them.
If you've ever worked someplace where you say, "Don't touch the code," or, "We can't do a deploy. We don't trust it." Again, it comes back to that faith-based idea that I'm talking about, that if your teams don't believe in the work that you're doing, you're going to start to have a culture of fear, which is going to be detrimental.
Ganesh Datta:
It sounds like one of the things that, if I had to distill that idea, is this idea of a shared concept of what good looks like. You mentioned things like we're not scared to deploy, we have good test coverage. These are all things that maybe an organization needs to come together and say, "These are things that we define to be good. This is what good looks like." Would you agree with that? Do you think having a shared definition of good is important? How does that play a role in culture?
Jeff Schnitter:
I think so, because there's some norms that we should accept, and I think we do. How many vulnerabilities? How many rollbacks? How many failed deploys? We have some pretty standard metrics that we can talk about. There's a lot of different ways to get to good, but I think that shared definition of what it looks like, I think we have an idea, again, in here of what it feels like. I'm not going to get a ping at 3:00 in the morning. I feel okay about doing my deploy. I'm not worried about an end of life service all of a sudden being gone. Having confidence in the stuff that you're building and deploying, and not having that fear. So I think the shared definition is a good thing.
Ganesh Datta:
Can that be automated? How do you drive visibility in that shared definition of good? Is that the leader's responsibility to talk about that? Like you mentioned at the beginning, giving visibility into it. Is it shifting left and making that visible at the time of PR? What does that mean for practical purposes?
Jeff Schnitter:
That's a great question. Honestly, I think that's why I joined Cortex, because I don't know if we can solve that problem. I want to get closer to being able to solve that problem. In my experience, I knew I wanted to automate it, but there were so many manual touchpoints. There were so many manual attestations. "Hey, team, do you have a good load test? Do you have great performance tests?" It's hard to automate.
I'm not saying it's not possible, but the way that I've thought about that problem is, what are all the things that I have to do? What is a golden path? How do I get to production readiness? How many of those things can I automate? I think, can I fully automate it? Never say never.
Ganesh Datta:
It's hard.
Jeff Schnitter:
Never say never. It's software. So, I think it's possible. It's probably an 80/20 rule. There's a lot of them in software. I'm going to take the 80% that are easy. I think you can automate those. And then I'd love to get to the point where I've automated all of those, so that I can work on the hard parts.
Ganesh Datta:
That's really interesting. Obviously, you mentioned in your past you've done things like test automation and rolling those kinds of things out across the organization. How did you get people to adopt it? Walk us through a war story.
Jeff Schnitter:
Oh, man. I think they're all war stories. Well, I'm trying to figure out if I have major successes, because I think they all had certain roadblocks, or they ran into problems as you rolled them out, that they weren't complete because the technology was changing.
A good example probably was when I was at Workday, they were trying to break out a monolith into microservices. Now, it wasn't necessarily something that I was driving. Everyone was behind it, because... Well, this is another not proud moment of my career, but I started as a build engineer. The build took about a minute when I started. After about 10 years, it took like an hour and a half, under my watch. So, well done.
And the problem was, it was getting more and more complex. We were always looking for places where we could trim time and make it run faster. Everyone thought, let's break out the monolith. Let's get these microservices out. You'll have these builds that are 90 seconds, but you can horizontally scale them. No problem. We'll get back to the time when I first started.
Well, we got about a third of the way through breaking out the monolith, but there's certain parts that are so hard to break out. Now you're halfway through that and you're like, I'm not sure if we're going to be able to complete this. So you're going to move on to the next thing that you try to do. So honestly, most efforts, I think, ended with like, 75% or 80% completion. So they're all war stories.
Ganesh Datta:
Do you think that 80/20 rule applies there? Was that good enough?
Jeff Schnitter:
I don't think so, but yes. I worked at a super successful company.
Ganesh Datta:
Yeah.
Jeff Schnitter:
Super successful. Now, was 80% good enough? For sure. Workday is a fantastic company, really profitable. But if you talk to Workday engineers, they're going to know right again, here, what are the problems? What are the things that you're trying to deal with? It's that same morphing that I talked about. The morph of a one-minute build to an hour and a half, partially breaking up the monolith into microservices. There's so many of these things that you have to deal with.
Ultimately, if you're talking about success of a company, 80% is good enough. It's not good enough for me. I want it to be better, and then it's just picking and choosing. Where am I going to try to look at some of those failed projects or partially completed projects? I never want to stop. I think the North Star should be 100%. 80% is good enough, and so maybe you can measure to that. I'm always going to aim for 100%. I know it's a little bit corny. Shoot for the moon. If you don't make it, you can land in the stars.
Ganesh Datta:
Absolutely. Now, we talked about your role helping customers and organizations drive this kind of change and adopt new capabilities. If you had a chief of staff who could help you with this role, what would that chief of staff do for you?
Jeff Schnitter:
I would love to ask the chief of staff, "Where should I be concerned? Where do I have potential problems?" I don't want to be dealing with things retroactively like, "Oh, great. We can fail fast and I'm going to fix some vulnerability." I want to ask that chief of staff, "Take a look at my ecosystem. What's going on? Where should I be concerned six months from now?" Another sports analogy, if you'll bear with me.
Ganesh Datta:
I love it.
Jeff Schnitter:
A quarterback's got to throw to where the wide receiver's going to be. You don't throw where they're at. And so when I think about working with an organization, working with software, where is that evolution, which is constant? Where are we going to be in six months?
Ganesh Datta:
Yeah.
Jeff Schnitter:
I don't want to be reactive in six months. I want to be throwing the ball to that point. That's what I want to ask my chief of staff.
Ganesh Datta:
I love that. Being proactive, rather than reactive. Well, thank you so much for being on the podcast. Just to summarize, when you're trying to change the culture of an organization, you want to start with pain, what sucks right now. Maybe get an outsider's perspective. Go from that pain to outcomes, like what is this going to do for me? What is it going to do for my team? Create visibility, get leadership buy-in, have the leaders tell those stories, have the team tell those stories, celebrate those wins incrementally. Anything else you would add to that?
Jeff Schnitter:
Iterate. Rinse and repeat, because it's going to change. Whatever those wins were, the organization's going to morph, and because you've done it before, you know you can do it again, and you're ready to go.
Ganesh Datta:
So much insight there. Well, thanks so much for joining me on the podcast. It was great having you.
Jeff Schnitter:
Thanks for having me.
Ganesh Datta:
Thanks so much for listening to this episode of Braintrust. If this resonated with you, do me a favor. Share it with another engineering leader who's wrestling with these same challenges. And if you want to continue the conversation or learn more about how we're thinking about internal developer portals at Cortex, reach out to us at cortex.io. Thanks for listening, and we'll catch you on the next one.
