Why and how GoDaddy focuses on people instead of process

Abi: Glad to have you. On this podcast over the past few months, we’ve been talking mostly to infrastructure, platform, and DevEx Teams, and I’m really excited to learn more about your flavor of how you enable and help engineers at GoDaddy. So my first question is, I have a good sense of what infrastructure and platform and DevEx Teams tend to focus on, but what is engineering excellence at GoDaddy and what’s your primary focus?

Brent: Yeah, that’s a great question. I can talk specifically to our department and our department is the partner’s organization at GoDaddy, which is historically our hosting organization. But it has grown a lot in the last couple of years, because as GoDaddy has gone public, we sort of acquire a lot of hosting companies to grow our portfolio. And so our charter or my charter’s, to coach and establish high performing customer focused partner teams. And that includes about 30 engineering teams, approximately 200 engineers and approximately 30 product owners.

Well, that’s awesome. And I’m curious, how big is your group then, that’s supporting these 30 teams?

It’s actually very, very small. I would almost say it’s like a two or three person show and we support it in different ways though. So there’s things like agile coaching, there’s metric programs that we build and roll out. We have a quality organization where we support with quality. A lot of what I do in my day-to-day has a lot to do with agile coaching, which is tightening feedback loops, just working with teams and then also working with the business unit on org structures, team structures and those dynamics between the product and engineering teams.

Well, it sounds like there’s a broad focus, but maybe leaning more towards the organizational side of engineering effectiveness, as opposed to the tooling side, which is really interesting. I’m curious, who are your biggest partners and allies? Who do you sort of report to? Do you work closely with the HR team? A platform team? Who do you kind of ally with?

Yeah, I think our biggest support person, is our VP of engineering. And there’s been quite a history of who rules in the partners organization? Is it product ruled or is it engineering ruled? And that’s always been a good friction, but currently it’s our VP who’s the head of engineering. And the way our org structure works at this moment is, this VP has directors of engineering reporting to him as well as directors of product management, and then POs go up to them. And then of course, engineers report up through the directors of engineering. And so our biggest allies are directors and VPs, I’d say.

That’s really interesting because a lot of the organizations I think I’ve spoken to and have worked with in the past have more of a branched out model where product and engineering are completely separate organizations that then come together cross-functionally. I’m curious, what do you think of the model that you guys have? Do you see any trade offs between having them be separate organizations versus under the same sort of management chain?

That’s a really good question. So we have had the separation in the past and I think this is part of that natural friction that I was talking about. But what we find though, is it kind of gets heavy, it gets weighted towards one side after a while, right. And so then engineering teams tend to not be able to get the things done that they want to do. It’s very, very product driven. And so the technical debt grows and quality assurance or quality starts to drop a little bit because I mean, product is very, at GoDaddy especially, it’s very marketing driven. So we spend a lot of time just trying to get stuff out to our customers, but in the meantime, we kind of lose some of that foundation, that’s really important to engineers. Environments too, is another thing, is like keeping up with our environments, our test environments.

And so recently, probably within last year, we kind of shifted the other way. A little bit of a change of power, where everything came under the VP of engineering. And what we did differently this time though, instead of just saying, “Okay, engineers rule.” It was more of, “Okay, there are engineering metrics that we think are really important and there are things that engineers really need to do. How can we use those and couple those with product goals and make that part of the flow?”

‍So not only are you doing engineering metrics and then a good example would be having a page load time of less than two seconds, right. Now that is a customer need, but there’s some really heavy engineering that has to happen not only on the front end, but the back end. And sometimes in that other model, with the product forward model, that back end tends to suffer. So what we’ve done is, and then this is some of the things that I help with. And the programs that I run is we take those kinds of metrics and make them part of the product metrics and feed it up into some of those product goals, because performance is a very common request or better performance, is a need for our customers. And so that’s kind of how the shift has occurred over the years. And right now it’s working pretty well.

Have you heard any sort of complaints from the product side of that discussion? And before I say that, I’ll say that the anti UUA was different than what I was expecting and actually really inspiring, to hear you say that really this org structure enables a more engineering led culture. That development concerns and engineering concerns a more advocated for. That makes a lot of sense having heard it from you now, but that wasn’t necessarily what I had assumed was the reason for the org structure. But I’m curious, what have you heard maybe from the other side of the discussion?

Yeah. The other side of the discussion is probably a little bit less now. That transition that I talked about, took a long time. It took a long time of people moving around, mindsets changing, people deciding that that’s not what they wanted, so they would move to another organization, those kinds of things. So I think there’s less thrashing now. People are in alignment with this methodology in the way this flow works. But of course, there was a lot of pushback in the beginning, right? Because like I said, GoDaddy is a marketing machine. And so that really ties into very strong product driven related things. And not that that’s wrong in the least bit, but it’s more of how do you create a hybrid that works well together? And that’s really what we’re trying today. Will it work? Could we look back in five years and say, “Oh my gosh, that was a total flop.” I don’t know. I mean, it feels like today, it’s going very well.

Yeah. It’s definitely a really interesting approach. Probably not, like I mentioned, the approach that I commonly see, but I can just really relate to it, having even my experience just at GitHub, which I think historically was a very engineering led company. But after the acquisition by Microsoft, sort of shifted a little bit. The product management organization quadrupled in size. There really wasn’t a real product management organization prior to the acquisition and as a result and because there were such big kind of audacious business goals for GitHub, the culture definitely changed to be much more product driven. And I think there’s a whole nother side of that story, which is we had to eventually pause feature development completely for a quarter to work on developer experience and technical debt, which we talked about with Liz on a prior podcast episode. But really interesting to hear the approach you guys have landed on at GoDaddy.

Yeah. And just to be clear, Abi, that’s just this business unit, right. There are several business units at GoDaddy that are on that other side, that are still doing it that way. And it makes sense for them.

Yeah, really interesting. Well, I think, one of the things you mentioned in the introduction here was that one big thing that your organization or your team is responsible for is agile coaching. And I think you’re actually the first person on this podcast to kind of wear the agile coach tag, so to speak. But before we kind of dive into what that is and what that means, what’s your background? I saw you’ve been an engineer, you’ve been an agile coach. You’ve sort of woven your way into this role. I’m curious to learn more about just kind of your personal journey and how you’ve landed here in this role now.

Yeah. That word weave, I think is key there. My personal journey did start at GoDaddy with quality assurance. I think I was given kind of a funny description when I entered GoDaddy. My manager called me the quality assurance paratrooper jumper or parachute jumper. And so what he would do is, he would drop me into various teams to help out. And my expertise was automation, right? I’m not just doing manual testing, but I could do automation, performance testing, debugging, profiling and those kinds of things. So my start here was quality assurance and I have a long background of quality assurance before GoDaddy. Went through some management phases there. Was on a platform team for a while that basically built something very similar to S3 with object storage internally. Was on another no SQL platform team that we kind of, as a service at GoDaddy, fork to help manage global distribution of data.

And then, also in there, was agile coaching. So several years ago GoDadd went into this phase of, okay, what is agile and how do we do it, right? How do we get out of this waterfall mentality that the whole industry is in? And so I was very passionate and interested in, in what this was and how it worked. And I was very fortunate to work within or to work with a company, a third party that we brought in to coach agility at GoDaddy. And I was able to shadow one of those guys. His name was Derek Neighbors from Integrum Technologies. And he taught me all the things about agile, that I didn’t know quite yet, as well as how to interact with the teams and just be that coach.

And then through that process, I got to see so many real world examples of human system dynamics and how teams work together and how organizational structures can be formed, non-hierarchical. How do you kick off a team properly so they have all the things that they need to be successful? And it just blossomed from there. Eventually we moved away from that third party and I just kept that role, even though I didn’t necessarily have the title anymore, as I moved around the company. I was always seen as somebody that people could go talk to get advice on agile methodologies, tools and processes. And then from there, because of just the various things that I’ve been involved with, with agility, moved into this director of engineering excellence, because there’s just a lot of stuff that goes hand in hand with engineering excellence and agility. And it’s not just tools.

Yeah. I love that. And the not just tools piece is definitely something that’s come up in so many conversations with folks who actually work on the opposite end of you, more on the tools side. I think in almost all those conversations at some point there’s a remark about, “Well, yeah, there’s another side to this.” And I think that’s the side that you focus on, which is so interesting. When you were talking about agile and agility, it sounds a little bit like the Way of the Jedi, right? So I’d love to kind of demystify it a little bit. I’ve never actually worked with an agile coach. I don’t think I’ve ever worked at a company that had an agile coach. So can you deem, what does an agile coach do and who needs an agile coach?

I think, well, my opinion of what an agile coach is, they’re there to help teams work on theory, tools, practices. Learn how to streamline their pipelines. What is extreme programming? What is TDD? What is CICD? Those kinds of various things, questions that come up. As well as just some basic things within Scrum, right. I spent a lot of time working with people, teaching Scrum basics. Just clean Scrum and the value of all the ceremonies, the roles. When you don’t have certain ceremonies, what can happen? When you don’t have certain roles, for example, product owner, a lot of times, or Scrum master, some of the fallout that can happen when you’re trying to run Scrum. Kanban’s in there too. Where we teach a lot of things around Kanban and how that works and how that can fit into your workflow to just make your life a lot better, a lot more efficient. And then just learn how to inspect and adapt, so you can continually grow as a team or as an organization.

And I’m curious, do you feel that, all teams would benefit from an agile coach or is it just teams that are inexperienced, they’re new? Who needs an agile coach?

Yeah, that’s a good question. I think certainly inexperienced teams do need help, especially as they’re trying to navigate the culture of the company, where their integration points are, things like that and try to understand that. When they’re blocked, how to get past blocking and those kinds of things. An experienced team, I deal with a lot of experienced teams. I think a lot of times with an experienced team, they have a lot of experience in agility, in those concepts that come along with it.

But sometimes they just need that third party to take a look to say, “Look, we’re just stuck here. We’re not sure what to do. How do we break out of this?” And having that extra set of eyes is very helpful from a coach with all that experience to say, “Oh yeah, well, I’ve seen this before. Here are some options you can think about.” And one thing that’s important about being a coach is not to be really dogmatic, right? Because if you’re dogmatic about the practices that you see or the problems that you see over and over again, and how to handle them, there’s no room for their own personal growth and self-realization. So coaching can tend to be a little bit of a long process for a team, because you have to build that trust. You have to help them see their own ways. And that takes time.

Yeah. That makes sense. And I’m curious, so what’s actually the operational model for agile coaching? So you mentioned your team is just a few people. So how are you coaching, I guess, at GoDaddy?

Well today for me, the operational model is, my door is open. I’ve been at GoDaddy for 15 years. A lot of people know me. And so when people or leadership realizes that there might be a smell or something that can be helped with, or a new team spun up and they want them spun up quickly with purpose. I have this sort of open door model, to say, “Yeah, I’m available.” Or my director of quality assurance is available and he can help with that specific problem. I manage a couple of platform type tools as well that help aid some agility as well as various other CICD test automation, those things.

That makes sense. So it’s more of a pull model. People come to you and that makes sense. Would you say, do you feel underutilized at times or are you slammed with a backlog of people who need help? Are you scouting for smells yourself or is it, you have a pretty good inbound queue of folks who need help?

I think it’s a good balance. I think what’s interesting is some of the things that I’ve focused on the past. When I feel underutilized by the people, there’s always other things to do that are more big wins, right? Like we need this thing or we need a set of metrics that we can help drive in 2023 to align with product. And those things keep me busy. Now, is that agile coaching? No, but again, I think, like I said, agile coaching and director of engineering excellence and human system dynamics, they tie together very well. And there’s a lot of things that cross over and I don’t know if I could put it under one title, but that’s what keeps me busy during the day.

I don’t know if you’ve ever run into it, but I’ve definitely come across sentiment at times, particularly sort of in Silicon Valley of this. A little bit of a snuffing of agile. I think there’s sort of… Certainly practices like Scrum, for example, have sort of have somewhat tarnished their brand within certain, I think, sort of subcultures of Silicon Valley. And as a result, I think agile, and maybe even agile coaching has sort of been kind of thrown into the same bucket. So I’m kind of curious, have you seen that yourself? Do you see that on the internet? Have you run into people who feel that way or have that attitude? And I’m curious what your perspective is.

‍Yeah, it’s interesting. Yes, I do see it. Of course I see it on the internet. There’s so much debate going on there. And I have seen it internally myself. When I was doing the coaching at a GoDaddy level, not at just a department level, that certainly was happening. And I think part of it again was GoDaddy is saying, “Look, we want to become more agile. And so what does that take?” And when you’re trying to go to organizations and explain to them what it is and what the various things are within it, that can help them, there’s an automatic reaction of like, “We’re fine. Don’t mess with us, we’re doing fine. Look, we’re deploying.”

But the reality of it is, is a lot of teams can inspect and adapt and make improvements. And it’s more about getting people unstuck, but through that process, especially in that initial rollout of talking about agility and declaring that we want to pursue this, there would be people that I would hear through the grapevine, that would be vastly against it. I would hear their names and I would never cross paths with them because they did their best to avoid that whole momentum. They try to fly under the radar.

Now because I think the position of power or having that somebody come in at that other level and being able to talk to other leadership about what’s going on, on the ground and how they’re helping, you’re exposing some of that. And so I think also like, there’s this pushback, not only like they’re fundamentally against agility, but they’re fundamentally against somebody sniffing around and telling the state of the organization. And that’s really hard. And again, that’s where trust, a long time of work in doing it and doing the right things and seeing results. I think that trust is built.

That’s really interesting perspective. And I love the call out to, in addition to maybe, just natural or arguments or mislabeling, or sort of the anti spirit against agile in general, the defensiveness toward, having anyone come in and inspect, right. The culture of inspection sounds a little bit, maybe threatening to some folks. And that is really interesting.

Yeah. And today, I think it’s less at GoDaddy, right. Because we’ve been doing this for so long. I mean, I’m going to say, I’m going to guess, like seven years or more. And so it’s actually part of our culture now.

One thing that’s interesting, I was recently having a conversation with someone at Google who mentioned, they have this developer productivity org of 4,000 people who really act as solution engineers internally. They embed with teams and help them just be more productive, both on the tooling side. But I think also on the process side. So that to me sounds very similar to your description of an agile coach. Maybe perhaps coming into it with slightly different lenses and perspectives. So I guess a question I have for you is, do you think the branding of agile is part of the problem with agile as far as people’s negative views towards it?

Well, that’s a loaded question because, what is the branding of agility? And I think the branding of agility is, there’s what we see on the internet, which is all over, right? And then there’s what you build in your company, right? And then what you preach or you go off and do in your own company. And one thing that I’ve always resonated with is capital Agile versus lowercase agile. Which that capital is like, here’s this dogmatic way that you must do, right.

And to be fair, though, when we first started talking about agility at GoDaddy, we found that Scrum was a very helpful place to start. Because it’s a framework and it has described roles and processes and ceremonies and those things are a blessing and a curse. Because one, you are giving somebody something to look at, to try to follow. But then if you’re saying, “No, you’re doing this piece wrong.” Then it feels very dogmatic to them. And so to me, it’s more of, in my opinion, it’s best to create a culture of lowercase agile, but give them all the tools and information so that they can dig in and learn for themselves. And then when they get into trouble or they’re confused with the various certain things, you can help them through that.

I really love that. The lowercase A versus the uppercase A. Because I think, and this is just my personal perspective, I do think that the capital A is associated with dogmatic practices like you mentioned, like Scrum. But also even sort of the over commercialization of agile by consulting firms and vendors selling solutions around it. And I think that’s led to a feeling of being sold sort of, like you said, a dogmatic or religious sort of approach to development that, when we know that there’s not maybe always some, one size fits all approach, that works well. So I think your description of capital A versus lower case A, really hits up that. So I really appreciate that thought.

Yeah. And it there’s one other thing there too is agile at scale. And that’s where I think it can get really, really dogmatic and GoDaddy doesn’t subscribe to some of these. There’s an infamous framework, I’m not going to name it, but I’ll let you do that. But I mean, there’s value there. I see that. But if you look at that and you try to follow it to a T and you try to shove your company into that, I think you’re just asking for trouble. And maybe it will work in the long run, but the journey to get there, is going to be full of gnashing of teeth and ripping of clothes. It’s just going to be painful.

Yeah. I completely agree with that. And I’ve sort of speculated on why… Just something like SAFe, it’s fascinating to me, and I’ve never, I should caveat this, I’ve never worked in an organization that use SAFe, and I haven’t really spoken to anyone deeply about their experiences with it. But having seen and learned a little bit about it, it strikes me as sort of software development is fast changing and it’s a black box, it’s complex. And so I totally get why there would be an appeal to like, “Here’s a comprehensive system that basically turns software development into as systematized, as a manufacturing facility.” Like I saw a diagram of SAFe once and it literally looked like a manufacturing plant, right. Assembly line of software. And so I totally get the appeal, but I think the point you made, I’m curious what the long-term looks like for an organization that adopts that? I mean, you’ve now rooted your culture in that. I mean, how do you even undo that? If you adopt that, undoing it is probably going to be as difficult as implementing it. I’m curious if you’ve seen stuff like that?

I haven’t experienced SAFe myself, either very familiar with it, like have poured over their stuff and very familiar with the diagram and the different versions that they’ve come out with over time. But what I find fascinating about it, and I think there’s a lot of truth to it and a lot of reality is, I look at it from a system standpoint. Like a system standpoint of process. Right. And trying to put it all in place at once is, in my opinion, a fool’s errand.

‍So how can you put little pieces in place that they’ve identified as key structural things, like for example, the release train. How do you put those things in place and just focus on that piece and then build off of that? And I think you could probably break it down or modify it in the same way. If something is not working necessarily for you, modify that a little bit, and maybe that diagram gets changed a little bit for your company. And I think that’s the best approach you can take, but if you’re just trying to stick to that picture, I think that’s when that dogmatic trouble begins.

Love that perspective. Well, I’ve appreciated this sort of sober or honest conversation about agile and I’m sure it’s one, we’ll both continue having. I want to pivot a little bit and talk about, speaking of capital letters, you mentioned to me, you took this course through the Human Systems Dynamics Institute. I love to just get the quick dive into that. First of all, how did you hear about it? I’ve never heard of it. And what is it? What kind of drove you to want to learn more about that?

Yeah. Well, one thing inside of agility, I think is, from a coaching perspective is, becomes very fascinating to you is psychology, right? And I don’t know, somehow through that in the internet, I tripped over the HSD Institute and I saw that they had a program and that you could go learn. And my mentor at the time, Derek, has some great connections in the agile industry. And he knew that Diana Larson had taken that course. So he hooked me up with Diana and I talked to her about it and the value that she got out of it. And she basically talked me into it.

And from there, I signed up and then I went to a week long or sorry, it was about a three or four day long workshop. And then I joined a cohort for about eight weeks where we worked through all the tools and various things that they have. And honestly it changed my life because not only from a work perspective, but just from everything, like my personal wellbeing and the way that I look at the world and government and those kinds of things. So that’s how I found it.

Well, that’s a powerful testimonial. And I mean, can you give an example, I’m sure it’s difficult to cover everything that human system dynamics is, but can you give an example of maybe one of the concepts and then how it like a concrete change in the way you’re approaching a certain problem, or the way you look at a specific problem in your work might be?

Yeah. One example or one tool that they have is something called dissemination and complex adaptive systems. And the way that I kind of use that constantly is trying to understand interactions between objects. And objects, being people or teams or organizational units. So you have the person and you have the event or the inputs and the outputs of those things that interact with something else, whether it be a person to a team in those kinds of things. Well, so what I tend to look at organizational structures to understand communication paths or more than most of the time is actually a lack of communication, not actual communication paths. And trying to understand how I can improve feedback loops and things like that. So a lot of it has to do with context of those structures and how they interact with each other and how you can improve those things, for me.

But a blaring example to me was just a simple tool that human system dynamics provided, which was just differences and similarities, right? So at one point we had this team that was struggling to get stuff done, and they brought in, or GoDaddy brought in, a couple of more people that were basically high level engineers that totally understood agility. And they’re actually part of a third party and they try to integrate them. And you can imagine that clash that occurred when you get these people that tend to be very knowledgeable and then they’re merging with these people or this team that is having problems. And so, interestingly enough, like I said, where agility and HSD tie together is, I ended up running this very high tension retrospective for this group of people to try to bring them back together, because it was literally, it was exploding. Like it was a bad situation.

And I simply used this tool that they taught us with differences or indifferences, and made each one of the people in that team list the similarities in the differences that they had between this other party and basically talked them through that. And talking them through that, it helped a lot and it allowed them to come up with some ideas, understanding both sides, to move forward and out of that problem that they were in. And that problem in human system dynamics is called the… I’m going to pause for a second. That problem is called a sticky situation. Right. So I helped them through that sticky situation.

That’s awesome. Well, I’ll definitely look into HSD myself a little bit more. Sounds like you got a lot of value out of it and really enjoyed this conversation today. Thanks so much for coming on the show.

I really enjoyed it too, Abi. Really appreciate what you guys are doing with this podcast. I love it.

‍