AA171 - The Shadow Backlog: How Invisible Work Derails Your Teams

welcome to the Arguing Agile Podcast, where Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando argue about product management, leadership, and business agility, so you don't have to. Welcome back to arguing agile. I was on the team once. And the director of the department, for all the teams, would go up to individual developers. And he would always know that he's about to introduce a work item that he wants done under the radar. Because he would walk up and he would say, Hey, buddy! The old, Hey buddy. That doesn't happen much though. Right? It happens all the time in product management. We call this thing, the shadow backlog the shadow backlog is real and it will haunt you. So this is your podcast. you're going to learn a lot today, hopefully. the first thing we want to talk about was this informal request is this old Pat on the back. Hey buddy, you're such a great, you use this example on other podcasts. So you're like, you're such a great developer. You can knock this out in five minutes. Or whatever your estimate is I'll just say real high, and then cut it in half. So I have referenced this before, I think, at least a couple of times. This is what I call ego stroking, basically, right? Somebody's gonna come to you and say, you're awesome, you can do this, you got this. And it won't take you long. And before you know it, days go by and you're still in the middle of this mess. definitely that is one way to spot what is coming at you In your shadow backlog because it's not defined up front in your actual backlog, and you're working on this stuff, right? Somebody told you to, or asked you to sometimes it's a bit more formal. The CEO or COO, somebody fairly high up, CXO, they'll come to you and say, I got to ask you to do this for me because we're going to show this at a conference that's taken place and it's important for the company, right? So you do it because you know, well, their management, that's another way. It's like, Hey buddy, but it's more like with a, a tone of, you want to do this? Hey buddy, or else. Yeah, Exactly. So that's another way of spotting uh, the source of uh, items that are coming into your shadow backlog. I've seen managers, direct managers in matrix organizations where the product management people and the developers are, owned by different people, different hiring managers in the organization. And then the hiring manager says, well, this is my person. They're just going to knock out this thing real quick and then there'll be available for but they haven't told anyone Right. it's taking time out of their day. Yeah. And they don't talk to product people because of that reason you mentioned, right. They're completely separate. You said, they have their people, their resources as they call them often that are seconded to the project. So yeah, they'll pull their favors. And yeah, that's another way to see shadow backlog. You don't actually see it though. Ironically, right? It's, they're kind of lurking and it's taking bandwidth away from The other, the other part of this, the, informal requests at ad hoc system of interrupting people basically that I've seen is I told this story on a podcast once a million years ago, We were integrating a vendor product into our mobile product. at the vendor company we were using, they had a development team that was producing our product and somebody thought it would be a good idea to have a shared Slack channel, our development team and their development team together. But I believe it ended up being managers and project people and whatever, what would end up happening is multiple times throughout the day, somebody would ping our developers in that channel and say, Hey, this thing. You know, this API request is coming back with this. Can you change it so it's like this or this this mobile transaction is passing these variables. We want to add another one. Can you make sure that you're accepting it on your side? I can't remember what it was like, little things like that. They would, and then our developers would go in and start making changes. And then you would say like, Hey, why are you still working on that? Like we are, I thought we were releasing that. Oh no. the vendor team asked me to add one little change. Without discussion with the product people, none of that, right. Without discussion. And that is very prevalent. I mean, anytime you have a channel that's open like that, it really needs to be very carefully curated. Otherwise you are going to run this risk, especially if stakeholders are involved because that's their conduit into the team. Yeah. Right. They're like water. They're taking the path of release resistance because they are perceiving going through the quote, normal backlog channel as you know, overly burdensome. Prohibitive sometimes you're overly bureaucratic I got to have an hour long meeting with your product manager. I don't want to do that. Or they just don't know what the correct process. Right. Yeah. That's very likely. They don't know, but just like water, I mean, it will fill up the space that's there. let's just briefly talk about ad hoc, right? So ad hoc, it's fine to have ad hoc, right? You solicit feedback from your customers and they can, they don't have to be cadenced or anything like that. they can give you the feedback at any point, but it needs to be triaged properly. Right. It needs to be carefully incorporated into the main backlog. So it doesn't end up just being worked on out of sight, out of mind in a shadow backlog. So I, I don't want us to kind of say clamp down on that. Oh, that's not what we're saying here. Right. We're just saying there's the right way to do things. So yeah, I forgot what we were going on. I was going to say we, we were just about to say, oh, it sounds like you're not a team player. When your boss comes to you and says, I need you to do this one thing. And then you say, have you talked to my product manager? Like he's he would be interested to know what when it comes yearly review time you know, same, same thing could happen if you say, well I request you to go talk to my scrum master, same thing. Yeah. Except same thing, except we can fire the scrum master. Because they work for a development. Right. That's true. So there is that, there is that real possibility that you're, you're not seen as a team player. You're not doing what someone's asking you for. You're not a true collaborator. That's right. Whereas the reality is you should really be. Not doing that. Listen, Ohm we got to move fast. We can always be talking about process. This process that that's the other way I've heard. Yeah, it's, I mean, it's very gaslighting, but speed is everything. Yeah, that's how I've heard people justify this, this, what we're talking about now, this informal request system of you, you, you, you scratch my back and I don't fire you. There's no benefit in it. I mean, it's just it actually is making your day worse because now you're failing on everything else you committed to, Right. Yeah. There's really nothing good that can come out of it. If I'm going to be a little more like the informal request network, altering the products and whatever, I'll be harsh on that one because rightfully so like I should be. Workarounds and quick fixes or hot fixes or, you know break fixes. basically something breaks in production and we now have to have the fire drill to put it out. this is one of the categories where like of course We should stop what we're doing and fix that You know the only I feel nobody gets into trouble with prioritization with this one I feel where people get into troubles when they have systems where this stuff happens all the time Now you can't be a your commitments because you you have no control of this. Well that speaks to Volumes to the quality or lack of it of the process as well as the product. Maybe so. But there is something else there, right? If you're fixing things in production. Okay, you have to fix things, so fine, do it, but at the same time, don't neglect documenting things, right? Don't neglect reflecting back and figuring out why is it, could we have avoided it? How can we not repeat that again? So all of those things have to follow and typically you find that because you're at the tyranny of time, right? They don't follow because you're just break fixing after break fixing. Well, that's the thing about quick fixes is they're done quickly. Who's to say that like that ever makes it back to the permanent code. Like I have seen quick fixes that are applied in production. And then the next time a release rolls out into production, the thing gets broken again because it was never really fixed. yeah, exactly. Yeah. I've seen that for sure. Especially in products where. You can do that through scripting or some other means or manipulating SQL or whatever it is, right? So that's really masking the symptom, right? It's not fixing the root cause. But again, it comes down to sound engineering principles there, right? If you're going to fix it, fix it, but then do a proper fix, put it into the code, test it and all of that. Right. Unless it's pressure tested before it releases again, you're going to find that it's never really fixed. But allow me to make the situation way worse. So now our team that does feature development, we say, well, we want to unburden them just to be purely feature development. So we're going to hire this other team that they're just going to do break fixes in production because it's become such a problem. So now this other team that is constantly. In the code, this new team, doing break fixes, maybe an offshore team, it's doing break fixes and responding to support issues. They're in the code base, fixing issues that come up while the other team is introducing new features into the code at the same time. So both those teams are working at the same time and now. You see where the, like the, you're on the Titanic at this point and like knowing what's about to happen, right? Yeah, that's a better analogy. I was thinking, well, you're trying to change the tires on a car while it's being driven on the highway at 60 miles an hour. You're trying to change tires on the Titanic. Yeah, that's right. While it's still. Halfway in the water. No, it's, it's pandemonium at that point because people aren't talking to one another, especially if you have dedicated teams. So how do you, how do you survive in that long term? I just can't wait for the person that's going to comment on this and be like, Brian, that scenario is ludicrous. No one would ever do that. Like I only bring that up because I lived through that exact experience. I like to talk to that person. Cause it happens all the time. Oh boy. We have so much, we have so, it's so unstable, like quality is so bad that we have to get another team that their job is just to do like quality improvements. But basically bug fixes, they'll wrap it is quality improvement I've seen Not, they don't have entire teams to do it, but I have seen them dedicate one developer. Well, that's the on call developer this week. Their job is just to catch all the bugs and garbage that blows up So in the former where we have a separate team or even a developer, it leads to this behavior from your development team that let's just, Scaffold it up. If it breaks, they'll fix it. Right? And that's terrible. Because you're releasing code that's not of quality to begin with. I'm a big fan of you build it, you run it. Oh, you're not a big fan of we, we Throw it over the wall? We'll fix it and document it later? Because later never comes. Oh man, somehow this needs to be a separate podcast. I want to let my feature team just develop features and put all the maintenance and refactoring off this other team. Like whoever thought that was a good idea. Like it needs its own podcast. I don't know what it would be called. Doing a whole podcast on that. Cause there's so much there. It's not just people that fix your stuff. It's also potentially people that are putting your code into production of your team is not right. these teams will go fix things quickly because well. They're the ones in charge of putting things into production. And if he breaks, it looks bad on them. So they fix it up, but he never gets back to the dev team and doesn't get back to the main branch. And that's the problem. Learnings don't get back, nor does the skill get back, which leaves you with a whole nother problem. Correct. And so potentially you could have not a shadow backlog, but multiple shadow backlog, we're already very, very, very close to be talking about technical debt right now. So let's just launch straight into. The technical debt backlog, at more than one place so I'm not trying to call anyone out, but more than one place, the developers some places the developers will revolt and say like, we must fix this. We can't wait anymore. Sometimes they'll try to be proactive overly cautiously proactive to say like, Oh, we've got to have a, a completely separate roadmap to, of how we're going to fix technical debt and improve the systems and bring them up to date. Whatever SPAC or current version, whatever it is. So they'll try to have their own parallel backlog because usually the people that lead engineering at a high level in organization, they're pretty much charged with like, Hey, how can we have all these systems that are falling over they get pointed out to say you're doing a bad job because they're the ones looking at quality dashboards and things. I mean, in reality, it's a partnership between engineering and product management that resolves the technical debt. So it's not, it's kind of not fair just to point at the engineering leadership to say you're not doing a good job cause you could have, you could have product people that completely don't understand what it takes to keep the system moving. They're completely disconnected from what's happening with the technology under hood. And they just I was gonna say go to lunch all day, but also they just asked for features. They don't want to do any technical under hood stuff. They don't understand it. They don't want to talk about it. I've been in a room with executives actually that are like this. They only want features. They don't want to talk about the systems under hood. They don't want to pay for things. They don't want to spend any development time on it. and honestly, like if you start talking about anything like this, sometimes you go into the weeds to talk about how a feature would be solutioned. Yeah. Like people do, right? They'll zone out. Like I had a guy once who would get up and practice his golf swing. He would do shadow golf swings. in a conference room. When the developers would start talking I don't know if I'm going to keep this story in the podcast. It's so good. I can't, I can't stop myself from telling it though. So he's an executive, right? They brought him in I think 'cause he had like deep ties with a particular customer we were trying to sell anyway, and they're like, we don't know what to do with you. You're gonna run development department. So he became in charge of the development department. This C the c-level exec. I don't remember what his title was. Anyway, this guy comes in, he could not care about technology at all. He, when we would, he would practice his golf. I see. I still remember him. Practicing his golf swing. I still remember him practicing. Well that just tells you what the company thought. Yeah of course. But I still remember him practicing his golf swing while we were talking about something highly technical that needed to be solved before we could launch some feature or scale the system or do something basically. And He could care less playing golf in a corner. He didn't last surprisingly. I remember talking to somebody years later after that guy had left who was like a senior developer who worked their way up in that company. And I was like, man, that guy. What a piece of work that guy. And then I remember the person who is developer was like, actually, it wasn't that bad. I'm like, what are you talking about? What were you on a different planet than I am? Actually, it wasn't that bad. I think wasn't that bad means I can do whatever technical debt I want and he'll, he won't challenge it because he has no idea. I think that's what it meant. He would either ignore what I'm doing and implicitly just approve it or he'll rubber stamp it. He'll just say, yeah, that's fine. It sounds good. I think that's what he meant by he wasn't that bad is that he didn't get into details or challenge you about details because he couldn't. Right. But again, that guy had no business in business at all. That's that was my opinion on him and I still feel that way. He's probably out there winning the U. S. Open right now. we may or may not be returning from a Segway right now. About golf. But yeah, the refactoring in order to solve technical debt, everyone can pretty much understand, like developers, like they, they see it happen. They, if you're, you're not going to give them the space to do it and it's painful enough, they're just going to go do it themselves, completely understand that. No problem. But the optimum is the underhood optimization that you could basically spend forever on. Like that, that is the other place that I've seen this goodness. Yeah. So tuning, right. Tuning and then forever refining and polishing. Right. Right. Gilding the lily. Right. So yeah, definitely have seen that. Especially, so there's two sides to this though, right? I have seen some developers that are so passionate about their work that they just want to keep improving. It can be better. I can make it 2 percent faster. I can optimize the queries. Nobody really is complaining about it. Right? But they're into it. There's that side of it. The other side of it is Save that one, because that one, when we talk about personal tasks, Oh yeah, yeah, yeah. That's definitely in that category. Is you guys are not taking this feature seriously enough. I'm going to go show you how good it could be. I've seen people spend nights and weekends doing that for sure. You're not going to get time in the backlog. We've talked about it. That ship has sailed and they go do an anyway on nights and weekends. And now they're burning themselves out. Is burning them out. Right. But I've seen people do it during their work days and they're not doing the committed features. Right. So there's two sides to it. Just briefly go back to. This idea of having the break fixes under like one leader manager and net new features functionality under different one, maybe product, right? Of course, they're going to protect their turf, they're not going to talk to one another. The person who has all these fixes to do. They're not going to go back to the product and say, can we just fix it? So that our processes and so forth. So we don't have as much to fix because well, they're employed. So it's their vested interest that they're protecting. I think it goes back to that whole org design thing again. Yeah. You know, how you organized in your company, right? I like the, there's so much to talk about here. I want to have a whole podcast on technical debt. there's so much here that I want to talk about. we have yet to even talk about the. Maintenance of legacy systems and, estimates on legacy systems when the people giving the estimates are not the people that built the legacy system, you bring on people to maintain a legacy system where you have new developers and the old developers are gone. Like your estimates are all garbage. You know, it always takes a long time to do something and you resist doing stuff to that other system or. Migrating it or touching it or spending any time that involves the the cost quality that you hadn't noted before. Like there's so many things I want to talk about in this, in this tech debt category. I think on that legacy one, oftentimes because legacy, I mean, it's old technology, right? And people that are well versed with the latest technologies have this Dunning Kruger effect that they're thinking. I can do that. I mean, that's not, that's old tech. I can do that. Yeah. Right. I can read COBOL if I have four hours to read the code, it's not that hard, but that's where they're wrong because they don't have documentation or worse yet. They don't have the domain knowledge. To fix things in whatever the old, the old languages were. It's not old tech. It's lost tech. It's lost tech. The long lost tech. What program am I thinking of? the technology is so advanced that the human beings forgot. I don't know if it's like Wally or one of the, basically the P the people are living, is it twilight zone? I don't remember what it was like the people are living on the ship, but the people that are living on the ship are like far removed descendants from the people that built the ship and they lost the ability. To work on the ship and you know, that's real that is real when you're working on legacy. That's this. Yeah, that's exactly this So their estimates though coming back to that right their estimates are very ambitious. I could fix that in a day Yeah, and 15 days later, they're still into it, right not their fault necessarily, but that's reality. It happens all the time Yeah, yeah going down a rabbit hole, trying to figure out That like that exploratory work as like I work with many, many developers who do that. and you know what to be honest, I do that. I spent two hours on something that wasn't working. Normally, I won't spend that much time on two hours is an immense amount of time for me in one Pomodoro like one go for me, like two hours back to back straight uninterrupted sitting at my computer, like two hours is amazing that I can pound out a bunch of stuff that's super helpful to me in two hours. But I had this two hours I spent trying to figure out why an API response wasn't coming back properly. Total waste of time. And even when I'm doing it, I know I'm spending way more time, but it's like the next, the next hit is going to work. The next hit is going to work. You know, the next thing is the gambler syndrome, right? You're really is the next spin is going to land the ball exactly on the number I'm gambling on. It really is. But the idea that you need to keep this stuff in a separate roadmap and lobby and do whatever and have a big bang or, Oh, we have to have a big project to do this stuff or introduce a new database or cut over to a database or whatever. No, if you can't do it as a normal part of your normal stream work, it's highly likely that you can't do it. Right. Technical debt is why I think it should be a different podcast. We will do one. It worries me as a product manager who used to be on development teams. It worries me because is a product manager who's empowered with prioritization, like that's their role. Do they really understand? what being versions behind or what being on this old technology or what being on several versions behind on the technology or not migrating to the latest technology that's purposely built for this or being on this old version of the language, do they really understand what that means? And do they re and can they illustrate in front of management when management is playing golf, that golf swing guy who doesn't know anything about technology, couldn't care less running a tech company. Couldn't care less about technology when they're dealing with that flippant attitude. Can they make it matter? The product manager, can they take all the concerns of the dev team and understanding of technology and make it matter to that person? Can they weave that story and make it matter to that person? I'm super worried when I, again, like most of the product managers, the advice that you'll see online is partner with your engineering lead. Have them help you do it. Believe your dreams, get lunch all day, beefcake, that's not good enough. Listen, you're describing a unicorn of a product manager who can actually do that, right? I found, I mean, there are very few that are technical enough to understand these things. Right. So yeah, we were talking before the podcast about teams wanting to. Upgrade To a new library or something like that. The product people aren't necessarily aware of the reasons why that should be done or not done. Visualization libraries is what we're talking about. But it could be, it could be anything though, right? visualization libraries are a really good example because they're in your face. six months. They're outdated. They move so fast. exactly. So I think it's a tall order. How do you partner with the engineering lead? If they the type of people that you're describing, right? It's hard. It is hard. the only other thing about technical debt, kind of, that's wrapped up in the legacy systems and technical debt to bring up here is, and it's only tangentially part of the shadow backlog is sometimes you will run into these hero developers. these wolf developers who have found themselves Outside of a team Also the other moniker that is relevant to these people is the Paris Hilton developer. Let, I haven't heard that one. Let explain, let me explain. I'm glad, I'm glad I can be the first one to lay this on you in this podcast. Yeah, I haven't heard that. you know the Wolf developer, you know that? Yeah. They work alone. They're only working on the latest fire. They're seen as a hero.'cause they go from fire to fire. they're the people that can do, do things. The Paris Hilton developer is like that. they're famous for being famous. They're at all the parties, they're at all the release events, they're at all the launches, you gotta get them in the room to have them in the room, but they're not really part of any team, they don't work on anything significant that you can remember, they just happen to be there whenever significant things happen, they're a developer that's really good at being there. When significant things are happening. So it's interesting because I actually have come across this. This should be a podcast. Our podcast should have been the Paris Hilton developer. That's a good title. I've come across architects that fall in this category. They go around. I don't know if architects can exist in any other category. Fair point. They go around with their little dog in their purse. Yeah, they go around looking all important. You know, they go ask the teams that they're working on. Offer their two cents. No, don't pick up the glass that way. Pick it up this way. Not that it matters, but you know, yeah, yeah. Pick it up and then that's it. They just hover around. They butterfly in and they butterfly out. So yeah, I've come across those guys. Oh, I know. Like when I, when you say it out loud, you're like, actually. I do know a few of those people. But you know what they do is they're really good at sticking around for a long time. staying in the media, What things is Paris Hilton good at staying in the, staying in the public eye, staying in the public eye, being seen. Right, but also knowing where to be at a certain time. You can't do that unless you're hoarding all that knowledge that someone might eventually need. Great point, yes. so again, the Paris Hilton developer is what I, my example of someone who's hoarding knowledge for their own benefit, not necessarily for anyone else's benefit. the quiet, Developer that kind of just goes from team to team and mentors the new people, walks them through the code, does code reviews for other people. Like those people don't get any of the glitz and the cameras that the Paris Hilton developer gets. they don't get to rescue the situation, right? This person does by hoarding knowledge. They do rescue the situation, but when they do it, they attribute it to the team and they don't take it personally on their own. Actual team player. But Paris Hilton is looking to be in front of the camera Exactly. Yeah. Don't be a Paris Hilton developer is what we're saying right now. Exactly. Just carry your lapdog in your purse. Not, not all that knowledge. Well, This is going to be a hard one to segue from, but I'm going to try. We said we would save personal tasks until it's own category. Do you remember why we said we would save personal tasks? Oh, no, it was, I had a solution. And then we chose not to implement that solution. So I'm going to do it on nights and weekends. That's right. Yeah, that was, so those kinds of personal tasks where the product manager says, I'm not going to do this. I don't want to spend time on it. Like it's outside of the sprint goal and it's outside of any of our goals for the quarter or whatever, right? And like, it doesn't line up with any of our goals, so I don't want to spend any time on it. And developer says. Well, I think it's important. I'm going to do it anyway. I'm going to do it on nights a week I'm going to show you that people like listen. I'm conflicted on this one and I'll tell you why because I do this. That's my confession. I do this I don't do as I do I do nights and weekends development To say, I'm going to go figure out how to query this database to go get the exact right data to use in this thing. And then tell the development team Hey, I can get this query. This is not exactly what we're talking about, what I'm doing. Is implementing like a feature or, or basically anything else like a, an NFR, a technical debt thing, something that I think that we're falling behind on. So I'm going to go do it. Like I, again, I, I have where I do things like this is I'll say, Hey, we don't have a, we don't have a program to query something from this database. And query something from this database and then put those two things together and send out a report and so that we can make this other decision and I could ask my development team to do it. It is development work, but it doesn't line up with any of our quarterly goals. It really doesn't take that long to get the data. The only pain is it's a manual one time thing when I want to go get the data So it takes me 30 minutes or whatever But if I can spend an hour and a half in the middle of the night and automate the process Number one I can make life easier on everybody that's looking for that data Number two, I don't have to ask the development team to do it. Number three. I don't have to lobby To make it a quarterly goal to do internal automation, to make whatever X, Y, Z, easier, whatever process I'm trying to do. You know what I mean? So like I do this all the time, so it's tough for me to talk about this one because I certainly do. if you're doing it, this doesn't matter if you're doing it or developers doing it, there's an opportunity cause you're doing something. If you're doing it out in your own time, evenings and weekends, you're still burning yourself out. A hundred percent agree. So I mean, I'm a little conflicted on it for a different reason. Are we really constraining the innovation that people can bring to the table by not allowing this to happen, right? So maybe, Maybe one thing to consider is reserve a bit of time every so often and have a hackathon. Let, let teams come up with basically what Google does, right? Let the teams come up with some innovation in that way. So that's their channel at the same time. You can protect the main backlog and make sure that people aren't distributed across seeing an unseen work. If you will. I wonder, I don't see this going away. This is what I'm saying. As long as people are there, they won't go. Right. That's what I'm saying. I don't see this going away, but I wonder 20 years from now. If the broad view of product development I wonder what the number of loading your developers down per week would be. So like what you just said. it sparked an idea in my head, which is like, maybe I don't want to load my developers. Like in America, 40 hour workweek, like that's the standard. some people will say 45, they're trying to squeeze a little more out of you, whatever. Right. I want to think like, what if the work week in the future is like 25 hours and we're reserving another 10 hours ish, right? Cause some of those hours that are spent at work are spent on purely administrative stuff that's not, it doesn't advance your work at all. So there are some hours to do that. Let's say we're only going to load developers down to 25 hours a week, and then we're reserving that other 10 hours. Whatever, eight hours, six hours. We can negotiate on a number, but we're reserving a number of hours per week on just things that the developer sees that need to be corrected, that they can just jump on because again, they're the people closest to the problems. So it does make sense to reserve some of their time for this category, this personal task category to reserve some of their time to counter what I'm saying, which is I do this, I can't expect my developers to not do this because if I'm doing it. And I'm leading the team. I'm basically setting the example that people are going to see, and they're going to follow my example. So I guess what I'm saying is I am leading and propagating this. So can I alter the system? Cause I can't alter my behavior. My behavior is set in stone. Like the real, that's the real fix here is Brian. Don't do that. Or if you do it, just shut up. Like don't, don't tell anybody. I almost cursed the bucket. Don't tell anybody that you do it because then other people see you doing it. You know, this is the same thing as like, if, if, if I work for a boss who never takes vacation, now I can't take vacation. That's the same thing that we're talking about here. It's the same effect. But the personal test one, if you know that you have this problem, if you have a problem, where's Mike Miller when I need him this personal testing, like maybe you can reserve some capacity, just like you would reserve capacity to deal with technical debt. Okay. We're going to reserve 20 percent of our. points in the sprint or whatever to know that technical debt stuff's going to need to be worked on, let engineering choose what that's going to be, and we'll drop it in. If we don't have something up in the roadmap, maybe this is the same thing we were going to reserve some time. if you don't need to do any of this stuff, then you just work on normal backlog items and everything's fine. I like the idea of reserving time because one of the other things you can add in that mix is skills development. So reserve whatever hours you mentioned, right? It doesn't matter what the hours are. It doesn't matter. You figure out the number. for personal tasks as well as skills development, right? Obscure yourself, learn something new. I like that. Yeah. I like that too, but it doesn't because really there's no room for that in day to day. You think about what teams work on, they're always working on either the actual backlog or some other version of it, which is what we're calling the shadow backlog. We probably could think about this number off the top of our head. Like every additional team that you're on, you add 20%. So, right away, you cut your utilization. if we're going to talk about the dirty four letter word that's called utilization, we're going to talk about that for a second. let's break out like, okay, you're a developer on one team what is your utilization to that team? Just off the start. Are we just going to say like 15 percent of your time is just pure overhead, like just on one team meetings and stuff like that. let's call one team 20%. Being on one team, 20 percent of your time is already gone. So, that's 80 percent potentially dedicated to development work that you do. Now, let's say, we're gonna do this personal task slash learning thing. So, let's take 30 percent of your time and dedicate it to these things. So, either personal tasks you have to do or learning and development. So, now we're down to 50%. Of your time dedicated to actually servicing the backlog. So now we're at 20 hours a week, basically. I think that's fair. We're going to take care of your L and D. We're going to take care of your time to work on the stuff that you're super passionate about. We're going to take care of the time to work on things that you would like to, to workshop and prove concept that the hackathon type of stuff, building into your schedule. I love this idea. You're basically exposing the skunkworks at that point, right? You say, well, don't hide things under the table. We're giving you the time and you can make it fun. You could make it rewarding for them. You know, if they come up, we said that's basically the google thing. Google have been doing this for a while, you know that on fridays the developers do this sort of thing, right? But I like the idea. Well, the point of all this is I want it all Transparent. I want it all clear. So like maybe I'll carve some time out in our sprint review for you to bring this work forward that you're working on and if the sprint review is not the appropriate place because maybe the audience is not the appropriate place, then maybe the engineering team itself has like the hackathon review, like maybe every month or every two weeks or something like that. Maybe the engineering team just the engineers in the matrix of engineering. Maybe just the engineers go to a across team engineering. Session where they share what they've been doing for this type of stuff. I would keep it separate from the sprint review because you possibly have stakeholders in the room. Well, it depends on how big your company is. But yeah, sure. If you're small enough. I mean, obviously if you have. 60 plus developers in your program okay, like that. Yeah, yeah, I would agree with you yeah, let's do that separately. I, as a product manager Will become the person who goes to that optionally like I'm on the optional invite to see what cool new things It's for them by them. So yeah, it makes sense But they're also As part of personal tasks, that's their time to pitch things So sort of like it could be Part demo part pitch meeting at that point anyway, I think so too. Yeah. I think this is good. maybe I can try exploring some of that to the extent possible. Yeah. Even if it's theoretical now, just treat that as an experiment. Try it out. in personal tasks. We kind of talked about developers trying out new things. Talking about personal tasks is developers researching new technologies, or we talked a little bit about new libraries for charting and stuff like that, like new ways of querying, you know what I mean? New technologies, that exploratory work of like, Oh you know, we know that this thing is upcoming in the backlog. They're going to ask us to implement. And in advance of that, we have to try some different ways. developers can go down a rabbit hole on that exploratory work proof of concept work like real, like things that are not directly in our product now, but maybe in the future, again, people listen to the podcast. know, I have a label in my ALM system. You can put a label on whatever system you're using. I use Jira, but it could be any system that you're using. I put a label in there for capabilities, which means my team is doing exploratory work. this is not feature development. This is not CapEx development. This is OpEx. The team is exploring something new. It may turn into nothing. It may turn into capitalizable features. I don't know yet. I have a tag for that because I want my developers coming to me and saying, we need to do this. And put some time into it and lobby for it. And then I'll put it in the backlog and we'll order it and it'll pop up. But not a lot of product managers can have that discussion and understand the need and understand the pitch. And again, like you said, be able to pitch it back to the business because they're paying for it. So the reason why exploratory work goes under the radar is because Any break in anything I just explained your, your ability of developer to explain to me, the product manager, me, the product manager's ability to prioritize it in line with the rest of the stuff that we have me, the product manager's ability to sell it to the people above me, like any, any breakdown in any of those things. I mean, assuming you didn't have a product manager, right. Right. Yeah. So yeah, you're right that developers have a tendency to go down the rabbit hole, especially tool selection. Let's use that as an example. That's a good example. New tools coming up, right? Well, let's try this new fine, shiny tool because that's the latest thing and I hear other people are using it. Maybe there's some value in that if they try it out. So put my guard rails around it if you want, but put it in the main backlog, right? And yeah, you got to be able to stand up and say, we're doing this because you can't do that. That's, that's the guard. The guardrails are, it's in the backlog. It's been prioritized. We're working on it. And then every day you're working on it, you're. Kind of giving your feedback about Hey, this is what we found. Maybe not every day that we're working on, but I mean, every couple of the regularly, yeah, regularly in the background, what I find is like a developer wants to be left alone with a new tool to just spend like, again, me in the middle of the night spending two consecutive hours. Working on this API. I mean, how long, like two hours again, for me at my level of where I'm at is extreme amount of time to spend on one task. I don't know about different people's levels. Two weeks might not be extreme for somebody else. I don't know what that time is, but if I'm doing scrum and I'm in sprints and you've spent two weeks. Exploring something, man, you better be a top to bottom expert. Wiz have several proof of concepts like coded and working like the, my problem with this exploratory work, not being in the backlog is the developers. Desire to just be left alone with a piece of tech for an extended period of time to really learn it inside out. And that is where we get into trouble. It's I can't have like, I, as a product manager, I cannot have you disappearing down a rabbit hole for the whole sprint unless that expectation has been set when we pulled the item up, So I agree, first of all, right. If you let it go, this is your analogy of water applies here again, because people are just going to keep. Playing with the new shiny tool. The other thing I've seen that kind of really odd is I've seen developers take leads, let's say, or even architects say, We need to do an exploration or a spike sprint. We need to do a spike sprint. How am I going to sell that to leadership? A whole sprint, 10 days, let's say, times six people. Well, we're going to do all of that just for exploration. Maybe we need to think through this and say, what's our opportunity cost? What are we not working on? That's really bringing value to the business. So again, it's not black and white. Not saying no, just saying, well. You know what gives right and having that discussion with those people above you leadership. And so can we take a little bit of time? Yeah. So it's a negotiation with your teams, plus with your peers and your superiors, right? Have you seen the Jeff Sutherland tweets? About you should estimate spikes. I think I have. Yes, I have seen that. The reason I was looking for the post from Jeff Sutherland about spike work, sizing spike work is because I think spike work needs to be just time box and that's it. You can find out what you can find out in the time allotted. And then if you decide that you need to extend the time box or create another time box or whatever, then you create another time box of the same length. And then you can get around dealing with the size of spike. I guess you can get around that also by just saying all spikes are the same size. Spike should be able to be dealt with in a day or two, right? But that, I was looking for that post because I was going to say Spikes, the topic, all alone, separate podcast. That's what I was going to pitch. Oh, yeah, yeah. That's why I was going down that road because I, and I would open up with that. I'd open up with that tweet, basically, to say, Jeff Sutherland says, Hey, you can't estimate it if it doesn't have an estimate. So everything needs to have an estimate. That's the policy here at Brian and Ohm's HR company. Whatever happened to the software company who said we need to have an estimate the category here was exploratory work, basically blowing up and becoming part of the shadow backlog because you never give you developers time to do exploratory work. I wonder about teams where exploratory work is a big part of the shadow backlog. I wonder how those teams do their refinements because a lot of times in refinement, we're pulling up systems and we're calling in experts and we're getting their opinion on basically a lot of the answers for exploratory work. we're making room for them during that time to come in and give us answers. That we otherwise would have to dedicate a person to, and that person would have to go chase down these things and whatnot. So, I do this stuff in refinements, which is different than sprint plannings. Where sprint planning assumes we already have these details. So I would assume you're not doing a lot of that kind of stuff. You know what else in exploratory work that can blow up is proof of concepts. Oh yeah, definitely proof of concepts, especially if there's no scope bounding. Right. And people will just keep working on it. Often there isn't in a POC. It's very ambiguous. So that needs to come with, how do we know when we're done with the POC? I mean, some sort of DOD, right? Some sort of definition of done on the POC. Plus having those frequent reviews of the POC and asking, is this enough? Or do we keep going? Right. I think you just nailed it right there. that's how we know we're done. we demo it on a regular basis, Honestly, more frequent than the sprint release, like the normal sprint and cadence. I think it should be more than that. And then we ask, here's the work that was done. Are we done? So on the cadence, right? We don't even need a cadence. As soon as you put a piece of functionality in there, get feedback. You say, well, here, we just added this. And at some point ask what else was missing. I like the world that you're living in because some other developers live in the world of, I'm just going to keep throwing stuff. and throwing stuff in the release pipeline. well they may see that as their actual work and the actual releasing to production, the pipeline, like executing the pipeline and having it roll out to the environments. They might see that as additional overhead or somebody else's job. If they can ship it to another team, like a DevOps release team or something like that. So you have a development team that just keeps throwing stuff into the pipeline and never actually running a release. So then when they finally go to run a release, you got all these merge conflicts and stuff that's got to be figured out it's a big disaster because they're not releasing I only call that out because I did live in that world in a previous part of my career. I don't live in that world anymore, so I don't talk about it anymore. Right. But it's, well, that world is real. It's very real. Yeah, it's real. And a lot of people live in that world, so just be mindful of that. I think that people listening to this should not walk away by kind of taking just one thing that we say, right. that exploratory work. Okay. Well, gotta be careful. No, we're not saying that. What we're saying is. It's on a case by case basis, right? How quickly do you need to do that POC? What do you need to learn? How fast? And size work that way, but put it in the main backlog. Yeah, that's what we're saying. Yes. if your policy is, we don't pull anything into the sprint to get done unless it has points. So now we have to have this big heartache about. Do we point our spikes or not point our spikes? Well, I don't know like You don't need any of that like pick a number throw it in there Or don't pick a number don't pick it up Don't pick a number and just time box it and you're done with it Like you don't need to be complicated about this. No, that's exactly right Yeah, and if you time box it or if you don't land it, well fine extend it, right? Okay Based on feedback. That's all I mean. Yeah Enough said like I don't Again, there's a reason I could have a whole podcast about that specific topic Cause people get ridiculous. Like ridiculous? Who cares? So dogma, the point of the spike is I need the learning. I need to know I need that ambiguity knocked down. So I'm basically willing to pay any costs to have it get knocked down until you tell me until it gets too expensive, like until it becomes so expensive that I'm not willing to pay it anymore. Right. Right. So how can we control that? Oh, I know how we can control it. We can just time box it and say, have we learned enough in the time allotted? No. Okay. Let me give you another time segment. I also think there's another element to it, which is just, just describe up front, what is it that we hope to learn so we know when we're done. Otherwise we just keep learning and the developers will keep going. With the team. I mean, that is the old arguing agile of the side of this, the other side of this is let me the developer figure out what I'm done and just go away leave me alone. why do I have to keep coming to you asking permission to have more time? We like, you like getting paid, right? We, we get money when customers buy real product. Yeah. I mean, I understand, but also like you have empathy for their position, which is like, it takes a lot of time to really understand the new technologies and understand all the business cases through it. the point that you're raising, which also is my point is nobody can go off on their own and burn a bunch of company money on their own, like without checking in with anybody, nobody in the business, product managers, executives, nobody works like that in the, even the C level, even CEO executives, you can't just burn an infinite amount of money and time and expect to not have to report that to somebody. Yeah, expensive to be accountable for that to somebody. Exactly, I had two other quick things that I think are quick, we'll see which is parallel teams slash tracks of work. What I mean by that is multiple products being serviced by one team. Team. if you have multiple products, usually what happens is as the team members are moving fast and transitioning between products, there's that switching costs. Part of paying that switching costs is they'll just do something real quick over here and then come back to the main thing they're working on. So they're incurring debt the whole time. They just don't know it. Right. Yeah. that's part of the shadow backlog is like, you don't really realize that they've come off of the main thing. To go do one, two little quick fixes on this other thing, and then they're popping back off. You don't notice it until they're gone two days and like, wait a minute, what's going on? Yeah. And that's made even worse by who's judging them? Like who's actually measuring what they're working on. So if they're being measured on this main work that they're doing and they kind of just go away somewhere and come back. Then they're going to want to rush things over there. So then come back to this cause all eyes are on this. Right. Right. It's just bad practice. It's just too many, two balls in the air is one ball too many. Probably. Parallel teams. I wanted to combine this with another category. it was either like non transparent. Don't understand the, like maybe one of these parallel tracks that's happening is a very, very old legacy product. Right. That maybe they don't like this. The company doesn't want to staff product managers for right. So it's unclear about who sets the priority for an end. Also unclear about when things get worked on. it doesn't have a clearly defined roadmap that's transparent and it's not clear when they're making releases. the customers are still using it and are happy when they get new releases. They can't be guaranteed that they're going to get a new release every week or whatever, like that cadence has changed because the business is no longer funding. the business may well be wanting customers to get off of the old legacy, And jump onto one of their newer versions Yes This is a very passive aggressive category. Yes, indeed. This multiple products, one team like, dude, this is a problem. I guess if it's multiple products. With one team and one product manager who is also over all the products. Then I guess it's a little easier because it's one team working out of multiple backlogs and then they have one sprint, but that one sprint is composed of different products. Yeah, but I mean, I guess the point of that category though as far as the shadow backlog goes, is like, I've also been on teams where as programs are dissolved, or as teams are dissolved, or whatever, like the people that are left join another team, and then the maintenance of that product that's in sunset mode is also added to this other team's responsibilities or sometimes it's not added to the other team's responsibilities. I was once with a program that was completely spun down. They only kept two developers and they added those two developers. They added one to one team and one to the other, but those two developers were the ones that got calls from the project managers when the project managers of that organization own the customers. Don't ask me how I didn't set this up. The project managers own the customer relationships and the customers would say, Hey, we had this problem with the software. We found a bug, we need to fix. And the project managers would go to the product managers who own those developers to say, we need this developer for a certain amount of time to do these fixes or whatever. And they would interrupt their. Sprints that are in progress. they're committed work that was in progress because this stuff would come up as like support work. in that instance, we like the project managers and the product managers had good working relationships. But it very easily could have been the project managers go directly to the developer to say, Hey, we need you to fix this. And now there's a stream of work in the shadow backlog. So, yeah. And it's, it's really not all that pleasant for the poor developer who's caught in this thing. Right. I mean, they have multiple masters. Oh, I was, Well, one of the, one of the two left cause they didn't want to work in that environment. And then we had one developer that did all the maintenance for that sunset product line that still brought in a significant amount of revenue for the company. So that's your like million dollar developer. So basically like that developer could have, they were not the kind of person who would ask for like, Hey, 20%. 50 percent or whatever I'm going to leave, but they very well could have, they could win the lottery. And now the company's in deep trouble. The only other category that we have left is dealing with NFRs, which is usability. Like I want to go make this change to the UI, like a UI front end developer. We'll do this. I've, I've seen them do this often Hey, I, I need to add. This new toggle to the map or this I want to add a dark mode to the map. Nobody says, everyone else has got dark modes and we don't have dark modes and I feel real strongly that we should have a dark mode. Cause I'm I, I'm a developer. I like only working on everything is dark mode all the time. Live my life on dark mode. Yeah, definitely. Everything you just said starts with the letter I. So yeah, these are solo people that just basically have their own opinions on what should be in the product and they go work on it. Maybe, maybe, maybe because scalability and performance, I've seen developers get lost down the rabbit hole of scalability and performance. But performance of, hey, I need to Go and pull all the SQL queries in our system and optimize every single query Performance is one of those things that the more you work on it, the more you can work on it. It keeps going on and on and on. Right. Yeah. absolutely. I've seen people like that, that are very passionate about their work. And they're like, no, I know I can improve this two more percent. Right? It's like, oh, just go work on something else. Nobody cares about that. It's already fast enough. They care. You know, they care. They themselves do. Yeah, this is very close. The NFR thing is very close to the personal task list that we were talking about scalability, for example. Where do you stop at scalability? You know, the system needs to handle a hundred concurrent users. The system needs to handle a thousand concurrent users. do you stop at a hundred times what our current normal traffic is? So rule of thumb is 10, isn't it? So stop at 10 and then build in auto scaling. Yeah. I think this category is the personal task list because the more that someone is concerned and digs into a category and keeps working on it as their kind of like pet project of I think about network engineers, this way is like, oh, I got a, Optimize the network. And I got to make sure we got bandwidth for this and redundancy. failover, basically failover. Especially with cloud tech now. But I remember those days too and then you add on top of that, all the nuances you fail over, but you can't have data from Germany, outside of Germany, right. All of those little nuances layer on top of that. Yeah, a lot of this, a lot of that in the four categories the personal task list, now that I'm now that I'm thinking about it a little bit deeper, so. I think, I think you can go a long way towards you know, eliminating quite a bit of that by defining the attributes that you need up front. Yeah. And putting guardrails there, right? If it scales to a hundred times, Is that better than 50 times? Cause we've never had that before, you know? So maybe stop and just monitor their times, probably better spent putting in some application monitoring. So it reports out the peaks and valleys, right. During the day or whatever. Monitoring is a great one too. Cause like there's always one additional detail, monitor anything, one additional detail. You just gotta have, it'll be perfect. If I have one additional detail, that's another great one. Yeah. That's true. Well, that's the podcast today of you know, , a shadow backlog, the hey buddy backlog, anybody backlog. I like that. Yeah. if you're looking at a backlog, that might be your Robin, if you're Batman, or it could just be a shadow Batman. I don't think it's, I think it's your Joker, if you're Batman. I think it's your worst enemy. Standing over your shoulder. we only kind of talked about all the different types. Of things that can contribute to the shadow backlog. We didn't really talk about what to do with them, how to resolve them or whatever. Maybe that's a part two, maybe it's a second part, completely separate podcast. I don't know if you have good backlog management, if you're doing backlog refinements, if you're involving your team, if you're getting the right stakeholders in there, you can do a lot to mitigate this. So I think when we talked about how you manage the backlog is not clear, it's not transparent. Like that is the. Kind of the crux of why this is a big problem is people don't understand your backlog management Maybe they're not invited to it and they should be maybe you're not casting a wide enough net to bring people into your refinements, you know Yeah, absolutely agree with that. Let's do a second part on what to do about these things. Yeah, I think that would be a good one. It may not be as long as this. I don't know. Yeah, maybe not, but I don't, I don't know what the title of that one is like killing the, killing the shadow backlog. It's a shining a light on the illuminate. Yeah. Well, if you have an idea for what part two would be Hit us up in the comments. Yeah, we'd love to hear from you. And don't forget to like and subscribe.