Very nice first article. Thanks for sharing these heuristics for prioritization. The point about truly time-sensitive work seems very interesting topic and I found very inspiring the phrase "Planning too far into the future isn’t useful to teams that iterate quickly". I am keen to read your next post. Warmest regards, Alex.
The reason management gives us for all the planning and roadmaps is the people who are paying us want to know what they’re getting and when they’re getting it before they write the check. They wouldn’t give a blank check to a contractor and say “build me a house” without blueprints, a budget, and a schedule. How would you respond to that?
So, they likely would be giving a check to a contractor who, statistically, is going to have an incorrect budget and an incorrect schedule. That house, despite having a blueprint, and a budget, and a schedule, is statistically going to be both later and more expensive than planned. It's not a blank check, but it's not not a blank check.
Is it helpful to management to have planning and roadmaps that are going to be inaccurate? Are they aware that producing them at the level of fidelity they're asking for is time-consuming, and takes away from the time actually building the product? Are they going to be upset when we inevitably don't hit them? Are they going to pressure us to "do things quicker", or balk at the estimate of time we give them, if we try to build in enough buffer?
Let's continue with the construction example. We have our plan and our blueprint and our timeline all tied up with a bow. We break ground and immediately find a broken foundation, or a messed up water main, or an archeological dig site. We go to you and say "we've gotta delay this, we have to fix the foundation before we build anything further". Are you going to say "no, skip that, we really need this house built in two months and we don't have time"? No, because you don't want to deal with the more expensive fix for that later on, and your house would be out of code. That happens to software projects all the time. It's not good!
If you sit down with the people who are paying you, and you say "look, you want a house. We want to build you a house. We haven't started building you the house yet, so we really don't know what types of things we're going to encounter along the way. We're going to do the riskiest parts of building the house first, because those are likely to be hiding all the surprising bits that could delay this project. We'll sit with you every week and tell you how we're doing at building the house. When we approach the end of building the house, we'll start telling you when we think you'll be able to move into the house, and we'll gradually get more confident with those estimates as we go. If we hit something that's going to tank the budget, we'll tell you as soon as we can. But we can't tell you for sure right now how expensive this house is going to be, or when we'll be done.". Is that satisfactory to them?
Maybe you've built a million houses exactly like this house before, with your exact team! Maybe you do actually know how long this is going to take you this time around. Those situations are incredibly rare.
People seem to like being lied to about roadmaps, because it makes them feel reassured. It's harder to do the work of saying "if I give you a roadmap, I'm lying to you. If that's ok with you, I will lie to you, but we both need to understand that I'm lying to you", but it's more accurate to reality.
Fantastic post! You've helped articulate many of thoughts I've been having and given me some new things to think about. Sharing this with my team and looking forward to the next one!
Whenever I try to bring these types of argument up, the inevitable response I hear is that "deadlines are required in the real world". I would love to hear how you respond to this.
I'd love to hear about what context folks are saying "deadlines are required in the real world" in. Is it just that, your team pushes back on a deadline and then somebody goes "hmpf, well, deadlines are required in the "real world" so we should have one here"? Is it "well, this project is tied to this event outside the company and we want to align with that"?
Typically the former of those two, rarely the latter. "Required" was probably the wrong word to use. "Useful" is closer to what I usually hear.
My objection to that argument is that these deadlines are built on the impossible premise that software projects can be accurately estimated, and that the deadlines end up hurting everyone involved. As an alternative, I pitch an approach similar yours: focusing on making smaller changes, prioritizing learning, shortening feedback loops, etc.
Sometimes I feel like I can get through to people, but often it seems that there's just this inherent appeal to deadlines that's very difficult to overcome.
I think a lot of what you just said is also what Matthew and I are talking about in another thread on the post: it's basically impossible to accurately estimate, and the fallout is really painful.
I imagine it's really comforting to be lied to about deadlines, if you don't fully internalize that you're being lied to. It's easier to swallow "we'll be done in a month!" vs "the future is vast and unknowable and we might be done in a month but we probably won't be!"
Very nice first article. Thanks for sharing these heuristics for prioritization. The point about truly time-sensitive work seems very interesting topic and I found very inspiring the phrase "Planning too far into the future isn’t useful to teams that iterate quickly". I am keen to read your next post. Warmest regards, Alex.
The reason management gives us for all the planning and roadmaps is the people who are paying us want to know what they’re getting and when they’re getting it before they write the check. They wouldn’t give a blank check to a contractor and say “build me a house” without blueprints, a budget, and a schedule. How would you respond to that?
Good question, and an interesting example. Construction projects famously go over time and over budget (depending on the study you look at, only 25% of construction projects get completed within 10% of their original timeline (source: https://assets.kpmg/content/dam/kpmg/pdf/2015/04/global-construction-survey-2015.pdf) and 86% of construction projects go over budget, by an average of 28% (source: http://www.ijimt.org/vol8/717-MP0022.pdf)).
So, they likely would be giving a check to a contractor who, statistically, is going to have an incorrect budget and an incorrect schedule. That house, despite having a blueprint, and a budget, and a schedule, is statistically going to be both later and more expensive than planned. It's not a blank check, but it's not not a blank check.
Is it helpful to management to have planning and roadmaps that are going to be inaccurate? Are they aware that producing them at the level of fidelity they're asking for is time-consuming, and takes away from the time actually building the product? Are they going to be upset when we inevitably don't hit them? Are they going to pressure us to "do things quicker", or balk at the estimate of time we give them, if we try to build in enough buffer?
Let's continue with the construction example. We have our plan and our blueprint and our timeline all tied up with a bow. We break ground and immediately find a broken foundation, or a messed up water main, or an archeological dig site. We go to you and say "we've gotta delay this, we have to fix the foundation before we build anything further". Are you going to say "no, skip that, we really need this house built in two months and we don't have time"? No, because you don't want to deal with the more expensive fix for that later on, and your house would be out of code. That happens to software projects all the time. It's not good!
If you sit down with the people who are paying you, and you say "look, you want a house. We want to build you a house. We haven't started building you the house yet, so we really don't know what types of things we're going to encounter along the way. We're going to do the riskiest parts of building the house first, because those are likely to be hiding all the surprising bits that could delay this project. We'll sit with you every week and tell you how we're doing at building the house. When we approach the end of building the house, we'll start telling you when we think you'll be able to move into the house, and we'll gradually get more confident with those estimates as we go. If we hit something that's going to tank the budget, we'll tell you as soon as we can. But we can't tell you for sure right now how expensive this house is going to be, or when we'll be done.". Is that satisfactory to them?
Maybe you've built a million houses exactly like this house before, with your exact team! Maybe you do actually know how long this is going to take you this time around. Those situations are incredibly rare.
People seem to like being lied to about roadmaps, because it makes them feel reassured. It's harder to do the work of saying "if I give you a roadmap, I'm lying to you. If that's ok with you, I will lie to you, but we both need to understand that I'm lying to you", but it's more accurate to reality.
Fantastic post! You've helped articulate many of thoughts I've been having and given me some new things to think about. Sharing this with my team and looking forward to the next one!
Whenever I try to bring these types of argument up, the inevitable response I hear is that "deadlines are required in the real world". I would love to hear how you respond to this.
I'd love to hear about what context folks are saying "deadlines are required in the real world" in. Is it just that, your team pushes back on a deadline and then somebody goes "hmpf, well, deadlines are required in the "real world" so we should have one here"? Is it "well, this project is tied to this event outside the company and we want to align with that"?
Typically the former of those two, rarely the latter. "Required" was probably the wrong word to use. "Useful" is closer to what I usually hear.
My objection to that argument is that these deadlines are built on the impossible premise that software projects can be accurately estimated, and that the deadlines end up hurting everyone involved. As an alternative, I pitch an approach similar yours: focusing on making smaller changes, prioritizing learning, shortening feedback loops, etc.
Sometimes I feel like I can get through to people, but often it seems that there's just this inherent appeal to deadlines that's very difficult to overcome.
I think a lot of what you just said is also what Matthew and I are talking about in another thread on the post: it's basically impossible to accurately estimate, and the fallout is really painful.
I imagine it's really comforting to be lied to about deadlines, if you don't fully internalize that you're being lied to. It's easier to swallow "we'll be done in a month!" vs "the future is vast and unknowable and we might be done in a month but we probably won't be!"