Menu
It's not always easy to know if your team is being productive. Are you prioritizing the right things? How do you decide what to do first? These are questions that many product and engineering teams struggle with. To help us figure this out, we're excited to welcome Elle Meredith and Lachlan Hardy. They'll lead a discussion about what being productive really means for our teams.
Elle and Lachlan will help us think about:
About the speakers
Elle Meredith runs Blackmill, a company that helps tech teams work better. She's done a lot of cool things in her career:
Lachlan Hardy started Blackmill with Elle. He's worked with many different tech teams over the years:
Both Elle and Lachlan really care about making tech teams work better and helping people enjoy their jobs more. They're excited to chat with us and help us think about how we can be more productive in ways that actually make sense for your team.
See below for:
.png)
.png)
.png)
You can view the slides from the talk here - and see below for the full recording.
>> Vivek: Multitudes goal is to make tech more inclusive and equitable. And the heart of our product is in diversity, equity and inclusion. And we work with teams to work better and make sure that they are equitable and inclusive. Part of the reason why we kicked off the tech leader chats is we wanted to create a space, for human centric leaders, to learn and grow together, and with their peers, especially for folk who do care about justice, equity, diversity and inclusion. and we want to make sure that we all grow and learn together. The plan for today is, we're going to have around a 30, maybe a bit longer presentation, interactive session with Lachy and Elle. This part will be recorded and shared afterwards. And then we'll probably have a little bit less time today for the breakout room because the session is going to be interactive as well. Feel free to put your questions in the chat today. and we'll look and monitor them while we're here.
Lachie and Elle have been fantastic members of the TLC community
Really excited now to introduce, Lachlan and Elle. I was just talking to them before this and I was like, I can't actually remember when I met them, but I have met them several times. but it turns out I think the first time was when, very early on in the days of multitudes. both of them gave some great user research feedback to Lauren and Jenny, who are also in the founding team of multitudes, and then have had subsequent chats in person and on Zoom. And they've been fantastic members of the, TLC community as well. Both Elle and Lachlan have got kind of their own prolific careers within tech, I think leaders at organizations like Atlassian and GitHub, and then organize lots of big conferences like Rubycon, I think, as well. so super. I think that was Elle. You organized Rubycon. Yeah, just lots of experience in all sorts of spaces and great humans. So super excited to have them, chat with us today. And now they run Blackmill consulting, which a bunch of you might already be familiar with, having done their amazing workshops.
So that's enough from me. I'll hand it over now to both Elle and Lachy. and I'll let you share your screen as well.
>> Lachlan: Cool. Thanks so much, Vivek. Really appreciate the intro. Yeah, I was trying to work out how we met too, and it's through that I don't remember when we first met. I do remember burgers at some ludicrous place in Melbourne though, which is maybe a bit more recent. Elle's got our slides up. This is super cool. Hi, everybody. welcome. as per the chat, Elle and I are coming to you from beautiful Bundjalung country in northern New South Wales, Australia. we live in a tiny town called Mullumbimby, which you've probably never heard of, but it's kind of near Byron Bay, which you probably have heard of. we are, going to do something a little bit different today, as Vivek kind of pointed out. And we did try and put in the notes and in the promotional stuff. This is intended to be a discussion, so I hope you all brought your morning voices or your mid morning voices for the, for the kiwis. because we're going to ask a bunch of questions and we want people to get in and amongst this with us. Michele has seen me attempt this before, so she knows what's about to happen.
>> Lachlan: Elle, do you want to say anything before we get into it?
>> Elle: yeah, so, we usually do this session for like two and a half to 3 hours. So trying to do this in 30 minutes. Gonna be interesting. we have a few points here that we want people to talk, but, we might be a bit more tight on time. So if we ran out of time and we didn't answer your questions or you had a point to make, either post it in the chat that we might go back to it later after the talk, or I post it in slack and we can have a conversation in there.
>> Lachlan: Yeah.
>> Lachlan: Cool, cool.
>> Elle: Shall we start?
>> Lachlan: Yeah.
>> Elle: And I guess we are starting immediately with asking you a question, which is, how do you define team productivity?
>> Lachlan: Everybody says they want a productive team. You got CEO's and board members asking you about productivity. Do you actually have a definition? You are welcome to come off mute and get amongst this. Or you can, I guess, write it in the chat. I do have the chat open. Three people are like, there's a discussion to be had. I am out of here.
>> Elle: okay, I'll jump in.
>> Lachlan: Go on, have a crack.
>> Elle: I think it's about building the right thing at the right pace, which I think is very perceptive. So, very much a perception of who thinks you're building a pace, and probably more a leading indicator is the team feeling engaged and they're making a difference.
>> Lachlan: Okay. So, right thing at right pace. Team is engaged and feel like they're making a difference.
>> Lachlan: That's, that's some pretty good coverage. I like that a lot. Does anybody have anything to add to that definition? Is there anything missing from that that we would add?
>> Elle: I could.
>> Sorry, I feel like I just spoke over somebody. I think maybe just add to that. But it's always similar. Just, consistently working on the highest value add thing. So just always concentrating on that, like, the highest value piece, of work.
>> Lachlan: Cool. Yep. a few people in the chat are mentioning sustainability as well. Vivek has talked about, like, healthy, inclusive environment, you know, high quality work, et cetera. Anybody got anything further? Have we completed the full definition of productive team access to the right tools and consistency? Lisa, could you say more about consistency and definition, please?
>> Lisa: so what I mean is that we define productivity and we stick to that same definition. where I'm working today, what defines success changes on a regular basis.
>> Lachlan: Right, right. Yeah, I've worked at that place, too. for places like that. Yeah, that's hard. working towards the same goal. Awesome. See, this is the thing I love about. This is the first version of this. We got Washington four, four items. Cool. well, yes, what I was saying is, what I love about this is, you know, even the first cut at this had four elements to it, and since then, people have said another 810. Right. And I think you could make a pretty strong argument for all of those being an element of this. Perhaps if we're being strict, we can take some of the team health, inclusivity, sustainability bits and put them in a separate, very important bucket. That is maybe not part of the definition of productivity, but I don't know. I kind of like that all of these fit in here.
>> Elle: so the way we define productivity is, I guess similar to Anna's definition, which is delivering and some of. Some of the things that people say, but delivering value on a consistent, cadence on a frequent cadence, which means, so you can ask some questions about that, like, does your team plan and work on delivering value? can anyone in your organization see progress? And that's going to be connected to other things we're going to talk about soon. is this happening as a norm, like continually, consistently, And does the team know the right delivery cadence for the market? For example, we've worked with engineering teams that work in the health, in the health industry, and they have to deliver, things according to specific standards. So their cycle is 18 months at best before they can ship something to, you know, to the market. But I, when we talked to them about delivering on, you know, on a cadence, and frequently they considered UAt and shipping stuff to Uit as a measure for them to know whether they are delivering stuff frequently. so if you look at all of those questions, how does your teams where you work now? Fair? Like.
>> Lachlan: Hopefully, everybody feels like their team is working on delivering value. although sometimes, sometimes, you know, sometimes that we or the members of our teams, our colleagues, may get a bit jaded about whether or not this particular piece of work is, valuable or not. so how do you know this is, Yeah, like, how do you define value? How do you know if and how do you assess this piece of work against delivering value?
>> Elle: like, I see a lot of things, for example, that are very, very busy and they work a lot. And, you know, busyness does not mean that, you are delivering value. So you might see tickets moving through, but to be productive, in our definition, is delivering value to the end user. That means working closely, closely with product to define what that looks like.
>> Lachlan: Yeah. m Michele has mentioned in the chat, like, right, delivery cadence is arguable, and I think value is arguable, too. In general, I think all of these things are, And one of the things we want to do here is challenge you to consider that, right? Is the work we're doing valuable? How does it tie in? Does it, in fact, meet those goals that somebody mentioned at the start of the quarter or at the start of the year or whatever? some places have really good practices of assessing that and reassessing that periodically, but some places, you just kind of get your head down and you're still going. And so, this is perhaps a call out for those people who are in the latter kind of place to stop and look up a little bit and make some assessments. it's also to, Vivek's, questions about who defines what is value. Right. if it's not your team in.
>> Elle: Collaboration with product.
>> Lachlan: Then maybe there's something to assess there as well. Right? Like, how do you have a sense of ownership, how do you have a sense of engagement with the work when it's arbitrarily defined by some externality?
>> Elle: Cool. A couple of things that Vivek was saying. Is it, who defines it? Is it sales? I really am not a fan of sales. driven development.
>> Lachlan: You work at a consultancy
>> Elle: Yeah. But, you know, it never works because whatever works for maybe one client might not work for others. And this is not the right, process to decide what you should be working on or not. And unfortunately, that's the case in many companies. You ask, what about the platform team? The users for platform teams are the engineering teams, for example. So they will be, they will define who is the user and what's working for the user. By the actual internal. They have a lot more access to the user itself when they work on a platform team. Yeah, yeah. if we move into prioritization, we talked about how to define what should we work on. That involves prioritizing the right work.
So we have a few other questions for you. in your does, the business and the team using shared language to talk about goals and progress, or does the team have access to all the business information that they need to be able to make the right decisions? And are they empowered to make those decisions once they have the information?
>> Lachlan: So I would love to, like, ask somebody here if they want to speak to any of those questions, for where they are. Right. I'm particularly interested in the shared language. One, are you speaking in isolation? Like, do the nerds talk about stuff in terms of performance and things, this and that, and, have, throughput of the blah or load of the data, databases, or are you talking in business value in the same way as the c suite is?
>> Elle: I know that I can pick on Michele, so, Michele, I would love to hear how you can pick on me.
>> Michele: I was just thinking that I discovered, in fact, just yesterday afternoon, that the reason our team feels like, we're being treated as a vendor is because the rest of the business actually regards us as a vendor. So, that makes these questions extra interesting, because, we don't have this shared anything, apparently. So, no, we are not empowered. We don't have access, and things are done to us instead of with us. And now I'm like, how can we change this? So, yeah, it's an interesting, we find ourselves in an interesting space.
>> Lachlan: Yeah. something I've always wanted to try in that circumstance, but never had the positional authority or lack of cares, to give, to try was to be like cool if we're the vendor, let's have this negotiation, and then offering up the actual cost back to the other in terms of actual real numbers.
>> Michele: apparently behind the scenes that's what they're doing. They're doing internal billing and weird stuff that I didn't know until yesterday.
>> Lachlan: But this is the thing. So if they're doing that, then you should be part of that process so that you can be like, this is supposedly worth this to the other part of the, and actually make that part of the conversation. So it's not this hidden thing anymore, and it becomes a real thing. And then you can discuss like, is this actually delivering value? You're going to spend $300,000 to get this feature shipped. Is that actually useful to us on that business value? Is it going to deliver, x times 300,000 or is it not? But if you're not part of that conversation, you can't, you know this. I mean, the vendors just don't get invited. Yeah, of course. But I think it's interesting, right, because the shared language is apparently money, but they weren't sharing it with you, right?
>> Michele: Yes.
>> Lachlan: does anybody have a different example from their organization?
>> Vivek: I think Lisa, you had your hand up, so.
>> Lachlan: Oh, I can't see hands up, sorry.
>> Lisa: Yeah, yeah, no problem. so our situation is actually really interesting because, we were originally a wholly owned subsidiary working pretty much like a startup. And the home, company absorbed us after we made enormous amounts of money and as the startup type approach. But it's a very large company. Right. So the entire culture is changed, but they never actually transitioned us. Exactly. so first of all, there is no shared language on anything, much less goals and progress. They kind of viewed us as a tool instead of a product. And it took me about six months to get them to understand that, hey, not only are we an actual product, but every one of your externally facing products relies on our product to be successful.
>> Lachlan: Right?
>> Lisa: So if we're not successful, the whole business unit goes down. And so they've, they've now kind of started to understand that, but they still kind of treat us like an interloper. So, I'm not given any view into pipeline, I'm not given any view into finance, or sales. they don't include the product managers in conversation about prioritization. so it's actually a really strange place to be in. And I'm the only strategic product manager. The rest of them are kind of technical product managers that are taking their cues from executives on other products.
>> Elle: so I think this reminds me of a lot, a lot of the way people work and hopefully it's changing. It is the old factory way and treating engineering as the last part in the production. So it's been decided by management someplace and leadership someplace else, and then being communicated to engineering. This is what we want and engineering is not proud of the process.
Nathan: I really like this diagram by amplitude. I think its really cool
Which brings us to like, I really like this diagram by amplitude. and it talks for, you know, a waterfall way of working. When somebody else selects the opportunities, somebody else, and then they pass it over to somebody to do the planning of the requirements and then somebody does the design and the build and the test and release and then run and everything is separate and you kind of pass the work over the fence to somebody else to do the work. and if you look all the way down to the bottom, which is a product teams, whereas engineering is a valid and active member, in the process. So they are involved in the opportunity selection and requirement planning and all the other parts of the process. Now, when I look at this, the majority of my engineering career I worked at ah, a feature factory when somebody else selected the opportunities and then I picked a ticket out of a backlog and I planned the requirements and I kind of specced, it out and then did the design and did all the rest of the stuff. I think the only place that I worked as a product team then where the product owner, ah, which was also the founder, was part of the team and we were working together was at thoughtbot. But that doesn't happen in a lot of places. Nathan?
>> Nathan: yeah, I was just going to kind of chime in there and say that we've got like an interesting approach to this. We've been using this exact image internally to talk about this as we're doing a bit of a change at the moment. We started out at ah, probably the third rung there where you've got the agile release, where the design team is separate to the dev team. And we've been slowly moving down that with the intention of mostly operating at the product team level, like probably second from the bottom. but we're looking at it as it's more of a menu. Depending on the thing that you're working on, you can operate at a different level. There's certain things where no one's ever going to get opportunity selection. For example, if you need to have a feature like SSO to sign an, enterprise client, that just has to happen. You don't get much say in how that's designed or how it works. There's standards for how it has to work, those sorts of things. You'll be operating at a different level as a product team, but then theres other times where as a business you decide that you just need to move some metric and youre like, we need someone to focus on this metric and then thats when you're operating at that opportunity selection level.
>> Lachlan: I think its really cool. I really love the idea of evolving your organization and team to the degree that you can be flexible about this, depending on the work you're doing. I think that's exactly. Really? That's ambitious. I think it's also tell me how it goes.
>> Nathan: Yeah, I'll keep you updated.
>> Lachlan: That's cool, though.
>> Nathan: So far, everyone seems to be like really on board with it and they like it, they understand it. I think it seems more realistic as well. to everybody.
>> Lachlan: Yeah.
>> Nathan: but yeah, there's definitely like a training element where you kind of like teaching engineers that like, hey, you have to be involved in the really early process and changing people's opinions on what counts as work. Often people think that, oh, I'm not writing code, so I haven't done anything today. That's not the case. If you've been in workshops trying to figure out how a thing works, you've been talking to customers, that's just as important. So there's a lot of culture shift involved in it and it's certainly not a quick process overnight.
>> Lachlan: Yeah, that's a really good call out, too. That's something that we say to people a lot is like, we talk about all of the aspects that are still work. Right. Going to that meeting is still work. Interviewing people to join your team, how do you not view that as being work like, that's definitely work. Right. there's so many elements of modern, design and development and product management that aren't, ah, strictly part of the discipline, but are part of the work. And, teaching your team to recognize that, I think is really powerful.
>> Elle: Yeah. this makes me think of engineers that think that just shipping code is work. And there's a lot of, you know, beats around a lot of other stuff that they need to do that is work too.
Michele: I'm curious about how product teams approach product roadmaps but if we move to product roadmap, I'm curious to hear like, the people here, the teams here have roadmaps. and how do you approach it?
>> Speaker G: I can talk to that a little bit. we have roadmaps where we are that our product teams put out, like our product people put out. So they collaborate to just do one big product roadmap for the whole business for about three months in advance, but they keep it really high level. And one of the things that we found probably a year and a half, two years ago, when all the teams were individually doing their own product roadmaps and in quite a lot more detail, is that teams got quite inflexible about change. Like, if new priorities came up, they were really attached to the roadmap that they had in front of them, and so had a really hard time moving away from that. And so we've kind of gone with this kind of big picture. Here are the priorities that we'll be working to, but these might change.
>> Lachlan: Fascinating. yeah, we've had the same experiences, and I think one of our ideas for, Well, I mean, we've obviously stolen this from somebody else because these are not our graphics, but I need to find.
>> Elle: The reference to give credit.
>> Lachlan: We have the article in slack.
>> Elle: Yeah.
>> Lachlan: I really love this idea. Right. because, like, I. And the way they've named it, like, misleading roadmap. This follows, this follows, this follows this. Nobody's roadmap has ever actually worked like that. or at least not for at least four items in a row. Maybe for one or two, sometimes three if you're lucky. but I love the idea that then you sort of have this spectrum thing, which is quite cool, and it's more like, yeah, we're not exactly sure what's going to happen out there, but it's got to be looked something like this. but what we've done with a bunch of clients in the last couple of years, and one in particular really adopted this, they got right into it. And so for the next two months ahead of time, they have, like, this is what we're doing. And beyond that, they have this sort of, they literally have this, this open diagram. They drew it all in Figma, and they have like, here's just some boxes that identify the various things that are probably important. Next. Yeah, it's totally a now, next. Later thing.
>> Elle: Yeah, I was, I was going to say.
>> Lachlan: And then beyond that, they just have this amorphous, list of things. It's just large and unprioritized. and they do actually migrate them from one to the other. And then make a fuss about it. And, it's really fascinating to see like the certainty increase as you come closer to, to the left of the diagram.
>> Elle: yeah, the idea I really like, Michele, the now next letter and we are the now needs to be very defined and specific and, tangible. whereas next is a bit more fuzzy and later is like ideas that haven't been specked out yet and haven't been explored. And that gives you a lot more opportunities to kind of change your mind later as you know, as you learn more and can make more educated decisions.
>> Lachlan: Yeah. the sliding quarters version that Lisa mentioned in the chat is really interesting too, especially if sometimes you may have a certain one that's actually like four quarters out. I think that's really interesting. that's cool. I would love to see how that works visually.
>> Elle: when we talk about speed versus quality, I'm, pretty sure a lot of people here are familiar with the, project management triangle.
>> Lachlan: Is it the iron triangle?
>> Elle: Yeah, that is, it talks about. It's like a theory of constraints. You can have time, cost or quality, and you can have two, but not all three. So a lot of time we talk about cost is a, decision mechanism to decide whether we can or cannot do something. But, there's something that I wanted to say. the idea is that the quality of the work constrained by the project budgets, deadlines and scope of features. so if you pick, for example, the time and cost, you will, compromise on the quality. if you choose quality and cost, then time will be, compromised and it will be a bit slow. And if you choose time and quality, it will be very, very expensive. But, people think that, by adding pressure, they don't believe, if the team is sorry, you should drink.
>> Lachlan: More of your coffee.
>> Elle: Yes. sometimes, if the developers don't believe that there is a purpose to the work, then they might not be motivated. So there will not be a sense of urgency. So to get them to deliver faster, people think that, they need to add pressure. We need to add a deadline for people to deliver. But however, that comes at a cost because, they will deliver faster, but that will hinder on quality and that will increase your technical debt. on the other hand, like, the next argument we can talk about is cost. And if your velocity is very low, then, everything is going to take a lot longer. And the biggest expense that you have is people and people hours. And then it will cost you a lot more. If you're not delivering things fast. but the problem with a lot of those things is that you create, a technical debt. And you can look at a technical debt is, a metaphor that frames how we think about dealing with low quality or high quality complex code. Now, technical debt makes it harder. then it would be ideally to modify or extend the application further. And I think everybody here knows that. But, I like a quote by a guy called Ward Cunningham that says, if you develop a program for a long period of time by only adding features and never reorganizing it to reflect your understanding of those features, then eventually that program will simply does not contain any understanding and all efforts to work on it will take longer and longer. So really we need to stop and kind of rethink about how do we understand the problem that we have? And is it organized well? so to be able to know whether we are going fast enough, or are we delivering or focusing enough on quality, then we need metrics. Now, if we have no metrics, that leads to decisions that are based on opinions and the decision will be uneducated. And this is very, very risky to the business.
So my question is, to people is what metrics do you like? to, ah, watch, I guess, or monitor? Do you have anyone?
>> Lachlan: Maybe just throw them in the chat as you, as you think of them, because we'll end up with some giant list that everybody can refer, to cycle time and throughput. Now you have to define a cycle, but yeah. Cool. So some of the ones that, Michele is the only person tracking. Tracking, metrics. Everyone's like, I came here to this talk for the metrics and you're asking me to provide them. Okay, cool. what's that one, Vivek? Is that weekly active users?
>> Vivek: Correct. Broken down also by user type as well, like ic versus managers versus vps.
>> Lachlan: Yeah, yeah, cool. And, I guess that's particularly useful for newly introduced features, but in general gives you a, I'm interested that it's weekly. Yeah, that's, that's cool. time invested in building new features versus maintenance. Yeah, we're going to talk a little bit about that.
>> Lachlan: Two out of four of the Dora metrics. Couldn't get the other two in there. Fan. That, that didn't, they didn't go for that.
>> Elle: have people here heard about the devx framework as well? What do people think of that one?
>> Lachlan: You're just going to ask me what they think of Dev X?
>> Elle: Yes, yes. Lots of thoughts.
>> Lachlan: Yeah.
Failure, uh, demand and new work are examples of metrics
So we're going to jump to the next slide, which is in some ways a form of metrics as well. Right. So these are some ones that I find really interesting to think about if we go back to our original question about productivity as a team. and so like sometimes people look at this and they go, this is, these are, these are, you know, they contrast with each other, they interrelate, but they're not like opposites. Right. So new work, you can probably define that as features, although some people have really specific terms for what a feature is, et cetera. But it's new work. Right. You sat down, you thought about it and you went and did the thing. It is almost always planned work, but not always. Yeah.
>> Lachlan: Failure, demand, if people are not familiar with that term, of art from broader industry like, you can think of failure demand as bugs, incidents, anything which requires your labor due to past failures, due to some sort of quality error, et cetera. So a production incident is failure demand, but so is fixing a bug. And this is why I think this is interesting because fixing a bug is probably planned work. It's not unplanned work, whereas an incident is unplanned work.
Michele: Trying to track these items and assess them is a really interesting challenge
Yeah. So trying to track these items and look at them and assess them I think is a really interesting challenge that I want to talk to a little bit, but I want to ask Michele, what's up?
>> Michele: correcting failure demand. Would you count refactoring the s*** code you put in before as value demand?
>> Lachlan: no, not unless it's caused something. Right. If it's caused an incident or if you've had a bug raised against it, then that is value demand. But if you've looked at it and said that's not to where I want it to be and I'm going to go back and fix it later, and then at some point you go back and fix it later or if later you've gone, we need to fix this thing before we can move to the next thing.
>> Michele: Yeah. So failure is definitely an incident or a bug.
>> Lachlan: Yeah. I mean there's probably some other edge cases you could call failure demand in various circumstances, but in general and outages. Yeah.
>> Michele: That's an incident, right?
>> Elle: Yeah.
>> Lachlan: Only do it? No, but yes. so for me, refactoring, ah, something like that's. I have improved my understanding and now I wish to revise this thing. although I guess it is also I have found more time, somewhere, somebody had ah, sent a question in that was around, like how we've helped teams turn around from being unproductive, blah, blah, blah. I want to give the example of a team wherein I convinced, an engineering manager I was fractional vp of engineering, blah, blah, blah, I convinced an engineering manager he wanted to change the way his team worked and I convinced him to roll in measuring these as part of that. And he was looking at them as trends, right. Like the past three months of is this going up or down or wherever. we never looked at exact numbers. He never gave exact numbers to anybody else. It was purely, are we trending upwards or downwards and depending on like for new work, if we're trending upwards that's good. For failure demand. If we're trending downwards that's good. And it was just those assessments. And within three months of him rolling out this practice, every other engineering team in the decided they wanted to migrate to the same practice. All the PM's were in love with him and we all hit our okrs and everybody was happy. It was nice.
>> Elle: I want to suggest that any whatever you're tracking a number in a specific, time, stamp is not useful. Generally what you do want to do is you want to track trends over time. So you want to look at those things and say, how many bugs have we had? Is that going up or is that going down? And look at the trends so you can do something about that. But I think out of all of these things, I do want to point, out work in progress and blocked items because you don't want to have too many things in, work in progress. And we'll talk about this in a second.
The last couple of questions that we have for you before we start to wrap up is determining momentum. So the questions that we have is how small is the work to deliver business value and how quickly is work considered done. And for considered done, you need to have a good definition of what done looks like, which sometimes, you know, some teams are, struggling with and how visible is the work and its progress to everyone. Do you? So I'll give you an example. We're working with one team and they work on big, big projects and the project never have an end date so they don't feel like they are delivering stuff because nothing actually ever ends. So you can't celebrate when something ends and you know, and work just.
>> Lachlan: Feels like they finished a project last week and nobody talked about it because they were so embarrassed that it had taken so long to finish. So they didn't even celebrate it when they did finish a project.
>> Elle: So what we want to advocate for is try to keep the work items very, very small. So my preferred size of a work item is maximum a day, and preferably less a day, maybe two, but preferably less. So I am able to ship prs, like one or two prs in a day at least. And I've seen teams that the bare metrics, they shipped 8 prs in a month and that seems like a lot and it blew my mind. So, you know, different sizes of work.
>> Michele: I like capability slicing for some of this stuff as well. So when I joined the team that I'm in right now, they were sort of working on individual features and I was like, hey, what if we did a thing where we did the minimum amount that would make something actually useful to a user and we changed how we were building so we could actually show progress and be like, hey, look, now someone can log in. Now they can log in and see their accounts. Now they can log in and see accounts and transact on them instead of just building like arrears and payments and things separately.
>> Elle: I literally had this conversation yesterday. building mvp means does not mean that when you build a car, you know, you have the diagram. When you build a car, you build the wheels and then you build, but instead you build like a skateboard.
>> Michele: Skateboard, scooter, bike. Yeah.
>> Elle: So on.
>> Speaker G: Cool.
>> Elle: what we want to suggest for productive teams is, I want to suggest that momentum is so much more important than urgency. so what we want to create, what we want to suggest is that everyone on the team has a shared understanding of the big pictures and what good looks like. So they earned, so they don't burn cycles, unnecessary or not useful work. We want to suggest that the team breaks the work into very small pieces, a couple of days of work at most, that will represent incremental business value, even if it's not user facing features. that will make things so much easier. Also, to review the code and I and so many other benefits. We want to suggest that the team embraces technical practices necessary to ensure, quality of work, that the code that they deliver does do what it intends to do. so we don't end up with lots and lots of bugs and, failure, demand work later. We want to suggest that the team is engaged and responsive and, you have an engaged and responsive product manager who is considered part of the team, rather than a, separate business functions that gives the work to engineering. we want to suggest that the work and its status is visible to everyone in the. So that, engineering is not a black box and leadership doesn't know what's happening in engineering. And the last thing, all of this can only happen when the team as a whole has a strong sense of partnership and trust, so that visibility never becomes a mechanism for micromanagement. And the last thing is, we want to suggest that slow is smooth and smooth and fast. And the idea in this is, if things are not going well, reduce the work in progress, reduce the scope of the work so that you can, get the wheels running well and smoothly so that you can start moving faster later. And with that, we are done. thank you so much.
>> Vivek: Awesome. Thank you so much. Elle and Lachy, we will do the breakout rooms go a little bit shorter this time. So this is where, I'll stop the recording. so anyone who's listening, thanks for listening. And you'll hear the recording stop now.
