Episode 32 | PMOs, Program Managers, and Slaying Reorgs with Shannon Vettes from BlaBlaCar

Shannon: This is actually a really good indicator when you should introduce process or not. What's the impact of not doing the process, right? I think it's the right question to ask ourselves, not like, what if we tried it and we see? It's like, what if I don't do it? Do I really care? Is this really gonna go south? Because if the answer is, "oh, we'll be okay." Don't do it. Like don't bring more process into your org if you don't have to.

Narrator: Welcome to Developing Leadership, the podcast for engineering leaders where Eiso Kant and Jason Warner share their lessons on the ins and outs of managing software teams. Today, we have the Head of Programs at BlaBlaCar, Shannon Vettes, on the podcast. Shannon is a transversal product and engineering leader with 20 years of experience in various roles, making her uniquely qualified to talk about the role of program managers, and what this means in the context of engineering organizations.

The guy spoke about dependency management and taking it away from engineering leaders, how PMOs can bring direction and focus around the company's mission and vision, and more. As always, this episode comes with accompanying show notes with a deep dive into the main topics, mental models, and key moments from this episode. Find them at developingleadership.co and linked in the episode description

Eiso: Hi, everyone. We're back again with yet another episode of Developing Leadership. Jason and I have a special guest with us today, Shannon, who has been the Head of Programs at BlaBlaCar in the last year is where, uh, she's titles herself transversal product and engineering leader. And we're going to learn more about that today. 

We asked Shannon to come on because she has over 20 years of experience holding a huge array of roles, making her uniquely qualified to talk about, what does program management mean in the context of engineering organizations?

When should you build it? What is it? And, yeah, big welcome to you, Shannon. And I'd actually maybe just love to start by a quick definition of, you know, what is it that, that you do? And what does actually program management mean and is that the title we should be calling it?

Shannon: Thank you so much for having me. I'm thrilled to be here. I love the podcast. Listen to it all the time, and I'm really happy to be a part of it. So what is program management? This is actually ... It's funny you ask. It's like the first question that I got when I joined BlaBlaCar. And I was taking over some of these teams and one of them was the engineering program management team. We were like, what was a program? What do you mean by that? What's the head of programs? What's that?

And, um, the simplest way that I've come to define it is it's like project management on steroids. It's like more complex, more intense, more teams, more difficulty of alignment, more dependencies on risks to manage. And it's just, it's another layer of complexity on top of what most people would consider to be project management. So it's aligning teams around their objectives, it's making sure that their dependencies are managed and their, their release timings are managed, that they can deliver to a common objective together.

So, basically, I think of it as someone who is trying to be helping people be in concert, right? It's not the conductor. Because I usually think like PM, EM roles is more the conductors because they're more decisive. But EPMs are a service role, or engineering program managers. They're a service role that helps support that group and make sure that, that they can focus on their core missions and not have to worry about, "did this team get this done on time to do this thing versus that one? Oh, no, this one's late. What does that mean for the rest of us? So program managers think about that stuff. And they, they care a lot about the whole and the, the entire objective. That's how I think about it.

Eiso: So I'm going to throw maybe a ... I'm not sure if it's a hardball question off the bat, but the, the dependency management and making sure that things are, are, are running well, shouldn't this be the job of, of the directors and the leaders?

Shannon: Ah, well, sometimes it is. I think this is where scale comes into question. On smaller organizations, yeah, those leaders can absolutely handle it, and they should. But this is where the value of program comes in. When your engineering leaders need to tackle harder questions, broader questions, it's great to have an engineering program manager team or a program manager team that, in that case, take the engineering out to do everything, end to end.

And in those cases, people who are working in larger scales can focus on that in a way that like a director would just be like, "Ugh, now I have to go and make sure team A works well with team B," right? And sometimes they just have bigger fish to fry. They could be thinking about like, do we move into this region? Or should I completely reorganize my group? And worrying about project A and project B is just less of a priority for them. So I would say, it's, it's a scaling question if you need that type of support or not.

Jason: As a follow up there, so is that primarily when you think about bringing in, we'll call program management to, to organizations or organizations to think about it is at some "version" of scale? And maybe walk us through if you were talking to a bunch of different companies, how you might evaluate whether or not they should even think about program management at the time.

Shannon: So good question, the when I think is the most important question that you can ask in this team. If you do it too soon, they won't be providing enough value. And if you do it too late, you're handing them a dumpster fire. So paying attention to the when is so important. Here are the indicators that I look at, is the product manager, who maybe at one point was serving as like end to end, like all the phases of the product development lifecycle, and they're, they're monitoring it and they're paying attention to that delivery.

Is your product management team now more focused on their metrics of success and their KRs and their KPIs and much less on, like, did project X is it on track, right? Or are they reaching a point where in order for them to achieve a delivery, they have to coordinate so many teams, and this o- again, like, for the leadership, this might be an indicator of reorg necessity, but not always. Sometimes it works very well, it's just complex.

But if the complexity reaches a point where the product manager needs to think about so many teams, that it no longer makes sense for them to focus on that because it would be the entirety of their time, that's a good indicator. On the engineering side, I think of it as a tipping point from, like, technical complexity. Are you dealing with multiple platforms? Are you trying to reach multiple systems at once? And do you have a lot of services to manage and a lot of decisions to make? Sometimes this can even just come about because we want to get rid of our legacy.

You know, like, sometimes those can be the triggers to creating program management teams. But the important thing to manage here is that, like, you're enabling your teams to focus on their core competency and where they're most valuable. And sometimes doing the, the project management coordination dependency risk management like these, these elements can take so much time that it takes away from what they should be worrying about.

So a good indicator of this in terms of, like, how you know if you're watching metrics is you start missing, like, cycle time goals, if your cycle time stretches out. You can ask yourself, is it because we just have too many dependencies, we're not managing them well and, like, things get stuck in the bottleneck? You can also see this happen in terms of, like, product metrics as well, if you're not making the same value gains that you used to be, like that slowing down, not becoming as regular.

Or if you're not reaching the same goals because people are more focused on getting the stuff done than watching what happens after this stuff shift. Those are two really concrete indicators that you should probably look at scaling and intr- introducing something to fill that gap. So that those things do get monitored and those other roles can focus on, is our technology solid? And are we delivering the value that we need to deliver to our people that our users that we care about? So those are the indicators that I look at, typ- typically. 

Eiso: That's one of the better explanations I've, I've heard on the topic. I'd love to go a little bit deeper here. If we look at the kind of dual role of, of an engineering leader between "we're continuously improving the way we work and we are delivering value," the PMO side are, you're managing dependencies, of course, a lot of delivery. But you're also really supporting the teams to improve. Talk to me a bit about how you balance both of those and, and how does that look like.

 Sure. 

Shannon: So I feel like sometimes both in program management and PMO, like s- they often, I just find them being introduced, usually, when it's late in the game. Like, we're feeling so much pain at that point that we know that we need it. And that's typically when those things get created. And the PMO side for me is, like, another layer of abstract in terms of, like, providing that oversight so that the people who need to focus on the product focus on that, and people who focus on the tech focus on that. And so PMO, for me, is like that next step.

Sometimes people will create a program management team before they create a PMO. And PMO, for me, is that next level oversight of alignment of objectives. So program managers can sometimes struggle with the, I've seen this a lot, with giving advice or input about what an objective should be, right? They are uniquely placed and positioned to see that like, oh, well, you're doing this and this and this and this. Looks like our joined up mission is somewhere around this objective. Like, this is where we align. But sometimes it's really hard to get people to buy into it.

And there could be a ton of reasons for that. Like, maybe the leadership is just really attached to them maybe and they don't want to rename and they don't want to re-objectify it. And they like what they've done. Or maybe they don't see all the connectors that you see because you're working across all these teams. And you can see like, actually, our focus is this, right? And in those cases, PMO can just facilitate that shift of we thinking and that we mindset that you need to reach at a certain point of scaling.

So I think the PMO comes about and brings the most value, first of all, when you realize that you just got too much stuff. Like, there's too much whip and you, and as a product team, like, you have a hard time seeing it all and a hard time making sense of it. And PMOs can bring direction and focus around company mission and company objective, in that they can be, kind of, a gatekeeper. Sometimes that can be bad. Sometimes that can be good. Depends on your organization.

But if they're gatekeeping, they're saying like, look, we're trying to meet these goals, this doesn't really fit into one of these buckets. Do we really need to do this right now? What would happen if we didn't do this right now, is the right question for a PMO to ask. And on the, like, engineering side, where the PMO becomes valuable is actually, I think, in protecting their capacity. Because engineers sometimes get slammed in those instances where the business has very vast and varying and ambitious goals. And engineering needs to be able to deliver to those goals.

So the PMO can sometimes be a protector for them, it can be a group that says, we see you with this amount of capacity, typically, and we respect that. And so that's why we're going to push back on these things in these ways, and say like, this is stuff that's not as critical and not as valuable. And helping set those guidelines for organizations with a little more authority and a little bit more vision and a little bit closer attachment to, like, strategy.

So I think that those are the differences maybe between, like, an, a program team that's, kind of, there, just like, be a service team, be a helper, fill that gaps that people can focus. And a PMO takes to that next level of like, now we're gonna help you refine objectives. And now we're gonna help you really bring focus and, like, reduce the whip so that we can really deliver well on the things that we care about. 

Jason: So quick question for you then, tactically speaking. How do you organize a PMO? Where does a PMO sit? Who does should it report to? Do you align to a product organization's organizational structure? Do you align to an executive staff's organizational structure? walk us through that a little bit.

Shannon: So this one's harder to answer. [laughs] I feel like you could say any which way and it would probably be true. It's not bad. I mean, what works for the organization works for the organization, right? So it doesn't matter what you recommend, it matters what the organization needs. So I've often and typically seen this being a strategic initiative. So like attaching it to operations and strategy or, or those types of departments in larger organizations are typically where that sits.

They will report into, like, a strategy operations team or a COO or something like that. Because in, in the essence of why you would do this, you would create a PMO in order to have a better focus on your objectives. So what better way to do that than to, like, focus them on the strategy directly? Like, that funnel, kind of, goes like this. It goes, starts with the strategy and the business needs and then goes into, like, PMO f- funneling those things and filtering those things. And then product managers, which I don't think report into PMO ever, typically.

But, like, they do need to take into account that information. They are in service of product, I feel like, in terms of organizational impact. They would say, hey, product team, this is where the strategy is going, these are the things that, that you have in your backlog of propo- the proposals that we're getting. And so we're going to try and limit some of these things to have better focus and better outcomes. So this is maybe the strategic outline that, like, we want you to focus on.

And the product team can, like, take that information and then go ideate on the backlog that they want to do and stuff like that. So I feel like the PMO sits typically under strategy. But they don't only work in a strategic vein. They will work with engineering, on balancing the innovation versus tech debt reduction questions. And they will also work with the product team and helping them limit the amount of, like, maybe projects that they can do if they get really ambitious, and the product team sometimes does. And they want to deliver all the features.

Sometimes the PMO can be that pushback for them. So I say like, they're, in my mind, in the view that I like of the PMO, they're on par with engineering leadership and the product leadership. They're right in the middle. All three of them need to collaborate well in order for it to really work. And they need to know their spaces and know their areas of concern in order for that to, like, happen frictionlessly. And we can talk about friction if you want, but, like, it will exist if you don't clearly carve out the space of where each of them lives and what each of them cares about.

Eiso: I think wh- what I'm gonna imagine is we're gonna have some engineering leaders listening to this right now and they are both impressed and overwhelmed, because there's so much to this. And I love-

 It's actually simple to me. [laughs]

 Exactly. And, and that's where my questions are going to focus on, like, to unpack, unpack this a little bit. Talk to me from, you know, an, an organization that is, you know, 50 engineers, should it start looking at having programs? Is it at 100? Is, is it organization size the right number? And if so, what are, kind of, those first steps that a leader who feels the challenges that you're describing, the unmanageable dependency tree, the struggling, like, to deliver the same value we used to deliver, that is thinking about like, you know, hey, we're going to invest in our platform team and our engineering productivity team that might have not thought about yet, at the same time investing in, kind of, programs?

You know, when should they, at what moment? And, and what's, kind of, that path is that you're going to hire someone in the beginning? You know, uh, at that very first moment, there might not even be a strategy, you know, org? Do they report it to engineering? So I'm, kind of, curious to get your, your practical advice from, kind of, zero to hero for someone who's listening to this, who's resonating what your pain you're 

Shannon: describing?

 Okay. What a great question. How to t- takes on this complex with lots of denominators. Like, well, where would you start? Thanks for that. I think the best place to start is by listening to your team. Are your engineering managers ... End of the commercial. Are your engineering managers and product managers tired of dealing with delivery dependency issues? That's the usual indicator. And I wouldn't recommend going straight to PMO, actually. I feel like PMO might be overkill. A lot of companies that are 0 to 50 or 50 to 100 do strategy perfectly well without a PMO.

They don't need it. So I would start maybe with one program manager and I would use this person as a means of reducing pain and measure that. Like, how much time did your team spend trying to manage dependencies, is the question that you would ask to your product team or your engineering team leaders. And did that get better when the engineering program manager or the program manager joined your team? Because those are two very different scopes and two very different missions. So, like, you need to ask them, in what instance would you feel less pain?

And see if bandwidth comes up, if they're saying bandwidth, bandwidth, bandwidth. You could try it. You should hire someone and you should try it. And I would recommend, like, going with a contractor. Because some of the benefits of, like, program management where you get a really good program manager, I think, is when they've seen a ton and they've been all over the place. So contractors often fit the bill. This is one of the great benefits of this role. You do not have to make a long term hire and you do not have to make a full team. And you do not have to make a PMO.

You can totally dip your toe in the water and see how that feels, right? So I would recommend starting small and just, like, seeing if some of the pain gets relieved. And if that happens, and you can measure it in your employee NPS or in your health checks if you're in an agile state or you can see it in the release metrics that I mentioned, like cycle time, time to value, and stuff like that, if your value add start increasing, increasing with that team that has the EPM or the program manager, then you can, sort of, say, okay, that worked.

Now, if you keep on having the same issues, that might not be the problem that you're trying to solve, which is also good reason to try contractor first before, like, building a whole team and strategy around it. It's like, find out if this is actually the problem space, if that solution helps. And if it doesn't, then maybe you have organizational issues. And I'm sorry to tell you, you might need to reorg or you might need to re-architect or you might need to re-platform. Or all sorts of other issues might be the actual root cause of your issue.

Engineering program managers and program managers are not a panacea. But they are a good indicator of scaling, a good indicator of growth, a good indicator of potential technological issues. And you can try them on for size and see if it helps.

Eiso: You threw out the, the almost forbidden word, which is a reorg.

 [laughs]

 And, and so we're, we're gonna go on a tangent here. Because I think, Jason, I don't think we've discussed the infamous reorg on the podcast before, which is, kind of, crazy how we got this many episodes in without doing so.

Shannon: Really?

Jason: It's interesting because we, we-

 [laughs]

 ... talked about a little bit about reorgs, but we also have not fully talked about dependency management either. And that's come up twice here in this conversation, so many outside of that conversation.

Eiso: Absolutely. So I sit on a lot of calls where the engineering leader says, we're undergoing a reorg because we're trying to solve problem Y. And you can pretty much see that problem Y isn't gonna get solved by a reorg, we're just pushing it down the line.

I'm very curious to hear, actually, both of your opinions on, you know, when does a reorg makes sense? And when should you stay away from a reorg? And, you know, and what about those kinds of organizations? I mean, hint, hint, Google that, you know, is notoriously reorging, you know, [laughs] every other quarter.

Shannon: [laughs] You just named and shamed pretty boldly.

 [laughs]

Jason: [laughs]

 [laughs] And so, 

Eiso: so, really, Google engineering leaders out there, happy to, like, receive anonymous emails on this.

 [laughs]

 But, yeah, let's, uh, I'm, I'm going to let you off the hook for a second, uh, Shannon and start with Jason and, and then pass it back to you. So talk to me about the reorg.

Jason: Well, so, this, this is obviously going to be a broad topic that you could talk about. But let me, let me talk about the Google one first and say that whenever I've seen large scale reorganizations at, you know, big companies, not, you know, "hey, engineering teams going to reorg," but largely like the executive machinations shuffle around a little bit. It has nothing to do with product engineering, has nothing to do with strategy, has to do with who is in, who is out of inner circles, who is politically in favor or politically out of favor, or who is trying to get more turf and things of that nature. We all talk about that, but we will never say that during the reorg. 

The second thing that I see at the largest companies when they are doing the reorg is they literally don't know why they're reorging. Like, you can't possibly fully understand a reorg. because if, you can't balance all your possible priorities and the best you could possibly do is say, we're going to align around one or two things at the moment and try to get those things done in literally like, I think that's what they're effectively doing. If it's not the politics side, it's the I don't know that I can X, Y, Z this one project or these two projects. So I want to make sure that I have a, a team of people who's literally focused on that and rename the, the organization and all that sort of stuff. And they think that's going to solve the problem.

But that doesn't solve the problem. You know, I think that's, Shannon could attest to that here. Now, on the flip side, I've been, you know, obviously worked at Microsoft and Salesforce, but I also, I, I was in via them, via smaller entities, um, in GitHub and Heroku. And I s- primarily a startup person that ends up in large enterprises. And I'll say that when you do reorgs in small organizations, or at least my approach to it was, had always been watching the dependency management, which teams depend on which teams, which depend on which teams.

So a good example here is I remember my very first time doing this at Heroku, I saw that there were teams, there, there were a lot of teams like two to three people who were basically owning components. And those components required involvement from other components to actually get to production. So I just basically circled them, and said, you're actually a team. You shouldn't have a component, you shouldn't have a team around the component. You should have one team around this entire entity as much as possible, saying, "hey, we're gonna release all of these things into production." And it has to do with who, you know, again, who has to have conversations with who or who depends on which backlogs or roadmaps or whatever word you want to use. And I just said, I want to get rid of all of those artificial boundaries. And my prime principle and thinking about reorganizations is that there are no lines in the world around us.

But for whatever reason, we put lines around us, particularly around organization saying, "my team, your team," or "my backlog, your backlog." And I just tried to say like, listen, those are artificial constraints. We don't have any of those. But somehow we started to think that way, so let's get rid of them. And, you know, my, basically, my principle is always to make bigger units typically, not smaller units. I tried to make it so you have bigger areas of ownership, uh, for, you know, organizations or leaders. Because you want them to be able to have more control, not less control over delivery.

Eiso: I'm passing it straight to you, Shannon. Yeah, you're, [laughs] 

Shannon: you're-

 I'm so aligned with so much ... I'm, like, sitting here and, like, viciously nodding [laughs]. Like, so much agreement with what you said. Dependencies is a leading indicator of reorg. But let's talk for a second, just about, like, what the org is. The org is, is a team's ability to deliver on their own, right? That's why you m- make the circle around them, is because that group of people together can do it, right? And when we put them all together, why we put the label of like team X or, or group Y or whatever, components or features, however you're organized, whatever topology you use, the reason you do that is to make them work together frictionlessly or seamlessly or whatever lessly word do you want to apply there.

So reorganization, to me, is a nuclear option. It's like the most disruptive, the most painful, and you should do it when it's really obvious that the team is starting to lose some serious function. Dependencies, the one that you called out is one of the biggest indicators of that in our health checks in all the organizations that I've worked out. That's why I love agile organizations built into PMOs, built into program because, like, they are an indicator machine for this stuff. They talk about pawns versus players, like, in those health checks. So do I feel like I'm in control of my scope?

Or am I constantly managing other people's dependencies? That's a good leading indicator. Or deal, the, that some people manage dependencies directly. I know we do and my former employer, BlaBlaCar, like, we manage that directly. Or you can just manage things like myAutonomy. That's a good word for it. If a team is not at all autonomous, they're dealing with something. That means that that organization of, of these people organized to work together is broken. So I think that you nailed it in your explanation, Jason. But I would also add that, like, use it sparingly.

And, and I love that you called out the political aspect because, like, that's one of the worst reasons to do on reorg. I think, as a leader, if you're doing it right, you're reorging when you care about your team being functional and happy and productive. And if your reorg is not serving that purpose, you're doing it for the wrong reasons. And I've seen this done recently for, like, the right reasons. And, like, we s- we sat down, we said like, what are the issues? Where are the dependencies coming from? Which teams, like, mapped out like the arrows?

This one goes to this one, this one goes to this one. And that's a great exercise to do, to find out if you have so many dependencies on a single or multiple teams that you got to break that. And we've seen multiple evolutions of this recently above, like, however the past like four, five years, where we've gone, kind of, feature, component, feature, component. And all of those made sense in the context of the problem that we were trying to solve, whether we were trying to go deep to solve an issue, that's where component teams really make sense, and where you can cycle your team members into different areas of the business and different pillars of the business to get cross-functional leadership and ownership in a tactical space.

That's a great reason to do, like, a more vertical siloed structure. But, like, cycle people through that structures, that you're not creating one person who has a center of knowledge and their stuff, single point of failure. But, like, when you're dealing with other reorgs that are, like, more like Spotify method, for example, of bringing people into chapters and squads and, you know, areas of competency that are much more business goal oriented.

And this is also where sometimes program management can be super helpful in facilitating that shift and keeping people focused and aligned and organized. But when you're doing those kinds of reorgs, I feel like there's an inherent need to, like, rebuild the team, which I think a lot of leaders miss. And that's what makes those reorg succeed or fail, I think, is isn't the team actually gelling and finding that organization useful for them. So reorgs have multiple components. There's the why you do it, there's, like, the when you do it, obviously, don't do too many elements.

Like, use it sparingly. There's the way you do it, do it in a way that, like, rebuild that team's structure and reliance and teamwork and, like, trust with each other, especially if they're cross-functional in nature, like that Spotify method. Or if they're going component, so with a deep problem, then you got to watch out for those silos and, and try and cycle people through, technologically speaking, so that they see different areas of the business and gain the deep knowledge. So that you can then break them out into, like, that pool of talent that's more transversal.

So, like, there's a lot of good reasons to do reorging that I just said. And I would say, don't do it if you can avoid it. [laughs] Because the team feels so much pain when you do it. They just feel like, oh, I'm lost. What's my mission? Who is my teammate? And it's, it's really destabilizing, I think. So, as leaders, we should be empathetic about when we do it and, and how we do it, especially.

Jason: I think w- we've talked about this on the podcast before, Eiso, too. So this is, kind of, a principle that I live by when you're building out companies, and, is how much of the conversation are we having about the inner workings of the company versus the customer and the product that we're delivering to the customer, the value we're creating for the customer? So what I tend to find is that, obviously, as you get bigger, you spend more time talking about the inner workings of the company.

But if it becomes a predominant conversation, particularly for a set of people, product engineering or operations or whatnot, you're going down a bad path. And there's many, there probably mechanisms by which you can solve that. But, you know, I get, I get letters or DMs all the time and emails and stuff like that from people who are basically saying like, oh my goodness, he's just said, like, "hey, at Microsoft or at Google or at Amazon, I feel like all I'm doing is pushing paper and talking about the process. And I'll get even bonus or comp'd on whether or not I, I, I followed the process and that sort of thing."

 I believe that is an unhealthy way. Now, I think that might be a defense mechanism for, at the largest, largest, largest, largest companies in the world. But ultimately, that is not why companies exist. Companies do not exist to follow the spoke processes that they built internally, but that is what happens at the highest level sometimes.

Shannon: Love that point be- I want to add on to that something because, like, I feel like I'm a huge process nerd. [laughs] I'm an anomaly, I love process so much. I will dig into this and just like, like a tick, I adore it. And it's something that most people don't like, and especially engineers don't like. And I feel like the thing that you said, which I want to really amplify, is the fact that process shouldn't be our purpose. And that we should be focusing on objective and, like, outcomes and not, like, the way that we did it.

And this is something that I need to, like, remind myself of sometimes because I'm such a big process nerd. And, but, like, I think the reason that that happens isn't just because they're afraid or something. I think it's because we don't want to waste time. And where I see process emerge and process, like, is born of us seeing like the snowflakes start to fall, like everyone's doing the same thing every little which way. And it's like, what a waste of time, you just spent, like, two weeks ideating on what is the right set of fields to have in your JIRA.

Like, we could have figured this out in the guild and, like, decided that this is the best way to do it. And then shipped it as a template or something, you know, like this is the origin of, of process and PMO and program managers would do well to pay attention to the balance and to know when you're hitting that point of we're spending more time on the process than we are on the thing that we're supposed to be doing. And I think that you need to have an indicator for that or some kind. You need a measurement,

Jason:  I like to talk about this. At, at one side of the spectrum, you've got the largest companies in the world. At the other side of spectrum, you have two people in a garage with a dog and just-

 You got both. [laughs]

 You're gonna have no process, you're gonna have no infrastructure, you're gonna have no bureaucracy or little, as little as possible, if you think about that, and with two people in the garage and a dog. At the other end of the spectrum, you're gonna have needed process and needed bureaucracy and needed things of that nature. And they're going to organic- it's going to organically evolve in those situations. Now somewhere in between all of those two extre- those two extremes, you're gonna start introducing various things.

And the, the typical reaction here is when, how, who, what, all that sort of stuff. I tell people quite often from a organizational perspective, we've had, again, had this discussion on the, on the podcast here, I like to keep all of my things monolithic as long as possible. So like my code base, my organizational structure. And as it, kind of, starts to need it, you start breaking these things off, what are those codebase and you'd pull off an app. But you're not c- you know, you're not going from a monolithic codebase to 1000 microservices. No one is going to think that that's a successful way to go.

So you go from a monolithic application to two applications possibly. You just split it into two large chunks. Well, that's the kind of the same thing you do in an organization. You go from, you know, t- two people in a garage with a dog to five engineers and a founder or five engineers and two founders. And at some point, you introduce the first salesperson or the first XYZ person. And that's the start of your first real split. Again, like, you can, kind of, see how this works.

Think of cells dividing and all that sort of stuff, then you get specialty cells. And so, you know, when we talk about the sorts of things, I think the, the real question is when. And again, I don't have a perfect answer to this. And I think it has to do with how you run organizations in general or h- what your app here, your inclination is, mine is to resist some of these things. But I'll use an analogy here, which is trailblazing, and how I look at almost everything in, in, in organizations, is I want to do it after, slightly after it's needed, but not too far. So here is, again, analogy.

 [laughs]

 You got a bulldozer. It's going through the forest. I don't want to lay the road before the bulldozer goes through. I want the bulldozer to go through and then I want to lay the road in the bricks after it. But if I took the time to go do the road before so the bulldozer had a steady, easy path, I think that is when bureaucracy is put in. If you do it afterwards, it's going to feel rocky, it's gonna be like, oh, that we just hit a stump. G- give us a minute, we're gonna have to figure this out. But I feel that that is what helps organizations grow faster. 

Now, is incredibly important they get two completely different types of people looking here. If you're using this analogy, the forward looking people are looking for the obstacles and, and they're trailblazing essentially. Like, we use this explorers, pioneers, and town settlers analogy, I think, that comes up. And the ones behind it are the ones who are actually laying this down in a way that's like, "hey, this road is gonna be great. It's gonna be robust." The people before them are just like, "there's a canyon over there, we're gonna avoid that, we're gonna go this way." And the people behind are like, "great, now we're gonna lay down the actual bricks and it's going to be sustainable, it's gonna last for five years."

Shannon: I love that, uh, such a great analogy. I think it plays really well to, like, the value of coupling these conversations with agility. And something that we've done a lot with our agile team is to, like, use them as the trailblazer, actually. So they've got lots of foresight. Like, they can, sort of, see because again, like, like the program management team, they've, they've been through some stuff, right? They're aware of risks, common risks in organizations I want to look out for.

But the benefit of using program and agile together as a team in this trailblazing effort is that you have one group, the program managers, which are very risk aware. And they'll be like, well, we'll have these issues and these concern in my head and blah, blah, blah. And they'll focus on all those things. And the agile team can be like, but let's do some experiments, let's do some small stuff. And they're more, like, incremental change that eventually like, when you get enough teams doing those incremental changes, make some big moves.

And it's not something that you roll out and ship really broadly in the agile sense. Usually, you would, you try something before you buy it. You, you ship it in a small sense, maybe even an organization that has like 40 or 50 teams, you try it with two, right? And you see if it lands and if the concept helps them, you try it with more, and then you try it with more. And to me, those are the bricks. So like those first teams are the ones that are, kind of, like, plunging forward like, we're gonna do this and we might have a hit.

Might not, might not get the greatest result because we're trying to, like, plunge through this, uh, like, you know, new road, but the program managers will help you avoid the canyons and the teams that come after will help you lay the bricks and make sure that it all, kind of, comes together nicely. And I feel like that's a, that's a great way to, like push, through change in an agile way instead of, like, really big top down, no, everybody does this. And you don't know if it works for everybody, actually. So that's my preferred way to, like, trailblazes as you've described it. I'm gonna use that same, you know.

Eiso: It's a good one. I think we, we can coin a term for it. So it's gonna be Jason's, uh, Jason's bulldozer analogy, you know, roll out.

 Yeah, I like 

Shannon: it.

Jason: [laughs]

 I don't know. [laughs] There's a, there's a bunch of memes that would come out of that one, for sure, though if-

 [laughs]

Eiso: I was, I was about to say, I was about to say, check out the show notes, people. We'll have name that, and maybe there will be a meme in there.

 Isn't that 

Shannon: the indicator of success, though? Doesn't that mean you've made it?

 Yeah. 

Jason: I mean, I think so.

 [laughs] Was your concepts are getting memes?

 [laughs]

 I think, uh, in 2022, it's if you can be memed, yes.

 Exactly.

Shannon: That's, that's my indicator, right?

 [laughs]

 If you get a meme out of this, Jason, props. 

Eiso: So, Shannon, you, I want to dig a little bit deeper, you know. The experimentation with those trailblazing teams to then start to concentrically roll it out in the organization, what's the role of the, the project manager and PMO at that point, right? Because the heart, it's one thing to run an experiment and even a successful experiment, it becomes a lot harder to then bring that over to the next 30, 40 teams and the rest of the organization. And, and how do you believe that PM, PMO, or PMO function can really help to make that happen?

Shannon: That's a super important question. They are the function of roll out actually, as I see it. And I, I agree with you, Jason, that, like, rolling out process globally should be taken very seriously. Because if you, I'll think of something that I just recently heard, which is just like, let's just make a JIRA template and ship it. And I'm just like, this will directly impact people so much. You are changing their ways of working in a very tangible way. You gotta ask them, you gotta try stuff, you gotta be listening, you gotta adapt.

And so I see, like, that early phase trailbra- blazing or, or, like, bulldozing, if you will, as, like, kind of, the agile realm of figuring out, will this work? And the PMO has a beautiful function that comes after, which is like, we know this works. So let's all get on board and stop, like, doing the ways that don't work and operate under a theory for a period of time. And I do think it needs to be measured for a period of time, like a quarter or two, depending on the scale and size of your organization and how long it takes to roll out.

But the PM team, sorry, the PMO and the, and the PMs and the Ems and the program managers can then band together through documentation, training, and incremental rollout and measurement of success. And let's be honest, few people want to do that work, right? Like it'd be hard press to find an engineering manager that was like, ooh, I want to track the rollout of this JIRA template. They don't care. They want to worry about tech stuff. So like, this is where the PMO brings a nice complementary skillset and interest set.

And that they really care about that like, did this help? Did this reduce this pain? Did this increase this metric that we're looking for? And they will worry about that stuff. So all these things come back to, like, who wants to worry about it? And the PMO group will be like, I do. And that's how you know that you need a PMO to work on something. And so, like, looking for who- who's having that area of concern and when is it really showing up as a success, like traction is something you want to look at. What percentage of your organization is starting to adopt that? And PMOs can also, by the way, help you develop that, like, process for process. Oh god, it sounds so, like-

 [laughs]

 ... people are cringing right now like, I hate process. You're talking about processes for processes. But it has to exist somewhere. Like, at what point does something become a trend in your organization? And you want to prevent people adopting practices that shouldn't be adopted, avoid shipping big, complex things where you can. So the best way to do that is by having, you know, some gatekeepers by saying like, well, until we have, you know, 10 of our 50 teams really liking this process and, like, seeing it work, we're not going to ship it to everybody.

And maybe you even AB test things like, this 10 do this and 10 do this. And then you measure results. Like, you can productize this. And I think that's an interesting way of thinking about the function of PMO. It's almost like a productization of the team. And looking at, is this the right thing that I now have done enough AB testing that I'm going to ship this one GA for the, for the full team, right? I think that's a, that's an interesting perspective to take when asking yourselves like, should I ship this up to everybody? It's, it's a question of, like, measurement within that group.

And it's going to be different for everybody, because everybody has different problems. And the PMO should help you figure out which problems are you really focused on and trying to solve. And are we at a point where we feel like we've found a good solution that we should bring out?

Eiso: So, is it fair to say that the team is the product, the PMOs are the product managers, and the team members and the leaders there are the customer? Or the organization-

 That's pre-

 ... is the customer?

Shannon: ... pretty close to how I see it. I would almost say like, you have key stakeholders, right? Your engineering manager and your product manager, probably the closest key stakeholders that you're gonna get. And I think that the PMO is supposed to, like, be listening to them as customers but also have, like, a side ear for the, for the team, like what's happening in the team. But I see agile coaches is, like, really listening closely to the team and the program managers being deepened into those sets of projects and saying like, are we really set up for success?

So, like, those two are your frontlines in indicating what's working or not working. And the EM and the PM are the two that, like, have decisive measure. So they're the closest to the customer, like you said. And the PMO is supposed to take all of that and say like, what makes the most sense? Because PMOs are a global organization, usually. They're meant to standardize, harmonize, centralize, and optimize. And if you're not doing those things with a PMO, why do you need one, is my question. Maybe you don't.

Maybe sometimes you needed a PMO for a while and then you don't anymore because, like, this stuff functions and you just don't need that oversight. And same goes for, like, engineering, um, program managers or program managers. Sometimes they're really critical and then reorg everything and, like, the dependencies disappears. Like, you don't need those team members as much as before. So I think when you're thinking about scaling these two things, I loved your analogy of like, the team is the product. But you've got stakeholders in multiple places. And the EM, PM are your two biggest customers of whether or not your solutions, your products, process, tooling, or otherwise are actually serving that team's need.

Jason: It's interesting, because I, when I think about, uh, again, going to the largest scale of things, I always ask the question, when should something be universally, like, almost mandated like, hey, from the top down, this is going to be the way, and when shouldn't it be? And there is no universal answer. Generally speaking, I always like to give people saying like, here's this that we're going to go do. Everyone is going to, kind of, be inside this bucket, here's escape hatches out if you need to do something different.

Here's when you're on your own if you are doing something different, versus you have the support of the rest of the organization, et cetera. And here's the requirements that you have. Like, you got a lot of ownership and autonomy, but you got a lot of accountability and responsibilities on the flip side. So, you know, at Microsoft or Salesforce, we always, we always had to do this annual security training and, b- and sexual harassment training and HR trainings and all that sort of stuff. And all of us were just like-

 Compliance.

 ... oh my goodness, this is, yeah, it's crazy. But if you understand why you're doing that, no, it is not the best use of an engineer's time to go do that. Yes, we are still going to require that every engineer go do this because it satisfies a certain set of things that the company just has to do for regulatory compliance and legal reasons. And, uh, it just, it just is what it is at that point. And, you know, on the, on the flip side, like here is, here is our release process, as an example. Here's what it looks like to release in Google, like you're in a release, blah, blah, blah here.

You stay within his boundary, you get all this stuff for free, all of it, right here. However, we can, you can escape hatch out. All of a sudden, you don't get this stuff for free. And you need to take care of all that sort of stuff. I think both things in that, like, uh, that example of release process or what's actually needed, stay within the bounds, get all the stuff for free, don't have to worry about it. Escape hatch out, great, you're on your own, here's what you have to do, here's what we're going to hold you accountable for as well.

And then all of a sudden, you can start to see how certain decisions we made. I think that s- that tension actually is quite good if you start to push that in there. If it becomes one way or the other as the organizations grow, I find that to, again, be- become unhealthy. It's like, no, we're just going to have absolute chaos at 200,000 people or everything is centrally decisioned and mandated all the way up, and from the top all the way down. Both of those end up in equally bad, but divergent bad situations.

Shannon: Yeah. I, I cannot be more emphatic with my agreement with you, actually. Jason and I are on the same page. It's like, I, I'm going to give you, like, a concrete example of this. And the concrete example that I'm going to pick is actually which agile framework to use. So a lot of organizations, especially right now, there's this really big safe trend. And so, like, program management, or PMO, could be a really good motor for distribution. "This is the process, everybody get on board. We're release training now. Yay!" But that's so dysfunctional for service teams, honestly. Teams with no dependencies should not be using safe. They just don't need to do that. It's overkill, process . Wise. And so if you ship that globally, you're not responding to the needs of the team. They need a kanban, they're focusing on the most important thing at the moment, let them do it. 

So the happy medium is giving them options and not like, and if they're gonna go outside those options, like you said, the escape hatch, you come up with really good examples with these. I like these terminologies. So I think you have to have like, if you're going to do the escape hatch, there has to be some constraints. You can do this in this situation. Like, security is a good example of that. [laughs]

You don't want people having you and escape hatch out of security, because that can be a huge breach risk. So you need constraints around some of those hatches around when they can do it and when they can get out doing it because it's not a big deal. I mean, we're not going to risk millions of dollars in fines or whatever. 

Jason: That's an important distinction too. Because, like, if you even take the analogy further, there's a tether, right? There's still a tether back to the space station for using the, the outer space one. And again, it's, you know, some things can be at some stage ... Example, I, I always like to use this example. Do lawyers make the decisions or do the executives make the decisions on risk compliance? And at some stage-

 Yup.

 ... most companies become lawyer driven on a set of things. And that's, again, it's probably fine because that's the type of the company it is where it is. And you just, you, it's a non-negotiable for that company anymore. You know, m- uh, Microsoft, if a lawyer said you can't do something, you can't do something. There was no getting around it. And that is frustrating at times. But, you know, th- it's just the way it is. It's just the way it is over there. And if you, if you want to change that, you actually have to be Satya to go change that.

 [laughs]

 That's, that's how it is.

Shannon: Yeah. Because, like, at, at some tipping point, and I think this is, this is the key thing that I keep coming back to when it comes to process and the right amount of processes like balance, you know. At a certain point, the compliance, the security, or the whatever it is risk is so great that it damages our ability to continue operating. And those are, like, the non-negotiables. You have to respect this stuff because the consequences are too great. And I think that we should ... This is actually a really good indicator when you should introduce process or not.

What's the impact of not doing the process, right? I think it's the right question to ask ourselves, not like, what if we tried it and we see? It's like, what if I don't do it? Do I really care? Is this really gonna go south? Because if the answer is, oh, we'll be okay. Don't do it. Like, don't bring more process into your org if you don't have to. It's always the right answer, I think.

Eiso: I, I love that, Shannon. And I think it's a perfect note to end today's episode on. Because I think we have to have you back on at some point, because it sounds like we can go for a couple more hours. But I really-

 Oh, sure.

 ... appreciate it. I'd like to ask you one question, though, a final question. You know, for engineering leaders who listen to this and have started realizing, okay, we should probably start experimenting with this. Any final words?

Shannon: I think there's one important factor to watch out for, because the root of all evil in process is no feedback. If your organization does not have psychological safety where you can actually get feedback, it doesn't matter how much you ask. Is this is working for you? Is this helping you? How is it helping you? You try and measure. You're gonna get false data. So before introducing new roles, new organizations, new processes, new oversight, first, make sure that your organization is one that will actually give you the feedback of, is, is this working?

And if I could leave, uh, like, anybody, any leader listening with that amount of advice, it's like, make sure your org is healthy in its feedback loops first before making big changes. Because you won't see the results you want, unless you start there.

Eiso: Fantastic. Thank you so much, Shannon. Has been a pleasure having you.

Shannon: Yeah, it's been wonderful being with you both. Thank you so much. I had a blast.

Narrator: Thank you for listening to Developing Leadership. Make sure you subscribe to follow us on our journey to more meaningful engineering leadership. If you have any challenges or topics you would like us to explore in an upcoming episode, tweet or DM us at devleadership_ on Twitter. To learn more about data enabled engineering and how metrics can help your teams and improve your processes, go to athenian.com See you in two weeks for another episode of Developing Leadership.

‍