I mean, who isn’t!? I wanted to pull at this string a little though, to see what’s there. I’ve been finding myself setting expectations that are sunnier than they should be for years now, and then I deal with the pain of attempting to deliver on a promise that stretches me too thin.
First, people pleasing. I like to say yes, I like to agree, I like to give reassurance. It feels nice in the moment, but in a team setting, it’s not so functional. Not only am I setting myself up for more stress, I’m passing that on to others when the delivery date starts slipping. My optimism turns sour, and then that hurts more than it would if I had set expectations.
Second, the art of time estimation. Even for someone who has more realistic planning senses, it’s hard to estimate time. Most things take longer than you might think, due to hidden complexity. I’m coming at this from the perspective of development, but it’s true about many things. I think, sure, I’ll do all my laundry today, but I didn’t look into it enough to realize that it’s actually 4 loads. I can always do half today and half tomorrow.
Third, a little more about hidden complexity. Software is hard. Even things that are not tangled in spaghetti code are still pretty spaghetti. Maybe you’re thinking about the code you’re going to work on, but when your build tool does that thing where it’s a build tool, it can mess up your plan pretty quickly. It just doesn’t take much to get things headed off course, and sometimes it’s not anyone’s fault.
In general, I feel like this is one of those things that you just have to work on by yourself. It wasn’t taught in business school, no one is going to come help me work through this, it’s just something I need to practice. So, how does one go about that? I’m going to try not to be too optimistic about how quickly I can course correct…
This feels like too generic of an answer. It might be a good thing to pilot though. Maybe try it out, see how it helps. Apply it in scenarios where it seems useful. Also, round numbers. It’s a good tool because of rememberability.
The more you know
This one is pretty simple. If you know more about what the work is, you can make a better estimate. If there are only one or two unknowns, you can be fairly confident about the rest. For this to work, I think I would need to be more honest and upfront, to say, “I need more information” or “I need some time to look into this” before giving an estimate. That can be frustrating, but I sometimes skip this step, or convince myself that I’m well informed enough.
I think it would really help me to look back over my estimations after the fact, to see just how far I was off. This would actually help me learn about what kinds of things I often estimate incorrectly, or at least give me a baseline of how much of a problem this is. Typically, when I give an estimate, there’s no system to close that loop, so I’ve been missing out on those learning experiences. Again, not something anyone else is going to do for me.
Before I wrap this up, I have to address stress. I think it’s a major factor here. Especially with what we’ve all been through. Some days, it’s all gotten to me. I’m not productive on those days. I wish I wasn’t expected to be productive on those days. Usually, when I’m estimating time, I’m envisioning myself as operating at 100%. Again, optimism. No one is operating at that level all the time, and if they are, they need to take a break. Being realistic about how much I should push myself is something that no one else will do for me.
Update, May 23, 2021: I just came across this article from Farnam Street about the necessity of slack time. I agree with what the article is saying, but in practice, this burden is still placed on the individual. An organization would need to recognize, at all levels, the need for slack, something near impossible to pull off. Still, a good idea to carry with me as I estimate time.
Was this helpful? Have a question? Let me know!