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

Summary

---

Podcast Summary: At Work with The Ready

Episode: AUA: How Do You Balance Autonomy With Alignment In IT Teams?
Hosts: Rodney Evans and Sam Spurlin
Date: December 8, 2025

---

Episode Overview

In this mini-episode, Rodney Evans and Sam Spurlin address a listener’s question about evolving IT organizations away from a fragmented, inconsistent federated model—where accountability is unclear and modernization focuses only on technology—toward a more aligned, collaborative, and accountable federated structure. They break down the trade-offs, outline guiding principles, discuss the balance between autonomy and alignment, and offer pragmatic, experience-based advice on how to navigate this organizational challenge.

---

Key Discussion Points & Insights

1. The Centralization–Decentralization Pendulum ([00:54]–[01:20])

• Rodney describes the persistent challenge organizations face, swinging between fully centralized and decentralized models, each with their own vulnerabilities.
• Insight: Neither extreme is a panacea. The goal is to find a nuanced, “third way” by designing intentionally for both alignment and autonomy.

“This horrible Faustian pendulum that they cannot get off… there is not one structure that’s going to work.”
—Rodney Evans [00:56]

---

2. The Role of Design Principles ([01:21]–[02:29])

• Establish ultra-clear design principles for what should be standardized versus customizable.
• Examples:
  • Which customer tiers get “white glove service” versus automated self-service.
  • What platforms and tools must be universally used versus those federated teams can choose.

“You’re going to 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.”
—Rodney Evans [02:18]

---

3. Outcome Clarity over Theoretical Models ([02:30]–[02:59])

• Sam stresses being explicit about the real-world outcomes you’re pursuing, not just adopting models because they're trendy or theoretically sound (“Don’t say the Spotify model”).
• Outcomes should drive design, not organizational fashion.

“People aren’t going to care about the org nerd design reasons.”
—Sam Spurlin [03:15]

---

4. Building Capability and Empathy Between Teams ([03:21]–[04:55])

• Both central and federated teams need to build adaptive skills in product thinking, user-centered design, and rapid feedback loops.
• Symmetry in capabilities prevents the central teams from being seen as bureaucratic and the edge teams as chaotic.
• Having teams learn these skills together fosters empathy and stronger collaboration.

“Everybody needs to be… using product thinking, using experimentation.”
—Rodney Evans [03:47]

---

5. Accepting Imperfect Efficiency ([04:56]–[05:49])

• Sam warns against prioritizing perfect efficiency in a federated model; some duplication and redundancy are natural and even beneficial for resilience.
• Over-optimizing for deduplication in a decentralized setting leads to unnecessary busywork.

“The goal cannot be perfect deduplication in a highly federated, decentralized way of working.”
—Sam Spurlin [05:00]

---

6. Trade-Offs: Efficiency vs. Adaptability & Innovation ([05:50]–[06:39])

• Rodney emphasizes that messy duplication is a feature, not a bug, of innovative environments.
• You must “live with” short-term inefficiency in service of longer-term adaptability and innovation.

“You don’t get both here. You don’t get to be a lean, mean efficiency machine… and have the messiness that’s required for experimentation and innovation.”
—Rodney Evans [06:13]

---

7. Federation that Fails: Responsibilities Without Authority ([06:40]–[07:14])

• Sam points out a common misstep: organizations decentralize tasks but not the authority, leaving edge teams unable to act decisively.
• True decentralization must include distributing real decision-making authority.

“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.”
—Sam Spurlin [07:08]

---

8. Deconstructing Workflows for Smart Standardization ([07:15]–[09:56])

• Most organizational processes are neither entirely standard nor totally bespoke; the key is dissecting workflows and deciding at a granular level what must be centralized and what can be delegated.
• Uses the example of compensation structures in IT and how the right balance enables both consistency and necessary flexibility.

“Work is not monolithic. It is a series of 1 million tasks… What is the bit of [the process] that truly can be shared… and what really is better served by being configured at the edge?”
—Rodney Evans [08:48]

---

Notable Quotes & Memorable Moments

• “Don’t say the Spotify model.”
  —Rodney Evans [02:57]

• “You have to get comfortable with [duplication] if you’re going to go in a federated or decentralized way.”
  —Sam Spurlin [05:12]

• “Put that dream to the side because you literally can’t have cake and eat it too.”
  —Rodney Evans [06:28]

• “It has to be carved out… What can this team actually decide? And it’s really hard for people to say those words.”
  —Rodney Evans [07:18]

---

Timestamps for Key Segments

• 00:54–01:20 — Centralization vs. Decentralization overview
• 01:21–02:29 — Designing clear principles for alignment and autonomy
• 02:30–02:59 — Emphasizing desired outcomes, not trendy models
• 03:21–04:55 — Capabilities and empathy between central and federated teams
• 04:56–05:49 — Why some duplication is necessary and desirable
• 05:50–06:39 — Efficiency vs. innovation: Accepting trade-offs
• 06:40–07:14 — Pitfall: Responsibilities without real authority
• 07:15–09:56 — Practical example: Standards vs. flexibility (compensation analogy)

---

Tone and Style

The conversation is candid, practical, and lightly irreverent, balancing organizational theory with real-world experience. Both hosts avoid jargon and focus on actionable advice, often using humor and directness to underscore their points.

---

For IT teams—and any organization—struggling with alignment and autonomy, Rodney and Sam offer a grounded, honest discussion that both acknowledges the messy realities of modern work and suggests concrete steps forward.

Transcript

[A]

Hey y'. All. Welcome back to Outwork with the Ready. I'm Rodney Evans and that guy is Sam Sperlin.

[B]

Hello, Rodney Evans.

[A]

Every other week we are tackling one tough, thought provoking listener question and sharing a few ideas that we hope are going to help you out. Sam, what have you got for us this week?

[B]

This week's question is, and this is simplified from a longer, more detailed question, but I think I'm going to 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?

[A]

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 is this horrible Faustian pendulum that they cannot get off. And the truth is that there is not one structure that's going to 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 glove 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 going to 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. So Sam, what about you?

[B]

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, you know, something along the lines of well, this is the future of work. Or like decentralization is like what will make us. It can't be this like theoretical, philosophical answer about why the organization should be decentralized.

[A]

Don't say the Spotify model.

[B]

Spotify model. You have to be really clear like 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 going to care about the org nerd design reasons.

[A]

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, 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 act in a much more rigid way and the edge teams act 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 chaotically 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 got to have this adaptive skill set in all of the teams. And 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.

[B]

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 deduplication 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 deduplication 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 going to go in a federated or decentralized way.

[A]

I was going to 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 got to put that dream to the side because you literally can't have cake and eat it too. In this particular question, one last thought.

[B]

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 decentralized, 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 remained 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.

[A]

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. Because 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 tis 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 one and a half percent. Like, that sucks. But within that, presumably you want to have a lot of flexibility and authority for bespoke choices. And like, if you want to put your whole budget on the burgeoning AI team that you think is going to 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 work. Yeah.

[B]

Cool. That is it for this mini. If you've got a question of your own, hit us [e-mail] we will see.

[A]

You back next week for a full episode of At Work with the Ready. Thank you for being a listener.