Have you been in a situation where engineering leadership and product management do not see eye-to-eye?
In this episode, Enterprise Business Agility Coach Om Patel interviews and coaches Product Manager Brian Orlando on challenges product managers face when working with engineering teams, leads, and managers.
Listen/watch to learn tactics for diffusing a potentially difficult situation, including:
- Strategies for effective spike work and time-boxing
- The importance of frequent check-ins and demos
- Spotting when tech leads aren't aligned with modern dev practices
- Key takeaways from "Accelerate" and it's relevance
- The value of being willing to abandon unsuccessful features
Whether you're a product manager struggling with team dynamics or an engineering leader looking to improve collaboration, this episode is packed to the tippy-top with valuable and practical advice you can start using - right meow!
#ProductManagement #Agile #EngineeringLeadership #ContinuousImprovement #DevOps
= = = = = = = = = = = =
Watch it on YouTube
= = = = = = = = = = = =
Subscribe to our YouTube Channel:
https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1
Apple Podcasts:
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
= = = = = = = = = = = =
Toronto Is My Beat (Music Sample)
By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)
CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)
00:00:01 --> 00:00:10 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.
00:00:11 --> 00:00:13 Welcome back to arguing the agile.
00:00:13 --> 00:00:16 I don't know how much arguing we'll have today because I need advice today.
00:00:16 --> 00:00:16 Okay.
00:00:16 --> 00:00:17 Let's see how this goes.
00:00:17 --> 00:00:17 All right.
00:00:17 --> 00:00:18 All right.
00:00:18 --> 00:00:24 So in all of the books that you read about product management, agility, the business operations, product management, right.
00:00:24 --> 00:00:40 They'll tell you if you have issues with your team or team members, Like talk to your engineering management or your peer in engineering And then work it out and everything will be great and we'll all hold hands and sit by the campfire That's that's what they tell you in the books, right?
00:00:40 --> 00:00:43 And that's what the influencers online will tell you influencers Influencers.
00:00:43 --> 00:00:56 that's not great advice because what if my hang up is between myself and engineering leadership, what if engineering leadership is saying like, well things will work out, you just need more time for the team to develop, right?
00:00:56 --> 00:00:58 what if that is the response?
00:00:58 --> 00:01:01 First of all, my advice is going to be worth every penny you pay for.
00:01:01 --> 00:01:09 So whenever you hear something like this, We have to resist the temptation of being kind of like uni dimensional, right?
00:01:09 --> 00:01:11 This is how it is with that organization.
00:01:11 --> 00:01:14 Because maybe you have variances in place, right?
00:01:14 --> 00:01:15 So it's worth talking about that.
00:01:15 --> 00:01:24 But engineering leadership they typically don't necessarily work with product folks on that level and say, yeah, we own this issue, right?
00:01:24 --> 00:01:32 Especially if you have other product leaders where this issue is not reported by them or it's not as exacerbated, right?
00:01:33 --> 00:01:37 So I think it's worth just quickly touching on how did you surface this, right?
00:01:37 --> 00:01:41 How did you come across this issue to begin with so that we can have some context around this?
00:01:41 --> 00:01:44 In this example I was at an organization where.
00:01:45 --> 00:01:51 The team members had a lot of issues delivering what the business was asking to production.
00:01:51 --> 00:01:55 We would have a refinement, we'd break an issue down.
00:01:55 --> 00:01:57 The team would say, yes, this is similar to something else.
00:01:57 --> 00:01:58 We did in the past.
00:01:58 --> 00:01:59 We think we can get this done in one sprint.
00:02:00 --> 00:02:01 we're going to point value at a five.
00:02:02 --> 00:02:02 I'll say, cool.
00:02:02 --> 00:02:03 It's a five.
00:02:03 --> 00:02:08 It's the highest priority feel free to push anything out of the way that you need to to get this one thing done.
00:02:08 --> 00:02:09 It's the sprint goal.
00:02:09 --> 00:02:18 And then, come the end of the sprint , we couldn't get it done, maybe there was some delays, maybe we ran into some roadblock and then we don't get it done, bringing it to the next sprint planning.
00:02:18 --> 00:02:19 , are you sure you don't want to break it down?
00:02:19 --> 00:02:20 No, no, no, no.
00:02:20 --> 00:02:20 We got it.
00:02:20 --> 00:02:25 , we're most of the way done because of what we did last sprint and then , come the end of this sprint, we're still not delivering it.
00:02:25 --> 00:02:28 So now it's been two sprints with this 3.
00:02:28 --> 00:02:33 5 point, item that everyone swears every day through the daily standup is.
00:02:33 --> 00:02:35 Got no blockers to work on.
00:02:35 --> 00:02:36 Everything's going great.
00:02:36 --> 00:02:37 that's been the development team every day.
00:02:37 --> 00:02:50 And, at the end of two sprints, I'm really looking at my engineering leadership my team leads or my director of engineering or whoever I have, whatever size company, and I'm really looking at them to say dude, can you throw me a lifeline here?
00:02:50 --> 00:02:51 Can you get involved?
00:02:51 --> 00:02:56 Can you please help because something is wrong here short of me, the product manager.
00:02:56 --> 00:02:57 Waiting into code.
00:02:57 --> 00:03:04 I don't know where to go from here, I was like, Hey man, like new teams need time to form.
00:03:04 --> 00:03:06 They're just working on their lines of communication.
00:03:06 --> 00:03:08 They're just figuring out how to escalate and stuff like that.
00:03:09 --> 00:03:10 I could deal with that for a sprint.
00:03:11 --> 00:03:12 Maybe two.
00:03:12 --> 00:03:20 So, for me moving the stuff that's not done at the end of a sprint, moving it to the next sprint, like a puppy dies somewhere when that happens.
00:03:20 --> 00:03:21 It's blasphemy.
00:03:21 --> 00:03:25 It creates these zombie Work items, PBI's, and never die.
00:03:25 --> 00:03:28 And that can be for a multitude of reasons.
00:03:28 --> 00:03:30 That's not this podcast though, right?
00:03:30 --> 00:03:33 You know, maybe requirements aren't clear, sizing's not right, whatever.
00:03:33 --> 00:03:37 I completely agree there's a million reasons technical data, a million reasons.
00:03:37 --> 00:03:40 But none of that has been escalated to the product manager.
00:03:40 --> 00:03:43 It's just, we got this, we're working on it.
00:03:43 --> 00:03:43 Yeah.
00:03:43 --> 00:03:49 And then I'm asking my tech lead or I'm asking my engineering manager, guys, the team says they got this.
00:03:49 --> 00:03:53 But I don't see any progress, and I'm starting to get real worried about this.
00:03:53 --> 00:03:58 They're probably getting the same watermelon reports that your stakeholders are getting, or your leadership's getting.
00:03:58 --> 00:04:02 Everything's fine, everything's green on the outside, but it's really red on the inside.
00:04:02 --> 00:04:04 So let's dig through this, right?
00:04:04 --> 00:04:17 When it happens, what is The first thing that you do when people don't deliver in a sprint, like the day, the engineering leadership, did they take accountability and say, let's dig deeper and do some kind of retro on what's going on?
00:04:17 --> 00:04:19 Or do they simply move it to the next sprint?
00:04:19 --> 00:04:21 That's kind of like the de facto answer.
00:04:21 --> 00:04:24 the de facto answer right now is let's try not to rock any boats.
00:04:24 --> 00:04:25 Like it's a new team.
00:04:25 --> 00:04:27 I probably should have started with that.
00:04:27 --> 00:04:29 It's not a new team like put together yesterday.
00:04:29 --> 00:04:30 They've been together a couple of months.
00:04:30 --> 00:04:35 It's a fairly new team, but not like new new team.
00:04:35 --> 00:04:39 And the technology that they're working in is familiar to them.
00:04:39 --> 00:04:41 So they're not working in a new tech stack or anything like that.
00:04:41 --> 00:04:44 So did they come up with dependencies?
00:04:44 --> 00:04:56 that couldn't be met or like, what is the team saying to the engineering manager these are the reasons or this is a main reason why we were not able to finish, If that's not happening, we simply just move the work forward.
00:04:56 --> 00:04:58 That's a process issue right there.
00:04:58 --> 00:04:58 Yeah.
00:04:58 --> 00:04:59 I don't know.
00:04:59 --> 00:05:10 I assume that they're trying to handle as many edge cases that they dream up as they encounter them or they're attempting to bring new technologies into the stack they're unfamiliar with.
00:05:10 --> 00:05:15 And that's where the extra time is, is working through a new technology that they found to solve this.
00:05:15 --> 00:05:17 that could be dealt with with our current technology.
00:05:17 --> 00:05:24 Like before you go and grab a new technology off the shelf or start deviating and adding acceptance criteria.
00:05:24 --> 00:05:30 'cause I've worked with teams where the engineer will add new acceptance criteria as they take care of things oh, we didn't talk about this in the original story.
00:05:30 --> 00:05:38 I'm gonna add this piece of acceptance criteria that the code now handles because we didn't think about it when we originally planned it, so I thought of this additional case.
00:05:38 --> 00:05:40 So rather than like bringing it back up.
00:05:40 --> 00:05:43 In a stand up of, Hey I started to implement this thing we were talking about.
00:05:43 --> 00:05:46 And I realized this other thing could happen.
00:05:46 --> 00:06:00 Do you want me to take a little bit extra time and code that path and take care of it, or do you want to break that off as a different, like we never had that, that presenting that never happened with me in the room, the engineer just decided they were going to wrap it into.
00:06:00 --> 00:06:16 I almost don't even want to say it's scope creep because like in an agile software development, there really should not be scope creep, but it kind of is scope creep in terms of like I've inflated the AC to now include these additional things that I've dreamt up on my own.
00:06:16 --> 00:06:17 Like I so.
00:06:17 --> 00:06:18 Some of it is that.
00:06:18 --> 00:06:19 And it's normal.
00:06:19 --> 00:06:21 This is also, it's very prevalent.
00:06:21 --> 00:06:21 It's normal.
00:06:22 --> 00:06:26 This is akin to saying, well let's say your story is to clean the house.
00:06:26 --> 00:06:34 So now, originally you just thought about vacuuming and now you're saying, well, we need to also mop everything and we need to do deep cleaning everywhere.
00:06:34 --> 00:06:39 and then I turn around and then tomorrow I come back, I'm pulling to the driveway and you're outside.
00:06:39 --> 00:06:48 So like half the team is power washing one side of the house and the other side of the team is painting the part that was power washed and dried and I'm like, wait, wait a minute.
00:06:48 --> 00:06:49 I meant clean the inside of the house.
00:06:49 --> 00:06:51 Well, you didn't say inside.
00:06:51 --> 00:06:52 You said clean the house.
00:06:52 --> 00:06:54 So we started inside and now we're outside.
00:06:55 --> 00:07:00 So it's just all going back to clarity, but let's go back to the original point about working with.
00:07:00 --> 00:07:01 The engineering manager.
00:07:01 --> 00:07:02 Are they engaged?
00:07:02 --> 00:07:10 Because it's been my experience that I've had engineering managers that are deeply engaged and on the other end of the spectrum, they have not been engaged.
00:07:10 --> 00:07:17 Well, I'm glad that we're going here because I've had engineering managers, that are really engaged, that completely understand.
00:07:17 --> 00:07:36 Team dynamics, how great teams are formed how great teams move through those Tuckman steps, and I've also been in organizations that when they scale or they become successful, those same engineering managers get overwhelmed when they're no longer across two teams or four teams, now they're across 16 teams.
00:07:37 --> 00:07:43 And now they went from being here with the water up to the neck to being clearly over their head with the water.
00:07:43 --> 00:07:45 And now they are out of their element.
00:07:45 --> 00:07:54 Like I feel that that is probably not talking about enough in our circles of just people just being overwhelmed.
00:07:54 --> 00:07:57 Just because now they manage more teams, you know what I mean?
00:07:57 --> 00:08:01 like a tech lead, for example, a technical lead, a team lead or whatever you want to call it.
00:08:01 --> 00:08:04 I think of them in terms of the team topologies, What is team topologies?
00:08:04 --> 00:08:06 Do they call it a technical lead?
00:08:06 --> 00:08:14 in team topologies, they have enabling teams, and the enabling teams are made up of what you would call lead, like the leads from every team.
00:08:14 --> 00:08:18 together in one group would be called an enabling team.
00:08:18 --> 00:08:23 so your rep to the enabling team, your team lead or architect or whatever you call in your organization.
00:08:24 --> 00:08:26 Like how many teams do they span?
00:08:27 --> 00:08:29 How many teams can a team lead span?
00:08:29 --> 00:08:34 when I was a manager of QA, for example, how many teams can all my QA people be on?
00:08:34 --> 00:08:47 Before I need to delegate to the different teams like can I have like eight people in the qa department and they all serve on individual teams So now there's eight product lines That each have a qa person like can I now be effective?
00:08:47 --> 00:08:57 as that individual qa person's lead to grab stuff that falls between the cracks to go between teams to you know, I mean Or do I need to put a person under me as a qa lead?
00:08:57 --> 00:09:17 You In like this middle management kind of tier to help relay to escalate the worst problems that slip between the cracks between Architecture and just like cross team stuff and all that kind of stuff like right there is a team of leads thing happening here that nobody's really good at that so like I went on this tangent because you asked a simple question, which is like You have a team lead, right?
00:09:17 --> 00:09:32 I mean, I do on paper, except he or she is across eight different teams and, oh, and also they're the main architect for this one product because they used to work on as a developer before they were promoted or whatever, like that's a very real situation, right?
00:09:32 --> 00:09:39 So like there is probably an upper limit of how many teams, a team lead, right?
00:09:39 --> 00:09:39 Can span.
00:09:40 --> 00:09:40 I agree.
00:09:40 --> 00:09:41 I don't know what the number is.
00:09:41 --> 00:09:49 I've not read that anywhere, but you know, just gut field tells me if it's more than three or four, that technically is going to be stretched pretty thin.
00:09:49 --> 00:09:53 Once you hit the number two, anything above that is like super suspect.
00:09:53 --> 00:09:53 Yeah.
00:09:53 --> 00:09:53 Yeah.
00:09:53 --> 00:09:58 It's just a big load you know, on the person because they are a lead, right?
00:09:59 --> 00:10:01 And oftentimes they reach left and right.
00:10:01 --> 00:10:04 So tech leads, engineering leads, et cetera, they work closely.
00:10:04 --> 00:10:09 If you have a model where you have other leads, you may have QA leads, for example, right?
00:10:09 --> 00:10:15 And I've been on teams where, You have BA leads, especially in a scaled environment.
00:10:15 --> 00:10:19 So you're collaborating with these other X Y Z leads.
00:10:20 --> 00:10:22 And if you're doing that, then, yeah, I agree with you.
00:10:22 --> 00:10:24 Two teams is probably the max.
00:10:24 --> 00:10:39 All right, so let's go back to the beginning of the podcast where we're talking about tech leads and their role in teams delivering product managers trying to understand working with the tech leads, what's going on, if everything's working well and you're delivering, nobody cares, right?
00:10:39 --> 00:10:40 No, nobody cares.
00:10:40 --> 00:10:44 They want more, maybe faster, My magic metric number right there.
00:10:44 --> 00:10:46 It's like, Brian, how do we measure development teams?
00:10:46 --> 00:10:55 I say, well, if you're delivering working software on a regular basis, no matter if that regular basis is once a month or once a week, once every six weeks or whatever, like it doesn't matter what it is, you're delivering.
00:10:55 --> 00:10:57 Nobody complains, right?
00:10:57 --> 00:10:59 They know when they're going to get their thing.
00:10:59 --> 00:11:03 The underlying point of contention here was the product manager.
00:11:03 --> 00:11:07 And then everybody that the product manager bubbled up to is not happy.
00:11:08 --> 00:11:09 With the cadence of delivery.
00:11:09 --> 00:11:11 So we go back to Brian's magic metric that I just threw out.
00:11:12 --> 00:11:19 Hey, You're delivering on a regular basis, if you're missing your sprint goal every sprint, the developers will quickly get painted into a corner.
00:11:19 --> 00:11:23 Where they're not delivering what they say they're going to deliver right now.
00:11:23 --> 00:11:28 you got to deliver what you say you're going to deliver like a scoping down what you say you're going to deliver to something you can actually deliver.
00:11:28 --> 00:11:33 Like, that's the number one thing you really need to do if you wanna get everybody in management off your back.
00:11:33 --> 00:11:34 Exactly.
00:11:34 --> 00:11:35 Exactly.
00:11:35 --> 00:11:39 So just because there is a sprint goal or sprint commit for that matter.
00:11:39 --> 00:11:41 does not make it a guarantee.
00:11:41 --> 00:11:44 However, that said the flip side of it.
00:11:44 --> 00:11:49 if they don't deliver exactly what they committed to or whatever the goal was, they should not be doing for that.
00:11:49 --> 00:11:55 But having said that, if there's a pattern of doing this where they're not delivering, there's something wrong, right?
00:11:55 --> 00:12:00 There's a dysfunction somewhere that needs to be we need to dig through this and, and analyze that and fix it.
00:12:01 --> 00:12:05 Let me bring up the, the main point of contention that's, that started this, right?
00:12:05 --> 00:12:05 Yeah, yeah.
00:12:05 --> 00:12:09 What I, what I said earlier in the podcast, we've gone three sprints, we haven't delivered anything.
00:12:09 --> 00:12:14 So I've asked the development team to implement a new charting library, for example.
00:12:14 --> 00:12:17 So we have a website, it draws charts based on data.
00:12:17 --> 00:12:18 I want a new charting library.
00:12:18 --> 00:12:20 So I asked him, implement a new charting library.
00:12:20 --> 00:12:22 These are the things that I want from the charting library, right?
00:12:23 --> 00:12:23 I've got this data.
00:12:24 --> 00:12:28 You're basically taking the same data and you're just hitting it with different, like a gallery of charts.
00:12:28 --> 00:12:30 Maybe each sprint, we could be delivering a different chart.
00:12:30 --> 00:12:34 I've left all this to the development team, but I've told them Hey, I want to have a gallery.
00:12:34 --> 00:12:39 Like you go to the website, you pull up the web page, you've got the data that shows there.
00:12:39 --> 00:12:40 And then I want a gallery of charts.
00:12:41 --> 00:12:42 Maybe a line graph.
00:12:42 --> 00:12:48 Oh, now maybe you know, a histogram and now, now maybe a scatterplot or maybe whatever, like a line.
00:12:48 --> 00:12:51 I don't need the ability to like manipulate the X and Y axis.
00:12:51 --> 00:12:54 You just pick what the X and Y axis is based on the data and just.
00:12:55 --> 00:13:01 Give me Four or five different charts that the user can you know a donut chart line graph simple stuff, right?
00:13:01 --> 00:13:08 Yeah, I was gonna say not exactly rocket science the team finally delivers My charting and Like all the graphs look terrible.
00:13:08 --> 00:13:19 It's just very underwhelming like if I were to take the CSV myself, go on to any of these websites and play around, like most of these websites with charting libraries have like a demo area.
00:13:19 --> 00:13:22 You can play around with the charts, upload your own data, that kind of stuff.
00:13:22 --> 00:13:30 If I were to do that, I could go and replicate this stuff like today, like in a day, I just dedicate today to exploring these.
00:13:30 --> 00:13:36 So after two sprints, the team is delivering this stuff that just doesn't look good.
00:13:36 --> 00:14:11 I as a product manager, I don't understand how we got this far off track I don't understand for the time that was put into this, I don't understand why I don't have a half a dozen different charting library examples live in production or whatever, live in the beta environment or whatever test environment and yeah, it seems to me like a skill level of the development team issue and an issue with tech lead, not properly supervising the developers to keep them on track and giving them guidance because clearly if I see it and it clearly is like, it looks like you know, it looks like a undergrad project, like clearly the, the tech lead on the team.
00:14:11 --> 00:14:12 Must not have been engaged.
00:14:13 --> 00:14:15 I was like, there's no way you could think that this is sufficient.
00:14:15 --> 00:14:17 Yeah, I think it points directly to that.
00:14:17 --> 00:14:28 I mean, the only other way is you look at that and say, Architecturally is what you're asking for is what the team working on and delivering aligned with their architectural runway.
00:14:28 --> 00:14:31 Which again, unless you have architects, it's the tech lead.
00:14:31 --> 00:14:32 So, so roll up to the tech lead.
00:14:33 --> 00:14:34 What happens though?
00:14:34 --> 00:14:41 What happens when they demo this stuff and it doesn't look good, a sprint goes by, another sprint goes by like, what is the behavior?
00:14:41 --> 00:14:42 Yeah, of the team, right?
00:14:42 --> 00:14:47 Are they owning up to that and say, Oh, damn, this doesn't look good, right?
00:14:47 --> 00:14:48 Where do we go wrong?
00:14:48 --> 00:14:50 So again, I go back to that whole thing.
00:14:50 --> 00:14:53 They retrospectively look back and say, How did we end up here?
00:14:54 --> 00:14:54 Right?
00:14:54 --> 00:14:57 Oftentimes, this gets weaponized and people use that to play the blame game.
00:14:57 --> 00:15:01 But my intent would be to say, if we missed it, we could miss it again.
00:15:01 --> 00:15:07 So it's really as a process to figure out where the gap was, redress that deficiency and move on.
00:15:07 --> 00:15:08 But we can't keep missing it.
00:15:08 --> 00:15:09 Right.
00:15:09 --> 00:15:13 So that, that's the other thing is, Now that we've missed it once, we look at it again.
00:15:13 --> 00:15:19 We've learned something as to why, but don't keep the same scope in play for the next sprint.
00:15:19 --> 00:15:24 If the reason was there was work was too complex, too much work, dependencies were found, et cetera.
00:15:25 --> 00:15:26 Feel free to change up the scope.
00:15:26 --> 00:15:29 So from that specific example, here was my learning.
00:15:30 --> 00:15:30 Okay.
00:15:30 --> 00:15:34 As my career learning as a product manager with this specific team.
00:15:35 --> 00:15:46 this team does not do well given the whole world as scope, like go out into the entire world, get all the charting libraries possible, all the visualization libraries possible, bring them back to me.
00:15:46 --> 00:15:48 Not the team did not handle that well.
00:15:50 --> 00:15:57 I'm going to go out and investigate charting libraries and pick like four or five of them that look good to me.
00:15:57 --> 00:15:59 Oh, but you don't, I feel you don't need that.
00:15:59 --> 00:16:04 You could ask your technical rep on the development team, your, your team lead or your architect or whatever.
00:16:04 --> 00:16:12 You could ask them, Hey, can you please go out and identify the top industry standard, five charting libraries, top three, right?
00:16:12 --> 00:16:14 You could ask for help with this.
00:16:14 --> 00:16:14 You don't have to do it yourself.
00:16:14 --> 00:16:20 I do it myself because I know how to do it in Python and it's pretty straightforward and I know what I'm looking for.
00:16:20 --> 00:16:21 But you don't have to do it yourself.
00:16:21 --> 00:16:24 You can make a ticket, assign it to your architect, have them help you in your sprint.
00:16:24 --> 00:16:26 Put that to the side for a second.
00:16:26 --> 00:16:32 What I'm asking for is, I'm going to create the boundaries by saying, Okay, these three charting libraries.
00:16:32 --> 00:16:45 I want you to take data exported from our real system and show me a donut chart, a line chart, a bar graph, whatever you mean that things I'm thinking of with our example data downloaded here into a CSV.
00:16:45 --> 00:16:46 So it's the same data.
00:16:46 --> 00:16:51 Different libraries, but real live quote, in production versions of it.
00:16:52 --> 00:16:53 And I want to see it mocked up.
00:16:53 --> 00:16:55 Maybe it never needs to leave our dev environment.
00:16:55 --> 00:16:57 it could be local on the dev environment.
00:16:57 --> 00:17:00 Double points if it's in production, but I don't care if it's in production.
00:17:00 --> 00:17:05 Because we I see them in a sprint demo and I bring these stakeholders and they say, these churning libraries all suck.
00:17:05 --> 00:17:06 They're all terrible.
00:17:06 --> 00:17:07 I hate them.
00:17:07 --> 00:17:07 None of them.
00:17:07 --> 00:17:12 I wouldn't want to stand in front of the customers and show charts written with any of these.
00:17:12 --> 00:17:13 Cause they're look, they look terrible.
00:17:13 --> 00:17:14 Okay, cool.
00:17:14 --> 00:17:17 Development team, roll all this out and throw all the code away.
00:17:17 --> 00:17:18 Which brings me to it.
00:17:18 --> 00:17:21 there's two statements I just threw out by saying that.
00:17:22 --> 00:17:35 both of which could be confrontational, but number one is I'm going to give you the very next thing because development teams might hear that and say I don't need you to give me the bounds that I'm playing inside of, I'll go out on the internet and I'll discover them for myself.
00:17:35 --> 00:17:37 Number one, that's valid.
00:17:37 --> 00:17:38 Let's put that aside for a second.
00:17:38 --> 00:17:39 You did a thing with code.
00:17:40 --> 00:17:41 Now I want you to throw it all away.
00:17:41 --> 00:17:43 those two things are very confrontational.
00:17:43 --> 00:17:49 I think as far as like saying to the team, go out and look for these two or three, why not just create a little spike to go figure that out?
00:17:50 --> 00:17:56 The team ultimately, so I want to go back to the point that you made about using your tech lead or a savvy person.
00:17:56 --> 00:17:57 Product person can do that.
00:17:57 --> 00:17:59 BAs can help there too.
00:17:59 --> 00:18:01 To do the groundwork, the research, etc.
00:18:01 --> 00:18:03 To figure out the tools, bring them in.
00:18:03 --> 00:18:05 That should be a spike.
00:18:05 --> 00:18:06 That kind of work, right?
00:18:06 --> 00:18:08 And then they share it with everybody.
00:18:08 --> 00:18:09 Not least the product person, right?
00:18:09 --> 00:18:13 And then you make a decision saying, well, we'd like to go with this, or we'd like to go with that.
00:18:13 --> 00:18:15 It's an informed decision.
00:18:15 --> 00:18:24 As opposed to the team picking something and deciding autonomously and then showing it to you because you may have good reasons why you want to pick a tool, right?
00:18:24 --> 00:18:33 let's talk about spike for a second So, Again from this conversation one of my learnings that I took with me through my career is I never, I told this story on a separate podcast.
00:18:33 --> 00:18:41 I remember telling a story where the development manager I was working with said like, Hey, I said, Oh, I don't want to spend like more than like two hours struggling to solve a problem.
00:18:41 --> 00:18:45 And he was like, don't spend two hours, spend like a maximum of 15 minutes.
00:18:45 --> 00:18:49 If you can't figure out the logic problem, come get another developer, you know?
00:18:49 --> 00:18:52 And at the time I was like, Oh boy, that's, that's a real short amount of time.
00:18:52 --> 00:18:57 years later, after the fact I find myself more in line with that advice of like, yeah.
00:18:57 --> 00:18:58 Spend.
00:18:58 --> 00:19:05 A couple of minutes trying to work through the I mean, dedicated, not like checking your slack and doing other things, I mean, dedicated to actually solid hours.
00:19:05 --> 00:19:10 And if you can't solve the logic problem by yourself, reach out to someone else and bring them in sooner rather than later.
00:19:11 --> 00:19:19 I stand to have a team working agreement like that, where if you're stuck on a task for more than an hour, reach out to somebody in Slack or Teams or whatever it is that you're using, right?
00:19:19 --> 00:19:21 And don't just sit there and spin.
00:19:21 --> 00:19:26 Least of all, don't wait till the next morning and say, Oh, I'm stuck on that task since yesterday.
00:19:26 --> 00:19:28 The reason I brought that up was, Spike thing.
00:19:28 --> 00:19:30 It's like, oh, we're going to, we're going to pick up a spike.
00:19:30 --> 00:19:33 This sprint that says, find the best charting library.
00:19:33 --> 00:19:34 Right.
00:19:34 --> 00:19:50 well, my engineers are going to go out and they're going to identify six maybe eight, a dozen charting libraries and come back and give me an overview of all of them what I really mean is like, I want you to learn how to use these charting libraries and then suggest which one's the best for us.
00:19:50 --> 00:19:56 Maybe every day you're learning a different charting library, but maybe, here's what I'm trying to say, which I, which this is not new either.
00:19:56 --> 00:19:57 I've said this on different podcasts.
00:19:57 --> 00:20:02 If I'm assigning a spike and the spike is suggest explore our options.
00:20:03 --> 00:20:08 With regard to charting libraries suggest the best one for what we want to use it for.
00:20:08 --> 00:20:14 And then I will write in the ticket, some of the things we want to do with charting libraries, maybe give some screenshots and stuff like that.
00:20:14 --> 00:20:18 And then your job as a developer is to take a couple days.
00:20:19 --> 00:20:19 Okay.
00:20:19 --> 00:20:23 So this is, this is where we start getting into the nitty gritty of what I want to talk about.
00:20:23 --> 00:20:25 I've been on teams where this is 24 hours.
00:20:25 --> 00:20:29 I've been on teams where it's 48 hours, meaning one day or two days.
00:20:29 --> 00:20:36 I've rarely been on teams where it's longer than that, but this team that I'm talking about in this example, their time box was a whole sprint.
00:20:36 --> 00:20:41 They would assign a developer for the entirety of the sprint to investigate the spike work.
00:20:41 --> 00:20:42 I've seen other teams do this too.
00:20:42 --> 00:20:43 So it wasn't unique to this team.
00:20:43 --> 00:20:44 And I think.
00:20:45 --> 00:20:50 That is too long to let the time box be open for spike work to go off and do open ended research.
00:20:50 --> 00:20:55 I feel every 24 hours that your spike task is open.
00:20:55 --> 00:20:58 You should come back to the team and review your findings with the team.
00:20:58 --> 00:21:02 Some people might think of that as micromanagement and that's why I want to bring it up.
00:21:02 --> 00:21:05 So first of all, let's just get that out of the way, right?
00:21:05 --> 00:21:07 The definition by definition is spike.
00:21:08 --> 00:21:10 means you're investigating something you don't know enough about.
00:21:11 --> 00:21:12 That is not micromanagement.
00:21:13 --> 00:21:21 That also cannot take a sprint because it's supposed to be a spike, not just a regular story, PBI, whatever, in the sprint.
00:21:21 --> 00:21:23 A lot of people have that.
00:21:23 --> 00:21:26 The phenomenon you described, a spike is open at the end of the spring.
00:21:26 --> 00:21:27 They go, we're still waiting to learn more.
00:21:27 --> 00:21:30 So we'll move this spike to the next sprint.
00:21:30 --> 00:21:31 They've already missed it by then.
00:21:31 --> 00:21:31 That's right.
00:21:31 --> 00:21:33 So look at the story, right?
00:21:33 --> 00:21:34 And say.
00:21:34 --> 00:21:36 Let's analyze what's in the spike story.
00:21:36 --> 00:21:42 If you're looking at investigating X, Y, and Z, or learn about X, Y, and Z, maybe open three spikes.
00:21:42 --> 00:21:45 At least that way, you can learn about X or X and Y right?
00:21:45 --> 00:21:51 Vertically slice the story smaller, especially if it's a spike story, such that it can be finished in a day or two.
00:21:51 --> 00:21:53 That's the idea behind a spike.
00:21:53 --> 00:21:58 Well, the spike here is like, I don't know how long it's going to take to investigate this charting library or whatever.
00:21:58 --> 00:22:11 But if I clear all the rest of the tasks that are on your to do list off for today, I say dedicate yourself to learning everything you can about this specific charting library today.
00:22:11 --> 00:22:13 In that scenario, you should be able to get it done.
00:22:13 --> 00:22:21 because of my background on development teams, if you're telling me specifically, Brian, there's nothing more valuable you can do today.
00:22:21 --> 00:22:29 I'm going to shelter you from all the production blowups and support tickets and other requests turn your slack off for the day.
00:22:29 --> 00:22:30 I'll deflect people.
00:22:30 --> 00:22:31 If you're giving me that.
00:22:31 --> 00:22:37 You have that leeway and you're telling me I need this decision from you.
00:22:37 --> 00:22:38 That's your task.
00:22:38 --> 00:22:39 Close everything else.
00:22:39 --> 00:22:39 Yeah.
00:22:40 --> 00:22:42 And get this thing done okay, that's my thing.
00:22:42 --> 00:22:46 Given the three charting libraries that we've identified pre identified, right?
00:22:46 --> 00:22:47 Because that's where I started.
00:22:47 --> 00:22:49 It's just saying like, I'm going to draw the guardrail.
00:22:49 --> 00:22:53 Yeah, I'm going to draw the box around this and say, here's three.
00:22:53 --> 00:22:57 I've discussed with the tech lead or we discussed refinement and we agree on.
00:22:57 --> 00:22:57 Yep.
00:22:58 --> 00:22:59 Those are the ones you start with okay.
00:22:59 --> 00:23:03 Well, maybe you start with one of those and you read through documentation.
00:23:03 --> 00:23:10 It leads you to something else, but the bounds, the scope of the original item needs to be, this is what I was asked to do.
00:23:10 --> 00:23:10 I focused on it.
00:23:11 --> 00:23:11 I did it.
00:23:11 --> 00:23:13 And here's my recommendation.
00:23:13 --> 00:23:14 Upload production data to it.
00:23:15 --> 00:23:18 I'll do all this myself in order to try to help the development team.
00:23:18 --> 00:23:28 I can manipulate the data myself where other product managers might need a spike and then their development team has to go do this R and D, this kind of research, I can shortcut that.
00:23:28 --> 00:23:32 while two sprints ahead of the development team, I can be doing this R and D type of stuff.
00:23:32 --> 00:23:38 when refinement rolls around, I will demo what I've mocked up for the development team.
00:23:38 --> 00:23:41 With stakeholders in the room and then we'll talk about what I did.
00:23:41 --> 00:23:43 This is how I had to manipulate stuff.
00:23:43 --> 00:23:44 What do you think stakeholders?
00:23:44 --> 00:23:45 Oh, this is what we'd like.
00:23:45 --> 00:23:46 This is what we don't like.
00:23:46 --> 00:23:47 What do you think development team?
00:23:47 --> 00:23:49 this is how hard we think it'll be maintained.
00:23:49 --> 00:23:51 This is how hard we think it'll be to scale the rollout.
00:23:51 --> 00:23:53 you didn't take into account that kind of stuff.
00:23:54 --> 00:24:01 And we'll have a quick discussion and in an hour, hour and a half, we'll have made our decision and we'll be moving along, but I will be working well ahead of the team.
00:24:01 --> 00:24:11 But again, not everyone has the bandwidth to do that nor the skill so like I don't even render that as advice to people When I hear them have these problems.
00:24:11 --> 00:24:19 Yeah, because I don't it sounds like terrible advice like oh just be more technical or oh just get more involved in the work like Just work 60 hours.
00:24:19 --> 00:24:20 Like it's it doesn't it's not good.
00:24:20 --> 00:24:21 It's not good advice.
00:24:21 --> 00:24:24 Yeah, that's what i'm saying Yeah, no, I I concur with that.
00:24:24 --> 00:24:28 It is not good advice to do it that way But but here's the thing, right?
00:24:28 --> 00:24:33 If you have a cross functional team Shouldn't your team have the skill sense to do these spikes?
00:24:33 --> 00:24:39 I have a question for that though, what, what if your team says well, why don't you just tell us what charting library to use?
00:24:39 --> 00:24:49 If your team is front end engineers and backend engineers and data scientists and DBAs, even like if your team has, they're a cross functional team, but they're not a cross functional team.
00:24:49 --> 00:24:50 Meaning like.
00:24:50 --> 00:24:51 Full stack developers.
00:24:51 --> 00:24:54 They're a cross functional team, meaning you have every.
00:24:55 --> 00:24:57 Skill on the team to get the job done end to end.
00:24:58 --> 00:25:02 But everybody on the team is looking only to do their like, well, that's not our front end work.
00:25:02 --> 00:25:04 So I'm not going to pick that up.
00:25:04 --> 00:25:04 Yeah.
00:25:04 --> 00:25:08 Oh, you have to write me a backend tag to do the, you know what I mean?
00:25:08 --> 00:25:15 Like that just tells you that you don't have this team spirit where you can go to the team and say, I can't tell you what library to use.
00:25:15 --> 00:25:19 We need to figure out which one, which one's the best for us.
00:25:19 --> 00:25:19 Given.
00:25:19 --> 00:25:21 These constraints, right?
00:25:21 --> 00:25:23 And that's my marching order.
00:25:23 --> 00:25:25 Take these constraints and go figure it out.
00:25:25 --> 00:25:27 You don't have to decide if that's your concern.
00:25:27 --> 00:25:29 Just go figure it out.
00:25:29 --> 00:25:30 And give us the salient points.
00:25:30 --> 00:25:31 Let's talk about it.
00:25:31 --> 00:25:33 When you know enough, let's just meet.
00:25:33 --> 00:25:34 Spontaneously.
00:25:34 --> 00:25:38 So that again talks to, I think, the level of, I guess, maturity of the team.
00:25:38 --> 00:25:45 But also, So process wise, right, understanding that the team isn't just there to take orders and say, I'll just build it.
00:25:45 --> 00:25:50 You tell me what to build the part and parcel of making the decision of what to build.
00:25:50 --> 00:25:53 You've highlighted another issue with this team.
00:25:53 --> 00:26:00 So I've come to this team and I said, Hey, I like you already heard in my examples, like I'm going and finding the charting libraries.
00:26:00 --> 00:26:03 So I can draw guardrails so the team can kind of stay on track.
00:26:04 --> 00:26:07 I don't want that to be the way I'd interface with this team forever.
00:26:07 --> 00:26:11 I would prefer to say, Hey team, I need a new charting interface.
00:26:11 --> 00:26:12 Why don't you come back?
00:26:12 --> 00:26:15 I'm going to give you three days, two days, whatever it is.
00:26:15 --> 00:26:20 I'm going to write a story with a time box and go out on the market, investigate.
00:26:20 --> 00:26:36 All the libraries and all the tools that are available to us because build and buy are also on the table so go out on the market find out what's available to us and then bring me back the options we'll review that in two three days and based on what we review We'll revise it another ticket.
00:26:36 --> 00:26:40 We'll change the acceptance criteria and then we'll figure out how to do a demo of that To our stakeholders.
00:26:40 --> 00:26:48 So maybe the first round of the investigation, I am the stakeholder and maybe the second round of actually like integrating with whatever we choose.
00:26:48 --> 00:26:52 I will now bring the business in to inspect the potential solutions.
00:26:52 --> 00:26:57 And then based on that discussion, we'll commit money and time to actually implement something in the product.
00:26:57 --> 00:27:08 The issue here is that team will push back on me and say, well, Brian, that's not our responsibility to go out on the market and read the market research of what's possible and out there.
00:27:08 --> 00:27:26 Like that's, that's something that needs to be done and decided and brought to the tech team, not something that the tech team is going to do when the developers aren't operating directly in their skill, like the silo of exactly what their skill is, you're asking them to say like, go do research on the market, or go figure out what trend is hot on the market or whatever.
00:27:26 --> 00:27:29 Well, I don't that's not that's not my direct role.
00:27:29 --> 00:27:30 Yeah, I don't care, we're a team.
00:27:30 --> 00:27:32 I'll give you example before you respond.
00:27:32 --> 00:27:39 If you go back to the scrum guide the scrum masters responsibilities to help me, the product owner coordinate folks for the demos.
00:27:39 --> 00:27:42 You're supposed to help me manage the backlog.
00:27:42 --> 00:27:49 And help me coordinate the demos, there are so many stakeholders I'm trying to communicate with and line up for the team to make our demos successful.
00:27:50 --> 00:27:50 I need help with this.
00:27:51 --> 00:27:52 I can't do it all myself.
00:27:52 --> 00:27:57 So I need to nail stakeholder management, and I need people on the development team to help me do that.
00:27:57 --> 00:28:00 The development team is actively saying No, no, no, that's not code.
00:28:00 --> 00:28:11 We don't want to do Just like the investigation of new technologies this could be something that the development team, It's not a great example, but it is an example of, just like saying, Well, you bring me the technologies and I'll tell you how to implement them.
00:28:11 --> 00:28:16 Well, you tell me who's going to be in my sprint review, and then I'll build the demo.
00:28:16 --> 00:28:17 No, no, no.
00:28:17 --> 00:28:19 I need you to actively contribute to this.
00:28:19 --> 00:28:28 Like how can I better work with the development team to help them understand like, Hey, we're all together running a good business and being development team.
00:28:28 --> 00:28:30 The first thing we're doing is running a business together.
00:28:30 --> 00:28:34 So like, there's no, not my job kind of conversation happening.
00:28:34 --> 00:28:38 Yeah, I completely agree with that.
00:28:38 --> 00:28:41 I think it talks to the culture of the team, actually, at that point, right?
00:28:41 --> 00:28:44 you do everything to satisfy the customer.
00:28:44 --> 00:28:47 The team's looking at everything in the backlog and saying, What do we need to do?
00:28:47 --> 00:28:51 We don't know which library to use, for example, which charting tool to use.
00:28:52 --> 00:28:54 So, there's a spike story, right?
00:28:54 --> 00:28:57 And people can swarm on that.
00:28:57 --> 00:28:59 If there's three, four, five options, guess what?
00:29:00 --> 00:29:02 You know, swarm on it and tackle that as one.
00:29:02 --> 00:29:04 So, yeah, spikes, swarming on a spike story.
00:29:04 --> 00:29:09 Swarming, yeah, swarming on a spike story, if, if, and that's an important story for the sprint.
00:29:09 --> 00:29:11 I wish there was a swarm on a spike story.
00:29:11 --> 00:29:12 Yeah, I wish.
00:29:12 --> 00:29:12 That would be great.
00:29:13 --> 00:29:16 So who's I mean, that's the direction that they should be given, right?
00:29:16 --> 00:29:19 And then they need to work with the tech lead.
00:29:19 --> 00:29:21 Or the engineering manager, basically.
00:29:21 --> 00:29:31 Yeah, that's like, my feeling is, I want to paint the sprint goal in the manner where everyone understands that it is the highest priority no matter what.
00:29:31 --> 00:29:37 So I'm willing to abandon all of the stories that are in the sprint that are not directly related to the sprint goal.
00:29:37 --> 00:29:46 And it's okay if like everybody on the team just dogpiles on the sprint goal and nothing else gets done As long as the sprint goal gets done, but it's very difficult.
00:29:46 --> 00:29:56 To communicate that to engineering team members and managers who've only ever been part of organizations where Everybody gets a sign Work item.
00:29:56 --> 00:29:58 the team doesn't get assigned work items.
00:29:58 --> 00:30:00 People get assigned work items.
00:30:00 --> 00:30:04 it's difficult when people come from those cultures because they bring that with them.
00:30:04 --> 00:30:08 And then I have to tell them I don't value, utilization.
00:30:08 --> 00:30:09 I don't value it at all.
00:30:09 --> 00:30:09 Yeah.
00:30:09 --> 00:30:11 In fact, I like, it's the opposite.
00:30:11 --> 00:30:12 I, devalue it.
00:30:12 --> 00:30:14 I think utilization is ridiculous.
00:30:14 --> 00:30:15 And it's stupid.
00:30:15 --> 00:30:18 And like a holdover from the taylorism error.
00:30:18 --> 00:30:21 And it's completely ridiculous for what we do.
00:30:21 --> 00:30:24 I would rather everyone upskill on the team.
00:30:25 --> 00:30:28 And progress our velocity together more slowly.
00:30:28 --> 00:30:34 If everyone's on board with the same skills, that way in the future, it doesn't matter who on the team picks up a work item or picks up the phone.
00:30:34 --> 00:30:36 When something happens, it doesn't matter who does it.
00:30:37 --> 00:30:38 They can resolve the problem right there.
00:30:38 --> 00:30:41 It's becomes more sustainable that way because they own it.
00:30:41 --> 00:30:43 And I'm willing to pay for that.
00:30:43 --> 00:30:49 I, as a rep of the business, I'm willing to pay for that in terms of velocity salary, et cetera, et cetera.
00:30:49 --> 00:30:50 Sure.
00:30:50 --> 00:30:54 So engineering managers need to understand this idea as well, right?
00:30:54 --> 00:31:00 And if they don't they need help work with your coaches or bring an external coach for a bit to help.
00:31:00 --> 00:31:03 I think it's difficult for an engineering manager because.
00:31:03 --> 00:31:13 the question is, like you, you expect that the team is moving through the forming, storming, norming stages just by being together for a certain amount of time.
00:31:13 --> 00:31:13 Yeah.
00:31:13 --> 00:31:14 Right.
00:31:14 --> 00:31:26 And that's where it's like, somebody recommended reading the book accelerate because of this like, oh, well, we're moving through these phases and you'll understand better about how to interface with engineering and engineering metrics and whatnot.
00:31:26 --> 00:31:36 So what I did was I went through and I read the book, Accelerate in the last 24 hours, And I like, this is not meant to be a podcast on the book itself.
00:31:36 --> 00:31:41 I think the situation where you're not seeing eye to eye with engineering leadership, is much more important.
00:31:42 --> 00:31:45 It's to talk about that specific situation than it is to talk about this book.
00:31:45 --> 00:31:46 Yeah, absolutely.
00:31:46 --> 00:31:52 But there are some concepts in this book that are important to talk about in the bounds of the conversation we're having now.
00:31:52 --> 00:31:52 Yeah.
00:31:53 --> 00:31:58 In the book, they say, well, there's not really a great way to measure the performance of software development teams.
00:31:58 --> 00:31:59 Because there really isn't.
00:31:59 --> 00:32:00 I mean, every team is unique.
00:32:00 --> 00:32:03 and you can even say, well, I mean, are teams that unique?
00:32:03 --> 00:32:06 Yeah, maybe they're not totally unique, but the context.
00:32:06 --> 00:32:15 . So the four things in that book that they say to watch out for, to watch out for performance on Suffer to own team are delivery, early lead time.
00:32:15 --> 00:32:23 Deployment frequency time to restore service and change fail rate Those are the four things in that book that they say to watch out for.
00:32:23 --> 00:32:23 Lead time.
00:32:23 --> 00:32:26 Well, we covered lead time in another podcast cycle.
00:32:26 --> 00:32:27 Time measures.
00:32:27 --> 00:32:41 How long it takes for code changes to go from being committed to running in production when the development team started working on it, lead time, is when the customer requests the chain until they receive the production when the change is incepted yet to when it's what's yeah, right.
00:32:41 --> 00:32:46 I swear to you , by the time we're done with podcasts, I will get that figured out and I will not screw it up.
00:32:46 --> 00:33:03 the next one is deployment frequency, obviously deployment frequency is how often an organization successfully deploys code to production that should be able to be measured pretty quickly Do you know how to solve when your developers find it too difficult to deploy code to production every two weeks?
00:33:03 --> 00:33:05 Deploy code every one week.
00:33:05 --> 00:33:05 That's right.
00:33:05 --> 00:33:09 Yeah, so the underlying ethos here is if it hurts, do it more often.
00:33:09 --> 00:33:12 And if it's too difficult to do it every week, do it every day.
00:33:12 --> 00:33:18 And then mean time to restore, how long it takes to restore service when an incident or defect occurs.
00:33:18 --> 00:33:25 Pretty trackable and then change failure rate percentage of changes that result in degraded service or require remediation.
00:33:25 --> 00:33:27 So all these are pretty trackable.
00:33:28 --> 00:33:29 They come right out of the book.
00:33:29 --> 00:33:29 Accelerate.
00:33:29 --> 00:33:31 they're the basic tenets of DevOps.
00:33:31 --> 00:33:38 To be honest, they're not anything difficult or tough to track, but I feel these are all delivery metrics.
00:33:38 --> 00:33:39 They have nothing to do with product management.
00:33:39 --> 00:33:41 So I'll make that case right now.
00:33:41 --> 00:33:45 Delivery managers should be interested in this and maybe service managers as well.
00:33:45 --> 00:33:46 Some of these metrics, right?
00:33:46 --> 00:33:48 MTRs and so forth.
00:33:48 --> 00:34:00 The other things that the book talks about are cultural aspects, which is like how your teams work together and how they work with other teams and then Management practices, meaning like we're gonna make our workflows visible.
00:34:00 --> 00:34:02 We're gonna make our prioritization frameworks visible.
00:34:02 --> 00:34:17 We're going to make our changes across product lines and intra and inter and intra product lines visible and then create feedback loops and continuous improvement Very little of the book is new to anyone that would listen to this book.
00:34:17 --> 00:34:18 I agree with that.
00:34:18 --> 00:34:22 I don't think there's a whole lot in that book that's earth shattering or new.
00:34:22 --> 00:34:25 Think about when it came out, probably 2018 right?
00:34:25 --> 00:34:28 So, around that time, there wasn't a whole lot of new things.
00:34:28 --> 00:34:31 except, the buzz was all around the Spotify model.
00:34:31 --> 00:34:34 And the book doesn't miss out on that, right?
00:34:34 --> 00:34:35 But that's then.
00:34:35 --> 00:34:36 This is now.
00:34:36 --> 00:34:40 So when you're reading this book, if you're reading this book, think about that, right?
00:34:40 --> 00:34:42 The world has moved on since 2018.
00:34:42 --> 00:34:44 I wouldn't key in on the Spotify model.
00:34:44 --> 00:34:45 read team topologies.
00:34:46 --> 00:34:51 your streamline teams go along with your normal product lines and your streams of work.
00:34:51 --> 00:34:55 the book talks about decoupling architecture and a couple of other things that are pretty basic.
00:34:55 --> 00:35:03 a couple of good things that were in the book that were interesting to me were they talk about queuing theory, about as utilization approaches a hundred percent, the lead time approaches infinity.
00:35:03 --> 00:35:05 I thought that was pretty interesting.
00:35:05 --> 00:35:16 So like, if you're squeezing your development teams constantly for more and more and more stuff, and there's no additional bandwidth for them to do cool things or whatever of course, they're going to miss all their sprint commitments or whatever.
00:35:16 --> 00:35:17 Part of this.
00:35:17 --> 00:35:17 I don't know.
00:35:17 --> 00:35:26 Like the difficult part of this conversation to me is like the spike of like, we're doing things that we've never done before that completely unknown things.
00:35:26 --> 00:35:27 Okay.
00:35:27 --> 00:35:38 Well, if we're doing completely unknown, if we're operating in the realm of completely unknown things, there needs to be a time between check ins where you present your work, And we talk about the findings and we recommend the next steps, right?
00:35:38 --> 00:35:44 Okay I think that time should not be more than 48 hours I would prefer it to be every day.
00:35:44 --> 00:35:48 the purpose of having stand ups Is so we can check in every 24 hours.
00:35:48 --> 00:35:54 So if we're saying 48 we're saying that one of those stand ups is going to be like Still doing my thing.
00:35:54 --> 00:35:55 Don't need any help.
00:35:55 --> 00:35:56 No impediments.
00:35:57 --> 00:35:58 Everything's on track.
00:35:58 --> 00:36:01 You don't get to see anything and I'm not going to present any work to you.
00:36:01 --> 00:36:08 Like that's not, only because like I bring everything back to like the startup mentality, that's not good enough at a startup.
00:36:08 --> 00:36:10 24 hours and no progress.
00:36:10 --> 00:36:16 I mean, like startup, like we're not that tight at a startup where 24 hours gets taken to company, . Two days of no progress.
00:36:16 --> 00:36:27 I mean how many days it's a fifth of a sprint after all, you know I think people also need to not think about this kind of time box thing as a A pin on the time horizon, right?
00:36:27 --> 00:36:29 Well, Nick we'll by tomorrow's stand up.
00:36:29 --> 00:36:31 We'll know it's like That's just a calendar event.
00:36:32 --> 00:36:33 We'll find out today.
00:36:33 --> 00:36:36 And if you know something or you want to ask questions, ask questions.
00:36:36 --> 00:36:37 Don't wait till tomorrow.
00:36:37 --> 00:36:44 Well, I mean, I also feel like if multiple developers were on this together, like you would never, you wouldn't go for you.
00:36:44 --> 00:36:45 No, you wouldn't.
00:36:45 --> 00:36:49 you'd have two people and you would go a couple hours, probably two hours.
00:36:49 --> 00:36:51 You mean three hours, half a day at the most.
00:36:51 --> 00:36:54 And you would know something and you'd be ready to make the call.
00:36:54 --> 00:36:56 the other part of this, which I brought up.
00:36:56 --> 00:37:06 And then I didn't go into depth was seeing the progress of something and then deciding this stinks, we're going to abandon it, throw it away.
00:37:06 --> 00:37:13 And now I've just triggered a bunch of people , we're going to code this thing for half the sprint and then we're going to review it.
00:37:13 --> 00:37:15 And then we're going to decide we're going to throw it all away.
00:37:16 --> 00:37:19 that's where I always tell my teams, don't get wedded to the item.
00:37:19 --> 00:37:33 you're not married to it you have been in large organizations where the idea of throwing away something we're working on is insane They even suggest roll all that code out put it hit the trash button and throw it all away.
00:37:33 --> 00:37:34 But it's a cultural thing.
00:37:34 --> 00:37:35 You're right.
00:37:35 --> 00:37:38 Large organizations, definitely, this doesn't go down well.
00:37:38 --> 00:37:48 Because it's the same organizations that say, Well, value utilization, you're wasting time, you wasted a half a sprint of six people, whatever it is.
00:37:48 --> 00:37:49 but culturally, right?
00:37:49 --> 00:37:52 You've learned something you didn't know half a sprint ago.
00:37:52 --> 00:37:55 Based on that, the call needs to be made.
00:37:55 --> 00:37:57 Do we continue down this path?
00:37:57 --> 00:37:58 Which is a cul de sac.
00:37:58 --> 00:38:01 This is a no through road, right?
00:38:01 --> 00:38:02 So make the decision.
00:38:02 --> 00:38:05 The earlier you make that decision, The better it is.
00:38:05 --> 00:38:09 If you wait till half a sprint, okay, this is the earliest possible.
00:38:09 --> 00:38:10 What do they call that?
00:38:10 --> 00:38:12 The last responsible moment, right?
00:38:12 --> 00:38:13 Well, it could be half a sprint.
00:38:13 --> 00:38:14 It could be the minute you learn.
00:38:14 --> 00:38:16 It could be one day left in the sprint.
00:38:16 --> 00:38:22 You say, well, whatever we've been working on is now null and void because we've just learned something, right?
00:38:22 --> 00:38:28 So feel empowered to say, based on what we've learned, This isn't the right thing to do.
00:38:28 --> 00:38:30 Why continue on that even for one more day, right?
00:38:30 --> 00:38:36 Well, also there's the idea that we put a feature in production and then it got no adoption like we thought it was going to.
00:38:36 --> 00:38:37 And now we're going to roll it out.
00:38:37 --> 00:38:41 Like the whole purpose of feature flags is like, we just tick it off and now it's gone.
00:38:41 --> 00:38:54 Like again, this is in the same category of like, why are we going to leave that code out there that we have to maintain and deal with in the future when obviously we missed, it didn't get adoption, we turned it off, we rolled it out of the application, and now it's gone.
00:38:54 --> 00:38:58 I made the call as a product manager, I'm not, I'm not maintaining this.
00:38:58 --> 00:39:00 You know, I built this whole Jenga tower.
00:39:00 --> 00:39:00 Yeah.
00:39:00 --> 00:39:03 I'm not maintaining the top 10 floors.
00:39:03 --> 00:39:05 Just take the 10 floors off and throw them away.
00:39:05 --> 00:39:10 And now there's less chance of our Jenga tower collapsing Well, you're doing a number of things at that point, right?
00:39:10 --> 00:39:12 You're not accumulating tech debt.
00:39:12 --> 00:39:13 That's the first thing, right?
00:39:13 --> 00:39:16 The other thing is, it's the opportunity cost.
00:39:16 --> 00:39:20 Are you gonna continue working for the rest of the sprint on stuff that you now know isn't valuable?
00:39:20 --> 00:39:21 What could you be working on instead?
00:39:21 --> 00:39:30 But unfortunately, as you said, people get emotional about this, and it is ripping the band aid, but people are like, well, it hurts as much as ripping a band aid off, right?
00:39:30 --> 00:39:32 What's the best way to do that, though?
00:39:32 --> 00:39:33 Just pull and yank.
00:39:33 --> 00:39:35 Don't keep tugging away at it.
00:39:35 --> 00:39:42 So if you're a developer and you're in this situation, please understand your work isn't just pounding out lines of code.
00:39:42 --> 00:39:43 Your work is to add value.
00:39:43 --> 00:39:45 In a minute it's determined that this is not adding value.
00:39:45 --> 00:39:48 Feel free to own that and say, oh yeah, it's not.
00:39:48 --> 00:39:49 Let's move somewhere else.
00:39:49 --> 00:39:52 Also, I mean, are we dedicated to simplicity or are we not?
00:39:52 --> 00:39:53 Right, right.
00:39:53 --> 00:39:56 Or are we dedicated to everything we've ever done in the past?
00:39:56 --> 00:39:57 Like, I don't know, okay.
00:39:57 --> 00:40:03 Well this podcast kind of cropped up with the advice of, Oh, just work on your tech lead and everything will be great.
00:40:03 --> 00:40:12 Like that, that doesn't really work because again, your tech lead could be You know, they could be taking the stance of like, well the team will work itself out given time, just got to give them time to work it out.
00:40:13 --> 00:40:18 you know, you as a product manager, you will say like, well, I don't, I don't want to just give it time to work out.
00:40:19 --> 00:40:20 I'd like a little more involvement.
00:40:20 --> 00:40:24 I'd like a little more guidance to my developers to kind of push them along.
00:40:24 --> 00:40:30 Especially if we have tech leads that have seen a better way of working I'd like to move us along through these things.
00:40:30 --> 00:40:32 So that's what this started as.
00:40:32 --> 00:40:44 I mean, sometimes you do get into situations where the tech leads will be almost like confrontational and they'll say, Why you as the product manager are having an issue with us, with the team.
00:40:44 --> 00:40:47 These other product managers don't have an issue with the team, right?
00:40:47 --> 00:40:48 That can happen.
00:40:48 --> 00:40:50 But also sometimes your tech lead.
00:40:50 --> 00:40:53 Isn't up with modern ways of working, right?
00:40:53 --> 00:40:59 They came up through the ranks of development that, that arm of the company, and they can be the other way.
00:40:59 --> 00:41:02 They can say, well, you keep changing your mind too often.
00:41:02 --> 00:41:05 I want next time I want everything written down so that you don't blame the team.
00:41:06 --> 00:41:27 Yeah, because we're you keep changing your mind, especially in just what we discussed now was we found that there's no value in continuing after half a sprint or whatever, three days into the sprint, that kind of thing, they need to understand, they need to be on board with value, rather than we have to deliver all this that we committed to, because it's a two week time box, and thou shalt not change anything in that two week.
00:41:27 --> 00:41:30 So, as a product manager, you need to watch for that, I think, right?
00:41:30 --> 00:41:31 And then educate them.
00:41:31 --> 00:41:36 I mean, yes, it's the scrum master's job to facilitate, but assuming that they're on board, too, right?
00:41:37 --> 00:41:41 I haven't come across that scenario as often where the scrum master is.
00:41:41 --> 00:41:43 You know, they're simply ticking boxes.
00:41:43 --> 00:41:48 Well, it's, I mean, you're in a tougher scenario where your tech lead inherits the role of scrum master.
00:41:48 --> 00:41:49 Oh, good God.
00:41:49 --> 00:41:49 Yes.
00:41:49 --> 00:41:53 Now you've got one person who's supposed to be informed and educated on both of them.
00:41:53 --> 00:41:59 But whether they are or not, like that's a question of where they came from and what they've seen in their career and whatnot.
00:41:59 --> 00:42:00 So I don't know.
00:42:00 --> 00:42:08 I want to paint a picture that there's hope for people, but also like get, get educated and keep their resume updated.
00:42:08 --> 00:42:09 Absolutely.
00:42:09 --> 00:42:09 Yeah.
00:42:09 --> 00:42:10 Keep the resume updated.
00:42:10 --> 00:42:12 Hopefully you've enjoyed today's podcast.
00:42:12 --> 00:42:16 Let us know in the comments below any topics you want us to discuss.
00:42:16 --> 00:42:18 And don't forget to like, and subscribe.
Related Episodes
AA193 - Product Lifecycle Phases: From MVP to Sunset - A Guide for Product Managers
Discover the four critical phases of product lifecycle management and learn how to navigate each stage successfully. In this comprehensive guide, we break down:MVP: Building your initial product and finding market fitGrowth: Scaling teams and features effectivelyMaturity: Optimizing operations and maintainin...
AA192 - Reaction: Product Management is Dead!
All Aboard the AI Hype Train!!!Product management is DEAD! It died facing a high-noon showdown with AI, and the rumors of it's demise are spreading faster than a locomotive through the boom-town of Silicon Valley.In this episode of Arguing Agile, Product Manager Brian Orlando and Enterprise Business Agility ...
AA191 - Platform Product Management in Banking/Finance
Success as a platform PM requires both technical depth and exceptional emotional intelligence to navigate complex organizational dynamics...That goes double if you work in banking or finance!In this episode of Arguing Agile, Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando read an...