Why founding Ibotta's DevEx team was like founding a startup

‍Abi: Welcome, Minh and Titus. We’d love to start off today by first just learning a little bit about both of your backgrounds and current work at Ibotta.

Minh: Thank you for having us. I’ll start us off. My name is Minh Pham. I’m a senior engineering manager at Ibotta. I actually joined the company about four years ago as an engineer, and quickly afterwards found my way into management. In the last several months, I’ve been working in our developer experience space, which is a brand new area. So yeah, it’s been a really cool journey. I’ve done a lot and worked in various areas of the business, and this is just the latest.

How about you Titus?

Titus: So I’ve been with Ibotta for actually … So when we’re recording this, I’m a couple of days away from my fifth anniversary with the company. I think this is the longest I stayed at a company, which is exciting. I am currently a distinguished engineer, also working on the developer experience team with Minh. When I originally joined, Ibotta, there was two engineering teams and we’ve got, I don’t know, 50 now. It’s pretty crazy. I’ve worked all around the company in various platform roles, delivering content or working on some of our largest code bases. Prior to Ibotta I was at MapQuest, but I’ve always been interested in programming pretty much my entire life.

That’s great. Well as I understand it, both of you have recently come together to form this brand new developer experience team at Ibotta. And as I understand, it’s been quite a long road and journey to establish this. So I’d love to dive into that. Maybe Minh, starting with you, maybe tell us a little bit what caused you to want to start this team in the first place?

Minh: Yeah, absolutely. Like Titus and I both said, we’ve experienced Ibotta through the lens of a lot of different teams and a lot of different experiences and projects and work. Throughout that whole time, I’ve always had a bit of more of a leaning towards management and the people aspects of it. We just noticed that as the organization was getting larger and larger, it was getting more and more difficult to continue to do great and effective work. And I really wanted to start to peel back the layers there. How do we continue to scale as an organization? Not just doing bigger and more impactful work, but also maintaining what got us here in the first place. And so within the last couple of years, I think there’s been a lot that’s happened in the technology industry as a whole with COVID and everything like that. It’s really forced us to put a closer lens to what it is that we’re trying to build within each organization. So at some point I just decided that’s the area that I really want to focus on, and I’m grateful that Ibotta gave me that opportunity.

Well that’s really inspiring. Titus, how about you? Did you have a similar experience?

Titus: Yeah, so I wasn’t there at the start, but I feel like I was there kind of early and saw a lot of that growth. And through that growth, something that I continued to have an interest in was how can we make the experience of developing both the day to day, as well as the efficiency aspect. I had moved around through some different roles.

And one of the key things that happened is, probably about a year ago,I had just joined the platform group, and my manager at that time was really encouraging me to flesh out where I wanted my career to go. And so I wrote up this hypothetical job that I called the meta engineer, engineering for the engineering process. And I continued to have discussions about that. And I think that was a big factor in leading to what ended up becoming this, because I was really pushing this idea. Which by the way, that hypothetical job description ended up being reused for the first job description for our first hire.

‍So give us a little bit more of the lay of the land before you guys formed this team. How many engineers work at Ibotta? Tell us a little bit about the org pre this team.

Titus: I think one thing that’s important to understand about the context of Ibotta. We have had various dev tools, infrastructure support-type of teams since about 2018. Our team, DevX, actually fits under a larger subgroup called engineering enablement that has other teams around cloud infrastructure and release tooling and whatnot. I think one of the things that really makes what we’re doing a little bit different is when you think about enablement, you can kind of think about it from two sides of the same coin. On one side, you have an emphasis on things that the organization may want, like say we want to improve the meantime to recovery, or we want to improve the deployment speed or things of that sort.

Those objectives are oftentimes driven by engineering leadership and business goals and whatnot, which is great. But the other side of enablement, the side that we are really focused on and the context that we’re trying to fit in, is we can also look at existing processes and tools and ask, “What is the experience like from the developer’s to use this? How can we improve that? How can we make it more enjoyable, more efficient, more desirable?” And so there is a broader context around we have teams that do tooling. Where we really fit is we’re trying to make the experience of using those tools in the day to day highly enjoyable.

That’s really interesting. So going one step further beyond just producing the tools, but really being out in the field and understanding the experience of developers using those tools.

Titus: Indeed.

Minh, I’m curious. Maybe can you share how many engineers are currently at Ibotta, and what’s the juncture of this team being formed?

Minh: So at the time that this team kicked off, I believe we were at about 230 within the engineering organization. That counts managers as well. And yeah, so we had grown quite a bit. When I had joined the company I believe we were sub 100 or so. And every team is about what you would expect. Six to eight engineers or so. And so we were stretched across, I don’t know, I want to say anywhere from 20 to 30 actual engineering teams, probably a little bit more. And some teams are larger, some teams are smaller.

So I’d love to just understand the journey a little bit more. When did you both get the idea for this developer experience team, and how long has the process taken to actually get it officially formed?

Minh: I guess it feels a little bit more unique, the path that we went through. It’s always been and is always continuing to be a journey that we are talking about, investing, creating the need, the desire for. Constantly working with engineering leadership to remind them that this is a worthwhile investment.

Officially to answer your question, Abi, we actually started talking about this, I would say, late summer of last year. 2021. And this is when the ideas were very, very broad. We knew the areas and the threads that were seeing problems as the company was growing larger, and leadership really wanted to understand what the root of this was, and more importantly, how we could actually work against that. How we could actually improve those things. And so that’s really when the conversations started and fully admitting late summer last year, the conversations did not look like actually starting a developer experience team. It was as we started to dig into it more, and we started to see the nature of the problems that we were handling, how many teams they were actually affecting, that’s when it started to become, “Okay, developer experience is not something that you can just do on top of everything else when it’s convenient. It’s really something that needs shepherding on an ongoing basis.”

Yeah, that’s really interesting. So it sounds like this journey has been long. Titus, I’ll go to you on this. It sounded like maybe some of this started with this ideal job description you had put together. I’m curious. What were the early conversations you guys had around this idea, and did they really just stem from that job description? Or were they separate threads going on at the same time?

Titus: There were a handful of conversations going on, and those early conversations weren’t centered around, “Let’s go create a developer experience team.” They were centered around actual problems that we as an organization were starting to see. To give you an idea, when you accumulate engineers at the rate that we did, and then you throw tools at them, there’s the chance that maybe those tools end up not being fully utilized. It’s kind of the nature of, I think, a high growth, fast-paced startup. And so a lot of those early conversations we were talking about how we inevitably had a lot of tools and resources and things that engineers could use, but there were a lot of signals that were telling us that they were underutilized.

So early on, there wasn’t a concept of a team. It was more like, “Hey, maybe we could do this presentation, or we could have this discussion, or we could have this training event.” And a lot of the early ideas were actions in a silo. It wasn’t until later that we continued to have these things, and I found out that Minh was talking about very similar concepts that I think the idea of creating a team out of it emerged.

That’s really interesting. Well Minh, I’ll jump to you then. What conversations were you having early on? And you mentioned they didn’t always go over so well. So tell us a little bit more about what that process was looking like.

Minh: So at the time I was already in the management circles and working in that function. And so my audience at the time for these conversations was the engineering managers, directors of Ibotta. So we started to dig in, like Titus said, there were a lot of problems and the organization had had plenty of tools in the past that we had used to try to address these. You do a training, you throw on a presentation, you create some confluence documents here and there, some toolkits for people to reference. But the problems kept coming back, and we kept finding that, wait, we solved this already. Or, wait, we’ve talked about this. There’s already resources here, but why aren’t people engaging with it? Why aren’t we seeing the supposed benefit of having done a teach out on, whatever it may be. Whether it’s time management as a manager, managing motivators and strengths for your teams. Why were these ideas still not really getting the same level of adoption that we expected? And so that’s really, when we got into this mode of thinking there’s more here. There’s something that we’re missing, and saying it once, saying it 10 times isn’t quite enough to actually get people to be able to act on that.

And so yeah, a couple of the early conversations that didn’t go so well, the idea was, “Well, we can’t just do a one time training on a particular topic. We’re going to need to revisit this and visit this again. And we’re going to need to understand why people aren’t finding this information in the first place.” Those are the areas we’re going to have to invest in. Otherwise, the material could be great, but people aren’t going to use it. They’re not going to find value in it.

So you were sharing out best practices, training, values, cultural practices, but you could tell that they weren’t really having an impact or being fully adopted. I’m curious, where did you start to feel pushback from executive stakeholders around the idea of forming a team, or just investing further? When did you first start to feel that pushback?

Minh: This is a great question. I love this. Because I think this is where our perspective might be a little bit different. I don’t think there was ever a time when the pushback didn’t exist. I think … Let’s just be honest. We all work in an organization, in a business, and the business’s goal is ultimately to sell products and services to make money. Otherwise the business wouldn’t exist. That’s not news to anybody. Where it gets tricky though, is when leadership is looking at something like the developer experience, and looking at some of these potential investments, they like to think in discretes. They like to know, “Okay, is it $50,000 over six months? What’s the outcome look like?” They like to see a lot of the discrete metrics and improvements. Where our approach differs from that is you’re always going to have that pushback, and the difference is your ability to speak to it and say, “Okay, but this is where we’re at today. If we continue to invest in it, this is what it could look like tomorrow. This is what it could look like six months from now.” And that’s an ongoing conversation.

And so, Abi, to your question, the pushback kind of was always there. And what was interesting is we had to change the goal posts as we got to them.

Well we’ll dive into that, but Titus, I’m curious, were you involved in similar conversations, getting some pushback around even your initial ideas for your dream job?

Titus: Not as much. Generally when you go to engineering leadership and you say, “Hey, I have some ideas about how to improve the situation, so that everybody’s happier and works more efficiently,” you don’t get as much pushback. It wasn’t until I joined forces with Minh. So Minh, I think you’re the source of pushback. I’m kidding. It wasn’t until I joined forces with Minh, and we started talking about making a bigger sustained investment that I think I started to encounter that. One offs are easy, but making a commitment to a team I think is when it really starts showing up. And you really have to prove that, yeah, there is something of value here. There really is something that we should go and pursue, and so this is a smart investment to make.

Yeah, and that makes sense. You guys both touched on it, but this natural pushback from executives that are naturally and by design focused on the bottom line of the business and getting features out that deliver impact to the business, are hesitant to make investments more internally. So I’m curious, how did you guys begin to build the business case and the justification for why that was a good investment?

Minh: Like I mentioned, this is one of those where the goal post is constantly moving, but I don’t want to make it sound like that’s an infinite uphill battle there. We are talking about what the goal post is every single month. And I think this is what both Titus and I realized very early. We have to stay in contact with engineering leadership. And we sort of use this metaphor in thinking about the developer experience team and everything that we’re trying to build. We view it as a startup within a startup. This is a notion. This is an idea that we believe in deeply. We believe it has a lot of value for the organization, but we’re not fooling ourselves that our customers, and namely our leadership, our investors are going to be bought in all the time. And so we pay really close attention to that to try to stay on top of that conversation.

“This is what you got for investing in DevX for the last three months, six months, but this is what you’re going to get. If you continue to invest in DevX.” We’re constantly updating our elevator pitch. We’re constantly updating our board slides, if you will. And it’s to serve that. We have to constantly remind leadership that there is still progress to be made. And there are still actually discretes that you can see, should you choose to invest another three months, another six months.

That might be a little uncomfortable. Thinking about a traditional software engineering team, that might be a little bit uncomfortable where you’re constantly in this game of essentially justifying your existence, but I think that’s kind of the world that every startup lives in.

I can relate to that as someone who runs a startup. But I was going to ask, can you give some examples of what these goal posts are, or really just what are you sharing with your stakeholders to get this buy-in and show them that you’re having an impact, or will have an impact?

Minh: Titus kind of alluded to a lot of these things. We started with the discrete problems that we saw. One of the first areas was tools that we are paying very good money for, but just simply aren’t getting as much usage as we would like. We literally made that one of our very first metrics that we reported on. Adoption rate. As a person who runs a startup yourself, you understand adoption rate is incredibly important. It doesn’t matter how good your product is if your customers just simply aren’t using it, then it’s not driving value. And so we viewed a lot of the internal tooling that we were building and supporting in very much the same way to measure, “Hey, what is our usage rate at?” And can we show to our engineering leadership that by working to improve the experience around these tools, people are actually using it more, they’re getting more value out of it. It’s actually helping them engineer better, more effectively.

Yeah. I like that. I’m curious. Any other examples? Maybe I’ll go to you Titus.

Titus: Yeah. So there’s certainly a lot I could say about how we have approached the investor relations aspect of our mini little startup. It’s not directly a goal post, but one thing that I think has had a very helpful positive impact on our situation is, in the same way that a startup thinks about the market opportunity, we have started to make better use of surveys to be able to demonstrate where the highest areas of needs are. So when we talk about a goal post, instead of just saying, “We think that we should have a goal post here,” we’re starting to be able to say, “This is the current state of the developer experience. According to the survey areas A, B, and C are the lowest rated, therefore this next quarter, we are specifically going to try to improve the survey results of next quarter by doing projects X, Y, and Z.”

That makes sense. So kind of taking a data driven approach.

Titus: Indeed.

I’m curious. So there’s one aspect to this, which is you’re kind of communicating externally to stakeholders to get buy-in and funding. What about internally? How do you guys talk about your own mission and charter, and the impact you can have with this group?

Minh: I think this is where it really helps that we came into this team already feeling a lot of these things through our own experiences in the company. And so when it came time to actually put this team together, I think a lot of us already had some very personal elements of the vision. For myself, I’ve always wanted to see an engineering org that was not only high performing, but really enjoying their time, enjoying their experience. People have a wealth of opportunities to chase, interesting problems to work on, and work is satisfying. It’s engaging. You can’t do that unless you have a team of engineering managers who are managing that. And so I think not only is it an emphasis on the tooling and the process, but it’s also helping managers to be able to deliver that to every engineer, and that’s not an easy problem.

I really like that vision. Titus, I’m curious. What about you? What’s your mission?

Titus: Yeah. I’m going to take a slightly different approach to answering this. You kind of asked there about what do our internal conversations look like? And I want to be transparent on that for a moment before I get into some of the mission stuff. Because I think it relates.

Minh and I, taking this startup metaphor, we kind of are co-founders in a sense. You kind of see the business and the technical co-founder thing. And I really liked his metaphor, because a lot of the lessons from the startup would carry over. And I think a great example of that is one of the reasons why having a co-founder when you start a startup is … One of the reasons why that works is because your co-founder offers commiseration and support when things don’t go well, and I think that there’s a real aspect of when you are trying to change culture, when you have this purpose to make the world, so to speak, a better place, even if the world is this small engineering department, you’re going to try a lot of things, and you’re going to have a lot of open and honest conversations, and sometimes stuff doesn’t work.

I think a defining aspect of a lot of our internal conversation is we’ve gotten to the point where we can have honest, not negative, but honest conversations about the current state of things. And I think to be engaged with developer experience, you have to push into the truth, into the honesty, and you have to ask hard questions. Our conversations, I think, have a very true nature to them. And that, I think, creates a situation where we can really talk about a true mission about what really are we going to improve here? How much of an impact is this going to have?

To summarize what I see as the vision for a developer experience is really just that people enjoy coming into work. The tooling and the culture and the processes aren’t getting in their way. They can come and they can be passionate and engaged and just get stuff done, but to get there, you have to ask a lot of really deep questions about why something isn’t engaging, or why something is pulling passion. And so there is really this element of honesty, I think, to get to that mission.

I love that. And I appreciate you being transparent about the behind the scenes of your team. I’m curious, any more specific examples of ways in which you guys have been able to go out and get buy in? And maybe if not, I’d be also curious just to know about any lows. What are some examples of things that got shot down, or initiatives you guys have tried that just failed? I’m curious to hear more about that journey.

Titus: Well, I think a great example is one of the very first projects we did … And just to clarify, the project was successful, but I think the way that we pitched it maybe didn’t go so successful. Our very first project was we gathered a lot of feedback that engineers were having difficulty finding information. So instead of introducing a new tool, we created a search product that aggregated the internal Wiki and documentation repos, and various companies have done things like this. We created that and we felt like it was going to be a slam dunk.

This was our very first project. We pitched it, we got approval. Everybody was like, “Yeah, this sounds great. Let’s go get engineers finding information.” What we intended to do was to then install Google analytics and be able to measure how many people were coming, and how many searches were happening, and how many people were finding results. That type of thing. We did that, and then we went back to the directors and were like, “Look in our first month we had 100 people use it.” And they were like, “Okay, what does that mean for the organization?” And so that was a real, I think, lesson for us that yes, we were excited about the adoption, but we needed to start connecting that tactic to a bigger strategy, and to be able to demonstrate what this actually meant more broadly to the business.

I’m curious then if you could go back to that meeting you had, what would you do differently to maybe tell that story in a way that you think may have resonated better?

Minh: I think, Abi, you say go back to that meeting. And man, the PTSD just jumps right at me. It just grips me a little bit. Because I remember presenting those numbers. Everything up and to the right. Green, month over month improvement, looking great. And everyone was kind of like, “Okay, so what?”

I think it goes to what Titus was saying. We needed to tie it in closer to this strategic umbrella that leadership was really, really brought into. And then finding the language for that. This is where investor relations is really, really important. We needed to spend a little bit more time with our leadership team to really understand that through these improvements, you are going to see that improvement to a metric that you do care about today. Something like meantime to restore. As you would imagine, responding to situations and responding to alerts and production fires, things like that are very knowledge heavy, especially for the person who may or may not be familiar with the code that they’re responding to. And so tying it that way, and being able to show an improvement to those areas, I think that could have gone a lot smoother.

‍I really love that thought process of relating your initiatives to the metrics or initiatives that leadership cares most about. Even if it’s an indirect impact, but still weaving that into the story. I’m curious, one thing you mentioned earlier was this need to affect culture and lift up managers. So how, practically speaking, have you begun or planned to approach that problem? Especially as just such a small group and a new group who’s struggling to get maybe buy in for your own existence, how do you now go out and affect change across a larger group of managers?

Minh: To be completely honest, it’s this is an evolution for us still. I don’t think that we have necessarily found the sweet spot that we’re just cruising at this point. And so I want to just be completely upfront about that. We’re still experimenting in this way. One aspect that has really jumped out though, again, using the startup analogy. In any kind of endeavor, you always have the early adopters, the people who already understand your mission, they’re already bought in, and they’re just excited about the potential. I think something that we’ve learned in this experience so far, we need to capitalize on that. And we need to capitalize on it not only from the management front, but also from the engineering front.

We have to have systems and processes that can capitalize on the early adopters and let them engage with us. There’s only so much room where you can introduce a new tool or a new process or something like that. But a lot of times people are really, really busy, they have their own lives going on, their own days going on, everyone already has a day job. You need to create avenues for them to be able to engage when they’re in the right mindset to do so.

And so one of the things that we’ve been looking at building is exactly that. Some sort of mechanism that teams can, managers specifically, can engage with when they’re in the right headspace, when they’re in the right time and space to do so. And that might mean something a little bit simpler. Some kind of newsletter, some kind of periodic event to hack on a particular non-functional requirement. Something like that.

Titus, I’ll go to you with a related question. But as you’ve been at the company for a while, and as you really understood the problems that exist across the organization, and even some of the ones you’ve talked about today like tool adoption, or finding information, do those problems exist more so on a local team level, or are those truly problems that you can tackle once for the entire organization?

Titus: Oh, that’s a great question. And this is certainly something that we have talked about quite a bit. There’s a lot that I could say here. Here’s maybe some initial thoughts.

We have done surveys and we have found that yes, portions of those problems are very localized and they will vary from team to team. However, there are commonalities that exist between them. And this is one of the things that I think we’ve tried to do. One team of a few people can’t go into every engineering team and fix all of these localized problems. And this was something that we just had to confront right up front and say, “Hey, we can’t do that.” We’ve gotten around it by framing a lot of what we attempt to do as a product that can apply to everybody, the principles around those products are we try to increase visibility or increase access. The pillars of the enablement. But what I think that ends up meaning is that there is a certain class of problem that we can solve, and there’s a certain class of problem that we can’t, at least with a shippable product.

Now on the flip side to that, one of the things that we’ve been talking about doing is creating what we’re calling a monthly engagement. So it’s a space where … Let me just give you an idea, a skeleton of what it looks like, because then you’ll see how it fits into this. Basically we could pick one nonfunctional requirement per month, and we work with the managers to say, “Hey, you need to designate half a day for your team to work towards this.” We kick off the month with maybe a presentation by a senior engineer, we have a Slack room where people can share resources about that nonfunctional requirement, and then we have this event that happens, kind of a, “Here’s four hours that are dedicated towards this nonfunctional requirement.” This is our monthly engagement. We haven’t come up with a clever name yet. We will.

But the idea is that in addition to the products that we ship that are tackling everything, we are trying to create space and resources and information, so that even if we can’t go into those teams, we can help coordinate opportunities for those engineers to specifically say, “Okay, this month is about logging. I’m going to go in and spend this time improving logging here. Or this month is about monitoring,” or whatever it may be. Yeah. That’s kind of our approach there.

That’s really interesting. Going back to your overall journey, you talked a lot about the friction and pushback you’ve encountered, but what about allies? Maybe give some examples of people that you have been able to get buy-in from. Who are these people, and what’s that relationship been like, and how does that continue to evolve?

Minh: I think this is where both of us started out, despite coming from different angles of the problem. The people that we were talking to, we got a lot of notions from both engineers and managers that the things that we’re talking about here, the developer experience and the elements that make up that experience, it is important. And so I sort of knew in the back of my mind before the team even actually spun up, there is a huge appetite for this. And it makes sense. When you think about it, who wouldn’t want their jobs to be easier, less friction, and just overall more enjoyable, more deeply engaging. That’s a non-starter. Or excuse me, that’s an obvious thing that everyone would enjoy.

But then as we started to talk to people, I heard it from engineers, I heard it from managers, I even heard it from our own engineering leadership. It was interesting. Actually, one of the very first things that we did even before starting the team, we ran a survey. We ran a survey with our engineers and we asked people, "Look, if you had two weeks to do whatever it is that you wanted, what would that be? And an overwhelming amount of responses were things that related with the developer experience. “I would improve the tools that I’m using on a day to day basis. I would improve these systems that I have to work on.” And that was how we knew. We have a lot of enthusiasm around these ideas.

That’s interesting. How about you Titus?

Titus: One thing practically that we’ve done, is we have a Slack channel that’s dedicated towards feedback on the product and tools that we’ve shipped. We didn’t realize it when we first did it, but that has become a way for us to identify allies and early adopters. We have adopted a strong communication policy with that group. So every time we make a change, we post a change log to that Slack channel, and every time somebody asks for an improvement or bug fix, given that it’s within reason, we pretty much try to respond within a day or two. Practically speaking, that has helped. We put the Slack channel out there so people who are allies to us can come and join. And so it’s been fun watching the membership of that channel increase and the interaction increase. And I think practically speaking, that’s helped us develop a stronger identification of who, and to create that communication bridge.

One of the other things is we have guilds within the organization. And so sometimes if we’re going to be working on an area, we’ll go look and say, “Is there an existing guild that’s already passionate about this topic?” And then when we start engaging them and they’re like, “Oh, you’re going to build something in this area that we already care about,” that creates a very natural alignment.

I like that strategy a lot. And as your function grows, and you guys are able to have a greater impact, I’m curious, what do you think is the bottom line impact you hope to be able to make on the business? Maybe another way to ask it is in two years looking back, what will be the return on investment for the business? Or what do you hope it will be?

Minh: Is this where I can basically go and start pitching all sorts of really, really lofty, ambitious goals with no clear indication that it’ll actually happen?

Pretty much. Or just maybe in terms of more bottom line impact. Looking back, if you were writing the resume for what you were able to accomplish in this group, what would you hope to be able to say?

Minh: I tend to be very lofty when I’m thinking about this. I personally believe it has the potential to impact virtually every aspect of the business. Literally how fast you ship code, the quality at which you ship products and services, the happiness and retention of your engineers. I believe that the experience is fundamental to all of those things. We’ve learned this lesson before in technology. User interface design became UX. Building products became really about the customer experience. I believe that the developer experience is that next frontier there that underpins virtually everything about our industry. So in a lot of ways, I don’t think there is a bottom line metric that wouldn’t be affected by a higher quality developer experience.

Well, I love that. And certainly, I feel inspired. How about you Titus?

Titus: Yeah. So much of what Minh said, obviously I’m going to be aligned with as well. We were having the conversation earlier about getting buy-in and really trying to demonstrate value, and I can’t help but see the parallels between the growth that TDD had to go through, where those early conversations were like, “We want to take developers away to have them write tests,” and then it ended up becoming an industry norm. The bottom line metrics that I see as really improving, Minh touched on them, really it’s improving the happiness and retention, as well as making a bottom line impact on better utilization of tools that ultimately results in higher quality software that has less errors and a faster recovery time that’s the Dora metrics that I’m basically quoting there.

That makes sense. And those are obviously pretty well established metrics that leaders care about. What are your plans for the team? Over the next year, do you hope to grow headcount? Do you hope to take on significantly more projects or launch major programs? I’m curious more tactically what your vision is in the near and long term.

Minh: So it’s multifaceted there. Do we hope to grow the team? Absolutely. I would love to have more people dedicated to the cause. There’s always a question of what the right balance is. And I do think that does have something to do with the size of your organization, the number of teams that are actually being supported. And so yeah, while I hope that the team certainly grows, there’s also another aspect that I am hoping actually comes out of this. I don’t believe that you have to be on a specific developer experience team to do developer enabling work. And I think part of success for how we’re viewing it, I think we need to see more of those activities across the org in various different teams and pockets as it goes along. We kind of touched on evolving the culture. I think this is one of those core aspects. Can we become an engineering organization where everyone collectively contributes a little bit more in their own way?

Minh: So that’s really where I hope to see it go. Hopefully the team does actually grow in size and head count, but at the same time, I hope that more people are also engaging in it just naturally within their own teams.

I love that. How about you Titus?

Titus: Practically speaking, I think the area that we definitely need to continue to push into more is around the communication aspect. Something I’ve been saying around the office lately is DevX is 50% tooling, 50% communication. It’s really easy to get wrapped up in like, “Oh, we’re going to put this product out there, or this process, or this thing,” and just think that it’s going to happen. But the reality is, DevX requires a constant commitment to communication, and it’s always something that we can improve. I would like to see us really ramping up that level of communication. If you’re going to affect culture, you have to get out there and talk to people. You have to be engaging. And sometimes in an organization, that can be uncomfortable. And so I think DevX really requires that push to get out there and to have the conversations. I would like to see us, in the second half of this year, really improving the ways in which we have those conversations, we interact with people, and we are a very present and communicative force in the organization.

Well, it’s been really inspiring to hear your journey, and I think so many listeners are probably in similar shoes as you. People who are really passionate about enabling developers, and maybe struggling, or eager to find ways to really affect change in their organization. So thank you so much for being on the show today. I really enjoyed this conversation.

Titus: Thank you.

Minh: Thank you. I did too.

‍