Hacker News Reader

I think I have to disagree on what you have say on time-box.

> "What happens if we don't discover what we wna to in that amount of time"

Then we know that the answer could not be discovered in that amount of time we had estimated and we adjust our expectation on the effort to do the research on this task. As a manager, thats one of the key information that I would want to know.

It’s also absolutely vital as a manager to put in place a system of psychological safety before making these kinds of asks. If someone feels like they will be held accountable for not accomplishing the task in the allotted time, then everyone is hurt by the exercise, and morale and trust can plummet - to say nothing of the exploration itself being compromised by a panicked context. But done in the right environment, this can be an amazing technique for exploring a design space.

Additionally, as long as documentation is made throughout, this can still be valuable.

* Someone else can continue research, where they left off.

* The research they did, can be discussed amongst the team, possibly by a more senior teammate.

* It may reveal that further research isn’t necessary, and this effort should be shelved until a later date.

That person couldn't discover it. Maybe another engineer could have discovered it in 5 minutes because it's what they were already working on (and the one researching wasn't aware, or maybe it was down a rabbit hole that looked unrelated).

I guess it depends on how high priority it is. But everything is high priority to management.

I'm not a consistent machine though. I may be having an off day. If I don't pull it off in 20 minutes I'm not sure if it's just me, or me that day, etc.

> there's no guarantee that you'll get what you want in that amount of time, and then what?

I am absolutely _shocked_ you've never received an answer to this.

There's no guarantee you'll get what you want in _any_ amount of time. You absolutely need to timebox, everything & anything, to make sure projects aren't going off the rails and ending up in the trash. This applies even to personal/solo work too. You can keep working on anything forever, it's much better to force a stopping point, get feedback (or ship it) and decide if it's worth continuing or not.

The mechanism at work here is forcing people to prioritize. If you're very good at prioritizing then a timebox maybe doesn't make sense, but even then, it may be hard to resist continuing to work on something to a higher degree of quality than is needed without a timebox.

> What happens if we don't discover what we want to in that amount of time?

We reevaluate with more information than we have right now.

This pattern of task is helpful for things where the unknowns are substantially greater than the knowns. The idea is to incrementally shift the balance until the knowns are _enough_ to actually make an informed guess instead of just a wild guess.

There's a bug in the legacy codebase. The replacement is nearly finished and slated for launch in two months. How do we handle that bug?

We could ignore it, we could just tell someone "go fix it, whatever it takes". Neither is a great option.

So: "Go investigate this bug, don't spend more than an hour, and let me know how far you get."

By the time you're done, we'll have a _better_ idea what the shape of the problem is.

Maybe you come back and say "yeah I found the problem's in this area, I need to sit down with someone that understands the business logic better to untangle this and then we can tweak and fix it"--great, we'll get you the appropriate resources and try and follow through with a fix. We'll figure on something like an afternoon of interruption for you.

Maybe you just come back saying "it's in this part of the code and it's pretty organized, just couldn't quite track it down yet" and we can greenlight more time based on some level of confidence that it won't be an enormous task. (Or maybe not, depending on the actual scope and severity of the bug.) We'll figure on a day or two of interruption to get it over the line.

Maybe you come back saying "it's somewhere in this eldritch spaghetti, and when I stared into it the abyss starting back at me sent chills up my spine and the pictures on my walls wept blood, please don't send me back there" and it's clear it's not worth pursuing any further and we drop it.

> Maybe you come back saying "it's somewhere in this eldritch spaghetti, and when I stared into it the abyss starting back at me sent chills up my spine and the pictures on my walls wept blood, please don't send me back there" and it's clear it's not worth pursuing any further and we drop it.

I wish I could give my status updates like this.

“Quick” means “done in a short time”; the sentence you call out is still using time to describe work.

> When anyone measures in time, there's no guarantee that you'll get what you want in that amount of time, and then what? Well, we add more time!

I believe you that this has been your experience, but it’s not universal. The problem is treating “what you want” as the end in itself, which is why the article also mentions “tell people what you need it for”: “our biggest client needs to know before they renew their contract” is worth more money, and thus more employee-hours, than “I was just curious”. At the leadership level, you are expected to realize that you can’t chase every benefit, and strategically focus on those with the best cost ratio.

"Each person looking at this is going to achieve a slightly different amount in 20 mins. Even if we ignore that, there's no guarantee that the manager making the request is going to get what they need from 20 minutes of your effort."

It is a managers job to delegate tasks appropriately. That isn't just assigning bodies to jobs. But assigning the right job to the right people with the right skills.

Time boxing is just a method to do cost/benefit. So sure, time is a bad proxy for many things, but it's not a bad proxy for cost in a world where folks are compensated for their time (generally speaking).

The manager was very clear and specific that what they needed was 20 minutes spent on the issue. Don’t second guess them. If they wanted something else, they’d ask for that instead.

I actually love when I'm given a time limit for a task. It enables me to engage my prioritization skills more effectively.