Transparency vs. Micromanagement

In this episode of Definitely Maybe Agile, Peter Maddison and David Sharrock tackle the delicate balance between work transparency and micromanagement, particularly in hybrid work environments. They explore how breaking down work effectively, building trust between leaders and teams, and maintaining healthy communication patterns can create a more productive workplace. The hosts discuss why detailed task breakdowns aren't about control but rather about creating clarity and confidence for all stakeholders involved.

This week´s takeaways: 

•  Effective work relationships require trust flowing both ways between leadership and teams.
• Breaking down work into smaller, measurable pieces isn't about micromanagement – it's about creating clarity, enabling better learning, and building confidence in progress.
• Leaders need to be mindful of how they request updates and information.

 Listen in for actionable ideas and engaging perspectives that will help you build stronger, more accountable teams.

Chapters

• 0:04 Balancing Work Transparency and Trust
• 9:08 Effective Communication and Trust Building
• 16:31 Podcast on Digital Agile and DevOps

Transcript

Peter: 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello, dave, how are you, peter? Good to see you again. Good to hear you. Yeah, good to see you, dave. So we were just having a little chat about what today's podcast would be about, and what did we?

Dave: 0:22

land on. Well, you know, I think this is a topical conversation in many different levels, but we're working. I'm working with a couple of organizations that have both remote workers and not remote workers and I'm kind of back working with some teams. I've had some teams that I'm working with and what's interesting is the whole issue of work transparency, task breakdown, why it's there, when does it become micromanagement and overly controlling, and when is it not micromanagement but the right balance?

Peter: 0:52

Yeah, and it's a tough one because we don't want to be tearing over the shoulders, asking questions all the time Is it done yet? Is it done yet? Is it done yet? Are we there yet? Are we there yet and looking for those status updates which are just interruptive, largely very disruptive to the people who are trying to focus on getting work done. At the same time, from the leader's perspective, they're also usually getting pressure from other parts of the organization for much the same things. It's like everything rolls downhill right Well, and.

Dave: 1:24

I think so much of it is. There's a little bit of a sort of a distrust or a dynamic that we kind of need to help people break things down and look at the other person's requirements. So if my team lead is saying, what am I up to? And I say I'm doing test automation and the problem is they're not happy with it. They don't know what that means, they don't know when it's going to end, they don't know if that's good or bad, and so now a follow-up question comes and I begin getting irritated because my job is doing this and now I'm being second-guessed as to. Every single question just creates more distrust. I think we kind of have to understand that it's a fair question and we need to somehow find what the fair answer is.

Peter: 2:08

Yeah, and leaders can help with some of that. I mean, there's a couple of different pieces here, right? We understand that when we break work down into smaller pieces, it's easier to gauge our progress and it's easier to be able to say, okay, I've done enough, now let's move on to something else. Or I've learned what I can here. I need to now look at something else. I need another way forward. If we're looking at test automation, how much testing is sufficient?

Dave: 2:36

So that outlines one really critical piece, which is there is value in the breakdown of the work, whether it's I think you were saying you know if you go run long distance you don't wake up one day and go. Okay, I'm going to go run some tens of kilometers.

Dave: 2:51

You have that as a goal and you break that down and it's going to be, you know, five kilometer runs I have to do, and 10 kilometer runs and 15 kilometer runs before I can run something bigger and scarier. And I can measure my progress by how I'm doing that. And at no point when somebody asks, have you done a five kilometer run today, it isn't micromanagement so much as that immediately places me on that progress towards my end goal. So the two things that come into that one is I need to break down that end goal into the steps for our own. You know, just to be prepared. You know, properly thoughtful about the work that I'm committing to.

Peter: 3:28

This works at every layer of the organization, too. I was in an executive strategy session a couple of weeks ago, and I asked one of the executives there when he came up with a effectively a very variable task, something that was there was potentially no end in sight of this thing, and so I asked him, like how will you know that you're done, or how are you going to gauge your progress? How are you going to look at what are the milestones, what's the pieces you're going to look at as you move forward? How are you going to break this down? Because otherwise you could start on something that you're never really going to be able to know. It's so nebulous that, yeah, are we moving forward or are we not? How are we looking at? What are we using to measure our progress? How do we know that we're going in the right direction? If everything's just this massive chunk of work that we're just going to start off on, then that doesn't really help us.

Dave: 4:19

Well, it's interesting you're saying that, because then the next thing in terms of let me describe this as dysfunctional or not highly optimized organizations that you bump into is they take that big, nebulous objective and they go okay, screech, halt. What we're up to. We need to do some analysis, and now we spend six weeks basically scrabbling around and trying to put a plan together, and that's not what we're talking about either. I think there's that bit in the ground which is what steps can we take going forward which are going to give us more information so we're better informed, so we're better able to clearly define the objective and the route towards it. And if I think about that, whether it's a team taking in a particular problem and breaking that problem down into the steps that they need to do, or leaders taking a strategy objective, strategic objective, breaking down, what are the steps that get there, that breakdown of those objectives, that work is powerful, it has tons of value, it does and then the amount that you need to do it.

Peter: 5:17

it's just not getting lost in analysis, paralysis. It's like if I keep breaking down more than where, where do I need to stop? Where do I pass this off? And I think, bringing it back to the initial piece, I think we're in strong agreement that breaking stuff down is essential because we need to be able to understand, like, how are we going to look at this work in smaller pieces? But we still run into this friction point between the person doing the work, who needs the time to focus on getting that work done and doesn't need to be disturbed every five minutes with are you done yet? Are you done yet? Are you done yet? What are you working on? Are you actually working on the right thing? You said you were going to go off and do this, but what's that even mean?

Dave: 5:55

So those types and this comes to that sort of and how many times you sit and you know you listen to a team in a standup and somebody on the team is saying the example I always use is strategy. I'm defining the quality, you know, test automation, strategy, and that's just this thing that seems to take the whole every conversation. I'm still defining this thing and I think what we need to recognize in that is that generates uncertainty and unease in anybody who hears it, whether they're a manager or not. If I'm a stakeholder, I'm now more and more anxious every time I hear it, because that doesn't tell me, it doesn't fill me with confidence that somebody has a plan and it every single time I hear the same thing.

Dave: 6:38

I'm more and more likely to ask a question when is it? How is it going? Show me something. And so there's that reaction, that sort of realization that what are you working on is not. I don't trust you. Tell me what you're working on. It's more a case of help me feel confident that you guys have a plan and you're working towards it, yeah, and and help me give me the information I need to tell the rest of the organization.

Peter: 7:04

here's what my team is working towards so that I can keep that rest of that organization off your backs. While you get that done, there's a, I mean.

Dave: 7:11

I and I'd even like you almost don't need to know. You just need to know that things are changing and moving and the team is confident and they know where they're going. They're thoughtful about it rather than you know vague things. We're developing, yeah.

Peter: 7:25

No, no, that doesn't happen. There has to be more meat on it. So we were talking a little bit about the sort of the David Marquette turn the ship around piece around it, coming and saying like this is what I intend to do and this is it. But there's a piece there where there's like the sort of when and how and the pieces are implicit into that. I can trust you to do that if there's sufficient trust. But the trust rose both way. If I'm going to trust you to do that, you have to trust me with to give me the information I need to be able to support you in that right, and it can't be a one-way street. So that's um, it is. I think, and I think we keep coming back to that trust piece. The trust between the, the leadership and the delivery team has to be very, very strong for them to be able to, and it can't be a police action, right where now I'm going hold on.

Dave: 8:15

You said you'd work on this task and you said it would be four hours, and it's now been five. Why haven't you finished that task? It's now unraveling everything that you were getting beforehand, right?

Peter: 8:25

Yeah, but there's still a piece around it from a leadership perspective, so that you can set boundaries on that. It's like oh so you want to work on the test automation framework and you have some good reasons for doing that, but what are the? How long are you going to work on that? For? Can we say that you're going to spend the next two weeks investigating what the strategy is and then you'll present your findings back and then we can decide what we're going to do from there. Does that sound fair? So there's a, there's a piece there of understanding, or at least setting those boundaries of understanding, or at least setting those boundaries. If it is a nebulous task, helping somebody understand, like how to sort of put some sort of structure around it, yeah, albeit however simple that may need to be well and it's it's um I.

Dave: 9:06

I think I like the what you were. You brought in with the intention-based leadership and the um, david marquette's work around. You know the main famous in his book turn the ship around. But there's intent is one thing, but how you're progressing towards that intent is where that breakdown comes in. And as a stakeholder in some ways, we're using that breakdown to evaluate the progress that's being made, to understand the progress that's being made, and I think that there's some I'm trying to be very careful with the wording that I'm using so, from the person who has an intent coming to you and saying I have an intention that I will deliver this at this point, or this is the goal that I'm working towards, that person then breaking down how they're going to achieve it is less about saying, look what I've done and more about saying I'm confident I'm still going to meet my original intent.

Peter: 9:58

I'm confident I'm still going to meet my original intent, because I mean, the other side of this is I might say I'm going to go away and work on this strategy for two weeks. I might come back in two weeks and say I learned that what I tried to do isn't going to work. And I built out this piece but I can't use it. It doesn't work. It's not going to work for our use case. I need to go back to drawing board. I need another two weeks. I need another two weeks. I need to do something different from what this is. So I mean, that's the entire idea of experiments. It's not really an experiment if you succeed all the time. So if we're always looking for positive progress updates, even when sometimes we may not be able to solve the problem or we may find ourselves in a situation that what we built wasn't the right thing, so now we need to go back and say, okay, how do I rework this and where do I go from here?

Dave: 10:47

But it's interesting what you're saying there, because there's the work breakdown coming up with. You know, investigating something, that work breakdown allows me to learn from it and gain knowledge and figure out what worked and what didn't and what would I do differently, whereas if I spend two weeks being a bit vague about what I'm trying to do when we come to try and go and that didn't work, how can I do things differently? I'm losing that opportunity to learn.

Peter: 11:11

Well, the smaller I can make the chunk of time that I'm using to do the learning, the faster I can learn whether it's going to work or not. So there is a piece of looking at the work and saying what's the smallest amount of effort I can put into this that will allow me to learn whether it's going to work or not, and hoping that you've found the right way. That isn't always going to work. We just have to understand that too. It's like I should be wrong.

Dave: 11:34

Yeah, and I think that one the important piece is and this again comes the two-way thing is now, if I'm going to say, hey, this is what I intend to do, here's how I'm breaking the work down and I'm not going to achieve what I intended to do within the timeframe I committed to. This is going wrong. We also have to have how can we help that out? What are we learning, what's different, and so on, rather than actually, you made a commitment to this date and I hope you don't think you're going to slip that date.

Peter: 12:02

You've got to you know, and all of the things that comes with this sort of hard-edged managerial practice and it comes back to uh trust again, because, uh, if I'm in a psychologically safe environment where I trust that my leadership isn't going to sort of tear my head off, if I come to them with, uh, sort of the problems that I'm running into, then I'm going to sort of tear my head off. If I come to them with sort of the problems that I'm running into, then I'm going to come to them sooner and we'll have a more open conversation about it. And that's why it's so important to get that psychological safety into place and have the trust there to be able to have those open conversations as well.

Dave: 12:36

So if you're in an environment where it's low trust, where your management is likely to call that out, what do you do?

Peter: 12:42

Well, there's a couple of interesting pieces there. Isn't there Change the org or change the org. That's a couple. I mean, if you don't feel comfortable being able to work on something new or experimental, you're probably going to find yourself in a situation where you're not going to do it because it's too risky, and it depends how low that psychological safety is Like. Why would I risk my livelihood or my job if I feel that if something goes wrong, I'm not allowed to tell anybody about it?

Dave: 13:15

What I find interesting is I love the statement you just said change the org or change the org which let me just say that it floats around people's minds for a bit.

Dave: 13:25

But there's another element which is in like low trust environments. What I find interesting is the breakdown of the work becomes doubly important because remember, we talked about the breakdown of the work being are we on track, are we making progress towards a commitment that we are going to be held accountable to, and people will get very sarcastic if we miss that commitment in some way. Then the better I do the breakdown, the better able I am to manage expectations, figure out what's going on and so on. So what's interesting is, although I might not want to share that breakdown out, or at least limit what parts of it I'm sharing out, I actually want to do more breakdown, not less, because it gives me much better insight into where things are working and so on I can use a very old reference, you know rathakan type things.

Peter: 14:14

I use hours, not days.

Dave: 14:16

We get black and white here or a different level of CGI involved.

Peter: 14:25

But that's essentially what you're saying. So how would you sum this up in three points for our listeners?

Dave: 14:31

So, I'm going to speak straight away to the one thing that you've mentioned several times, which is trust. So we talked about this being is it to do with remote work and breakdown work, breakdowns tasks and so on? But the reality is that there's a two-way communication and in order for that two-way to communication to have trust, both sides are responsible for understanding what the other side is needing in that dialogue to build trust, and I think, I really think, that the way you addressed it, by bringing trust into nearly every part of it, is super important.

Peter: 15:00

Then if I look at.

Dave: 15:01

That's the step number one. Step number two is as somebody who's doing the work. We have to recognize that it isn't important that somebody is not looking over our shoulder. That's not the intent for understanding. We've broken things down and we have a bunch of tasks that we're making progress on.

Dave: 15:17

It's more looking at us to make sure they're confident that we are in know where things are going and we're going to shout out if we're seeing a problem early rather than late. So I think a lot of that is just confidence that things are going in the right way. It's a little bit like you know if you're driving across country. We just need to know that progress is being made rather than not hearing from somebody for days at a time before we find out what's going on, and then from the other side. The third point would be as a leader or a stakeholder, we need to recognize that when we're asking questions we've got to be careful about squirreling in and being too sort of direct, because that breaks down trust again. We've got to understand that continually asking for updates or challenging the updates and saying hold on, that doesn't sound like you're making progress or whatever it is is destroying that trust that may have been built up.

Peter: 16:08

Yeah, I think the one thing I would add into there is that your first and second point said the well-defined work will help build trust on both sides, because it'll aid with the understanding and it'll aid with the visibility of the progress and it'll aid with you being able to get to the learning faster. So defining the work well and breaking down is absolutely critical in both those aspects. Well, thank you for the conversation, dave. It's always fun. I think we covered a lot of really good ground today, so I look forward to the next one. So you can reach us feedback at feedback@ definitelymaybeagile. com, and don't forget to hit subscribe. Thanks, perfect. Thanks again, peter. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.