AUA: How Do You Balance Autonomy With Alignment In IT Teams?

- Hey y'all, welcome back to Outwork with The Ready. I'm Rodney Evans and that guy is Sam Spurlin. - Hello, Rodney Evans. - Every other week, we are tackling one tough thought provoking listener question and sharing a few ideas that we hope we're gonna help you out. Sam, what have you got for us this week? - This week's question is, and this is simplified from a longer more detailed question, but I think I'm gonna get to the heart of it here. How can our IT organization move from an inconsistent and fragmented federated model where accountability is unclear, central teams are seen as cost centers and modernization efforts have focused only on technology to a more consistently aligned federated structure that avoids duplication, improves accountability, and fosters better collaboration between central and federated teams. Rodney, where does your head go on this question? - Yeah, so in general, this is a tough org design question, so I appreciate it. I see companies really struggle with this all the time and they sort of swing from centralized to decentralized. This is horrible, foused in pendulum that they cannot get off. And the truth is that there is not one structure that's gonna work. So what you're seeing as the cracks in the federated model are going to be true and problematic and increase over time. And if you were to pull it all back into the center, you'll create a whole new basket of problems that look different. So the first thing to do is know that. Know that there is a third way between centralized and decentralized that you've got to find. And my first idea to actually start figuring that out is what are you designing for? So this is where design principles behind this structure are really, really helpful. And design principles in this case have to get super specific. Like it might be like this tier of customer gets white gloves service. And this tier of customer is entirely self-service. Or this suite of products or platforms is consistent across the enterprise and centrally controlled. And these kinds of tools and systems can be purchased at the discretion of the federated teams. Like you're gonna have to get really dialed in on what's meant to be consistent across and why and where you can allow customization at the edge. That's number one for me. Sam, what about you? - So the thing that I would add to that is needing to get really clear on the outcomes that we actually care about. So yes, I agree about design principles, but like why are we actually doing this? And the answer can't be even though as the org design nerd, you probably want it to be something along the lines of, well, this is the future of work. Or like decentralization is like, well, it can't be this like theoretical, philosophical answer about why the organization should be decentralized. - Don't say the Spotify model. Don't say Spotify model. You have to be really clear. What value are we actually trying to create? What outcomes are we trying to create that we think this model will allow us to better pursue? That is the only way you get in a really stable version of this. And people aren't gonna care about the org nerd design reasons. - Yeah, I think that's right. I also think that, so there's the structural component of it and then there's the capability component of it. And whether you're talking about the centralized teams or you're talking about one ring out from that, where you've got these federated teams, you really need to create some capability here around things like product thinking, user centered design and have really strong feedback loops between the center teams and the edge teams and the edge teams and their end users. The reason I'm saying that is because where this tends to go wrong is that the center starts solving problems nobody has. And the edge teams are seen as the more like value oriented customer-driven teams because they're closer to the end user. And actually, everyone should be operating using these skills, using product thinking, using experimentation, but a lot of times what we see is this bifurcation where the centralized teams acted in a much more rigid way and the edge teams acted in a much more flexible way and both think the other is wrong and are annoyed. And like everybody needs to be like, the edge teams can't just be chaoticly solving one-off problems for their users because that is not scalable and you will create so much org debt, you will collapse under the weight of it. And the central teams can't be just like filing TPS reports. Like you've got to have this adaptive skill set in all of the teams, having that and actually going through the experience of learning those skills is also going to create a level of empathy between those teams that might be missing right now. - Totally. My one last kind of watch out for this is anytime I'm working with a team or an organization where there is this decentralization push and in the same breath we start talking about duplication of effort, I try to put a stop to that because the goal cannot be perfect to de-duplication in a highly federated decentralized way of working. And I think a lot of times organizations get really wrapped around the axle, around like we can't have teams doing similar or the same things and in a decentralized model, I think you are really setting yourself up for a bunch of busy work to get perfect de-duplication when really you're prioritizing for something else. The resiliency, the redundancy and that comes at a cost of potentially some duplication. So I think you have to get comfortable with that idea if you're gonna go in a federated or decentralized way. - I was gonna make a very similar point, Sam, which is in this model, you are going to trade off perceived efficiency for adaptability and hopefully for innovation. But to your point, the inefficiency in the short term is going to look like people duplicating effort, people not talking to each other, people recreating work that has already been done somewhere else blah, blah, blah. And it's like you just have to live with that. You don't get both here. You don't get to be like a lean, mean efficiency machine with no waste and have the messiness that's required for experimentation and innovation. So just like you gotta put that dream to the side because you literally can't have cake and eat it too in this particular question. - One last thought from me is that in a lot of the decentralization moves that I have seen with clients is there's been this big push to federate, to decentralize, but not the authority. So teams have responsibilities and they're doing work out on the edge and the authority to own their decisions or to really make decisions that will allow them to move quickly has not been federated. That has been centralized. So you're left in this weird in-between where you have teams on the edge with no authority, which is really not decentralization at all. You've just basically made it harder to make decisions. - Yeah, we hate that. That's such a great point. It has to be carved out. It's one of the first things we do when we're working with like a mission-based team or a cross-functional team is be like, what can this team actually decide? And it's really hard for people to say those words. The last thing that I'll say is like, which sort of comes back to the first point that I made. But like, I think there's very few workflows that are well served by being completely common and standardized or completely bespoke. And one of the things that's tricky about like really advanced work design is you have to start to pull things apart and see that work is not monolithic. It is a series of 1 million tasks. And I imagine because you're coming from an IT organization, this is not terribly difficult for you to grasp. But for a lot of people it is. 'Cause for a lot of people they see, for example, compensation as being a process that is one process. And like, you know, I'll take comp as example because it is the season, y'all, where it's like, you know, what is centralized around compensation that might apply to a whole department or even a whole organization is this is the overall percentage that needs to be hit in terms of cost of living adjustments, overall base salary increases, et cetera, et cetera. And this is the percentage on balance of promotions that are within tolerance to be affordable. Those two tenants or constraints might be centralized so that the IT folks aren't like, we're doing 20% and finance is like, we're doing 1 1/2% like that sucks. But within that, presumably you want to have a lot of flexibility and authority for bespoke choices. And like, if you wanna put your whole budget on the burgeoning AI team that you think is gonna help you through the next phase shift and keep everybody else flat because you think that like, it's a buyer's market, you should have the flexibility to do that. Now, I'm using compensation as an example, but it is an example that can be translated to lots and lots and lots of things, including building technology for an organization. It's like, what is the bit of it that truly can be shared and common and consistent and within that same workflow, that same value stream, what really is better served by being configured at the edge. And most organizations are not well set up to do that, but I actually think that's the value. - Yeah, cool. - That is it for this mini. If you've got a question of your own, hit us up at [email protected]. - We will see you back next week for a full episode of "At Work With the Ready." Thank you for being a listener. (upbeat music)