Giving your Engineering team autonomy and balancing that with process

[00:03:00] Welcome and Introductions

Andrew Murphy: Everybody, welcome to the Tech Leaders Livestream. I’m Andrew Murphy. I’m a tech leadership trainer and coach and this is a livestream where I get together the people that help me become better and share them with you. When I became a tech leader 15 years ago, there weren't a lot of books, people, resources out there to learn from. So I decided I'd start sharing the people that teach me how to be a better leader and giving them to you for you to ask them questions.

Today we're going to be talking about balancing process and autonomy in teams. Should you be at one end of the spectrum or the other? Probably not. We’re going to talk about how we find the middle ground. I’ve got two excellent people with me today: Susan and John. Susan is the CTO of Collider and John is the CTO of Gleam. Susan, do you want to give us a quick intro?

Susan Brander: Hi everyone, I'm Susan. I'm a developer, engineer, leader from long time around. I'm also co-organizer of Tech Leading Ladies and branched out into my own startup last year with Collider. We're working on improving the gender balance in technical leadership, an extension of my work with Tech Leading Ladies.

Andrew Murphy: Awesome. Very, very important. John?

John Sherwood: Yep. So I've been a developer for about 20 years, currently running my own company called Gleam, which is mainly competition software, but a few other marketing tools. Been in a bunch of teams as a consultant and as an employee over the years. In the lead up to this talk, I’ve been thinking back to the various levels of autonomy and process I’ve been subjected to, and also subjected my teams to. So yeah, I'm sure it'll be a good chat.

Andrew Murphy: John is our first return expert to the livestream, which will be excellent. You can ask him questions you missed from last time if you want. That's a perfect segue: we’ll start with some prepared topics, and then please put your comments and questions in chat! I like these to be actionable for you, so ask questions, make comments. We're here to talk with you, not just at you for 60 minutes.

First, let's have a little bit of a fun one. What's your favorite tech gadget that isn’t your computer? I’ll answer first: just before this started, I was showing John my teleprompter. As I started doing more livestreams, I get so excited at the beginning that I forget what I need to say. A teleprompter lets me look right at the camera, see all my notes, and not forget anything. Best $170 I’ve spent on a piece of tech. Susan?

[00:08:14] Icebreaker: Favorite Non-Computer Tech Gadgets

Susan Brander: Ridiculously boring, but it's actually my Apple watch. I love getting away from my phone and computer, but I go hiking a lot, so being a bit of a data nerd, I love tracking my hikes, distances, elevations, and being able to do that with my watch without a phone—brilliant.

Andrew Murphy: I'm also a huge data nerd, but for me it's household stuff. I track all my solar panels. I just got a new heat pump water heater and I’ve bought a relay to hook it up so when the sun is shining, I can turn the water heater on. I'm going to track all of that.

Susan Brander: We need to talk because you can even automate that stuff. I've got a whole interest in renewable energy and solar home automation.

Andrew Murphy: All right, we definitely need to talk. I’ll show you my home assistant installation. John, what's your favorite gadget that isn’t your computer?

John Sherwood: The honest answer is probably AirPods, but this is one of my favorites: it’s a dumb thermometer. No app. No app on an App Store that disappears after three years. It does its job and doesn’t get hacked. I love dumb devices. I’m like an anti data nerd—I don’t want the numbers because then I’d have to do something about them. So I just don’t look, no data!

Andrew Murphy: We've got both ends of the spectrum here. I must say that with smart home stuff, I severely prioritize things that don’t have cloud or don’t need cloud, because they might just stop working. That’s why I like home assistant and Zigbee/Z-wave—no cloud needed. Maybe we can pull you onto the dark side of smart devices, John, if we show you how they can work without an app.

All right, let's kick into our pre-prepared questions. Let's talk about autonomy and process: how do you balance them? What does autonomy mean to you? What does process mean to you? And how have you gone about striking the right balance? Susan?

[00:10:58] Defining Autonomy and Process & How to Balance

Susan Brander: Yes. Autonomy to me means the team—and individuals within it—are making their own decisions. That could be about process, technology, choices, ways of working. Formal process is something...I don’t use the words "imposed upon them" so much as a situation that’s been set. I often use sensible defaults: that can be a formal process, but it’s a set of guardrails—a context to work within.

It really depends on the problems you're trying to solve, the team, their experience. I’ve been in a very process-led organization and leapt into the next one thinking, “Everyone’s going to have autonomy!” But the team was very young and when I gave it to them, I was effectively handing them a blank canvas and saying, “paint a masterpiece.” That was unfair. So together, we put in some guardrails, sensible defaults, provided experience and opinions, and let them work within that—then begin to break out.

Andrew Murphy: That’s a great point on guardrails. There’s a big difference between a rigid process you must follow and guardrails within which you have autonomy. I think this conversation will go to those guardrails. John, what do autonomy and process mean to you, and how do you strike the balance?

John Sherwood: Yeah, I guess processes are the automated side and also the expectations of what people are supposed to do regularly. As for autonomy, it’s about what someone can do—from absolute freedom (like as a founder, within political and regulatory constraints), down to someone being told which lines of code to write.

People land differently on the spectrum. When you're at the start of your career, sometimes you want more process and less autonomy—so you can be spoon fed how to get things done and not freak out. Someone with more experience wants freedom—if you throw too much process and restrict autonomy, people will quit.

[00:13:36] Experiencing Different Needs for Autonomy over Careers

Andrew Murphy: Interesting! Susan, have you noticed people's desire for autonomy versus process changes, shifting more towards autonomy as careers go on?

Susan Brander: It can be career, but also the problems they're solving. Process can mean, “I don't have to think about these things,” like frameworks. If someone’s focused on getting things done, they don’t want to think about all the things behind it. Later, they might want to challenge, be curious, and affect change. So it’s not just early vs. later career; it’s also about what’s going on in their life and the problems they’re solving.

To have full autonomy with responsibility, you need context—understanding the business process, reporting, regulatory needs. Not everyone wants to be doing that at all times.

[00:14:53] Problems with Too Much Autonomy—Missing Frameworks and Data

Andrew Murphy: That’s a really good segue to issues with too much autonomy. If you give people autonomy but without the decision-making frameworks and data, you get anarchy. I’ve seen this happen: companies swing to autonomy, but don’t provide frameworks or the data to use them.

For example, orgs say, “Teams aren’t choosing the right features!” I ask, “How do they decide?” They say, “We want them to consider profitability, user demand, etc.” I say, “Where do they get the data?”—“We talk about it in the board meeting, but the teams aren’t in the meeting.” Teams can’t make the right decisions without the data or understanding what it means. It’s a huge mistake I see again and again.

Anyone else seen this?

John Sherwood: Yeah, as a dev, upgrading libraries is a clear, easy win: productive, clear pull requests. But to push a pet feature, that’s a huge battle—having the data and context to do that is tough. I don’t know if I’ve ever had a team, even my own, where we do the Google 20% time thing well.

[00:17:14] Owning Consequences and Feedback Loops

Andrew Murphy: Another example: when people are shielded from the consequences of their decisions. Say a team builds a feature that isn’t useful—they’re told “oh well, never mind.” But you need to show the data, explain and feed it back into their decision-making framework. Not to blame, but to help them learn for next time. Teams need to see how they might have missed information or could have improved their process.

Susan Brander: I love that—if teams are going to own something, they should own it. Autonomy comes with responsibility. If teams pick a feature, do the research (even if it’s flawed), measure it, and come back and say, “Hey, it didn’t work,”—that’s great. No fear of failure, but also an understanding that they don’t want to maintain legacy systems with no value. They measured, they cull their own things, and move on. To do this, they need context—access to customers, data, and the passion and rewards when driving the business forward.

[00:20:14] Team Autonomy and Process, Not Just Individuals

Andrew Murphy: Notice how we’re talking about the team, not individuals. The whole team should be able to make these decisions.

Susan Brander: And this can be supported with process! You can have a good process for feature delivery, from ideation (no matter who it comes from) to end of life.

Andrew Murphy: Brilliant. Speaking of process—let’s flip the question. Any examples where too much process has led to issues in a team?

[00:20:40] Problems with Too Much Process

John Sherwood: I once worked at Census as a consultant—an interesting 18 months. It was like working in a chain gang: pairing all day, meetings for everything (kickoffs, walkthroughs, retros, estimation). We did the full Agile bingo card. So things moved incredibly slowly. But I learned a huge amount, and the stuff we built was basically bug-free, fully tested—incredible quality, but very slow and exhausting.

Susan Brander: Could not imagine thriving there myself. I walked into an org with a change access board—twice-weekly meetings to review all commits to prod. Some people really loved it—they were absolved of responsibility ("the board approved it"), but that didn’t last long.

Andrew Murphy: That’s the problem: process can make people lose responsibility for decisions, blaming “the process” or “someone higher up”. So they don’t live the consequences.

[00:22:42] The Problem with Rigid or Misaligned Processes

Susan Brander: Rigid processes that can’t flex for team or organization needs lead the org and team to flex to the process’s needs. You lose the people who don’t fit. Outcomes end up being driven by the process, not business outcomes—and I think that's flipped.

John Sherwood: Process can help you not think about certain things—flowcharts or rules to follow. That's helpful! Like in our app, someone has to triage errors every week—not fun, but it needs to be done. I try to clarify what's a real error versus noise. Writing out rules helps. Sometimes, expectations don't match reality.

[00:24:19] Balancing Stakeholder Communication and Lone Wolf Syndrome

Andrew Murphy: Someone commented about balancing saying no to stakeholders, and communicating your decision-making framework. If you give autonomy, how do you help teams communicate to stakeholders why they’re saying no? That’s important. Another comment: there’s autonomy and there’s lone wolf behavior. How do you tie autonomous decision-making to team goals and delivery? Any examples of “lone wolf” issues?

Susan Brander: John?

John Sherwood: I’d like to think I’ve been a helpful lone wolf! At Census, in the heavy-process environment, I’d build tools to make things work better—“skunk works” projects. If it took longer to process a card than do the work, I’d just do it. Sometimes I’d work late building tools, which is naughty—but sometimes it’s the only way.

Susan Brander: Going fast alone, going far together. Lone wolves can deliver fast, but I encourage my teams: if it takes longer to write/triage/process a card, just do it—but radiate information. There are two types of lone wolves: those like John, improving everyone’s lives, and those who think they're right and make unilateral change (like new architectures). The latter can be detrimental—you need to pull them into maintainability and group decision-making. One lone wolf added a new messaging system (org already had four!), and we had to have a tough conversation—and should have had it earlier. Early conversations, good process matter.

Andrew Murphy: It’s not just the size of the work, but how much it overlaps/interacts with the system—good frameworks help decide whether autonomy or process is needed.

John Sherwood: Hard conversations—sometimes someone’s new way is clearly better, but you still need to fight it, which takes effort and risk.

Andrew Murphy: Even if it’s objectively better, is it right for right now? In a startup, you sometimes want speed, not perfection.

Susan Brander: Maintainability costs must be considered—the perfect example was five messaging buses (instead of four) which is an exponentially increasing cost with no budget to migrate everything. Luckily, nobody quit.

John Sherwood: Recent example: someone spent a week building a fancy floating footer for a site. That week of work (and ongoing maintenance) cost a lot of money, but was the feature worth it? Sometimes devs forget time equals dollars.

Susan Brander: We hate talking about money with devs—and it’s to our detriment.

[00:34:40] Value, Metrics, and Difficult Conversations about Priorities

Andrew Murphy: The reason we get paid is because our work adds value to someone. The code doesn’t have inherent value. Richard Campbell said: "The value of code is not in its creation; it’s in its utilization." Sometimes teams work for months on a feature that moves no metrics. Having conversations about putting such features into maintenance mode is tough; these conversations are influenced by your prior relationship with your team and the overall culture.

Susan Brander: Relationships matter so much. Open, trusting communication makes hard conversations easier. Use a coaching approach—take them through your decision logic and include them in the decision-making process. If my team has missed context for decisions, that's partly on me for not providing it.

[00:38:53] How Can You Tell if a Team Has Too Much or Too Little Autonomy?

Andrew Murphy: What are the key indicators you use to tell if a team has too much or too little autonomy? If you join a new team, how do you tell if you need to adjust either?

John Sherwood: People gravitating to tasks they know how to do and avoiding the ones you want them to do. If they use questions as pushback, that often means they don’t have real autonomy.

Susan Brander: With new teams I start with DORA metrics—delivery time, deployment frequency, throughput. Also, friction or dissatisfaction (or resigned silence) means too little autonomy. If they aren't bringing ideas and enthusiasm, they probably have too little freedom.

Andrew Murphy: Friction is healthy if it's about the work; unhealthy if it's not. If teams refer to “Sales wants this” or “Product said no” (not individuals), it’s a sign of unhealthy friction and a lack of context—they feel constrained/restricted.

[00:42:48] Signs of Too Little Autonomy and Lack of Pushback

Susan Brander: Often when you hear “they won’t let me fix tech debt,” it's a lack of context. I love John’s point about people avoiding tasks or sticking to their safe spaces—big red flag.

John Sherwood: If people don’t push back on dumb ideas—like, “Did you think this was good?” “No, but so-and-so wanted it”—they’re not empowered. Teams need to be able to negotiate instead of just doing bad ideas because someone senior asked. Otherwise, it’s a clear sign of no autonomy.

[00:44:00] Decision-Making Frameworks and Saying No to Stakeholders

Andrew Murphy: What frameworks do you use to say no—so stakeholders know it’s authentic? I like a version of the Eisenhower matrix (importance vs. urgency, 0-10 scale for each). When saying no, I show which other items are higher priority and why—not just “no”, but “yes to something else instead”. This usually opens a more productive conversation.

Susan Brander: My approach is similar. Saying no is hard—often it’s “no, not now” or “no, but what do we need to make it a yes?” Stakeholders should be part of that process, not just recipients of decisions.

Andrew Murphy: Good point, stakeholders have valuable information and you could be wrong. Go into those conversations open for discussion, not fixed on saying no.

John Sherwood: If both sides come in fixed (“mine’s a 10/10 priority”), it’s a political battle. If both are open, it’s better. But you have to operate in good faith.

Andrew Murphy: It’s about prior relationships and building a culture of open, authentic, honest conversations.

Susan Brander: It works when everyone trusts the other is working in the organization’s best interest. It gets political when that’s not the case.

John Sherwood: Instead of explaining why your thing is a 10, ask why theirs is a 10. Maybe you’ll both calibrate your priorities.

[00:49:49] The Challenges of Autonomy as Orgs Scale

Andrew Murphy: Jared commented: in small orgs, team autonomy leverages talent for speed and quality, but in large orgs it leads to every team doing things their own way and trouble with tooling, deployment, etc. It’s the same as individuals vs. teams—fast alone, far together, but across multiple teams and at scale.

[00:52:15] Communicating the Value of Process to High-Autonomy Teams

Andrew Murphy: How do you communicate the value of some process or guardrails to a team that values autonomy and has a high-autonomy culture? For example, if you want to introduce Architecture Decision Records (ADRs) into a process-light org, how do you do it?

John Sherwood: The wrong way is just to mandate it. “You must do this or be fired” is definitely wrong. So, what’s the right way?

Susan Brander: I love ADRs. The introduction should always address a problem the team sees. Bring them into the problem-solving process (developers love that!). Suggest the solution, but stay open to better alternatives or adjustments. Frame it as an experiment with a clear review date—let them know it's not set in stone.

[00:54:13] Change Management: Problem First, Then Solution

Andrew Murphy: Walk people through the problem, not just the solution—otherwise, they’ll fixate on what’s wrong with your solution instead of why it exists. In change management, never do this in front of a crowd. Start one-on-one with the organization’s true influencers (you can often tell who they are by who people turn to in a crisis). Get their buy-in first—dealing with opposition individually is much easier than in a group. Only roll it out more widely once you’re aligned with those people.

Susan Brander: And if you’re new to an org, start with curiosity—ask for the oral history, figure out how things got to be the way they are.

[00:57:34] Context, Caution, and Avoiding Rigid Solutions

Andrew Murphy: Code and process decisions weren’t dumb—they were contextual, based on tradeoffs at the time. But beware using context as an excuse not to change. There’s a balance.

Jared suggested another prioritization framework—from John Cutler. If you have frameworks, always share! It’s great to borrow, adapt, and learn.

Lloyd commented to clarify: Andrew, “break prod to identify your thought leaders” was a joke!

We’ve reached the end. Thank you, everyone, for the comments, questions, and suggestions. Thank you, Susan and John, for joining me today. Always great to have people to agree and disagree with—these convos are so valuable.

Susan Brander: Thank you so much, Andrew and John. Great chat.

[01:00:43] Upcoming Livestreams and Closing

Andrew Murphy: Livestream watchers, in a couple of weeks: “From Burnout to Balance—Embodied Leadership in Engineering” with my friend and coach Dan Prager. We’ll talk about how your body and brain connect in leadership, and how stress manifests. It’ll be the last livestream for 2023, then we’ll start again in January with something super exciting.

Thank you, everyone! Have a wonderful rest of your day and weekend, and I’ll see you in two weeks' time. Goodbye, everybody.