Themed days, Timeboxing and why you should use them
jamalx31.com
jamalx31.com
Timeboxing is an alternative method to goal-setting. The classic case is diets: instead of saying "I will lose 10kg in a month", timeboxing says "I will eat healthier and take some exercise every day for 2 weeks and see what happens". The difference is to do something different for a set period of time, and then see what the result was, rather than set a goal and a deadline.
For those of us immersed in Lean Startup thinking, where goal-setting doesn't really work any more as a motivation method (who cares if I fail in my goal, that I set myself 2 weeks ago, the important thing is what have I learned in that failure?). Time-boxing is a great alternative because it doesn't judge, it all about learning what happens if we change behaviour.
Timeboxing as setting goals and "exclusion zones" misses the point of it. If you say that you're going to "timebox" writing those two missing features today, but don't manage to complete them, then what happens? Do you extend to tomorrow? Then you're not really timeboxing, you're just saying "I'm not answering any calls until I've finished these features". Which is a totally different thing.
Properly timeboxing this would be "I'm going to spend today working on those features". I don't make any commitment to finish them. I don't know if I can finish them in a day. There's no judgement if I don't - I successfully spent a day working on them, and that was the requirement. After that one day I will know more and may be able to make a judgement or commitment about completion. Or not. I'll know after I spent the day working on them, not before.
> Scrum uses timeboxing for all of the Scrum events and as a tool for concretely defining open-ended or ambiguous tasks.
I don't doubt that's true, but it's not how things are supposed to work in scrum: https://www.scrum.org/resources/commitment-vs-forecast
The answer is it doesn't matter. The problem here is that people are doing Y not X, and discussing semantics is only useful as an appeal to authority (which to be fair can be pretty darn useful sometimes).
It's the CIA Simple Sabotage Field Manual applied to project management.
Any work accomplished is entirely accidental, and will be remedied during the next sprint planning meeting.
Edit: I don't mean to say scrum proponents are wrong, but if so many people get it wrong there seem to be a fundamental problem with scrum.
It's the same problem with all methodologies - if the management is in charge of the process and it doesn't like some aspect of the process it will ignore that aspect.
This isn't solvable by tweaking the methodology.
Rather, (at least to me) it's "don't extend the deadline, instead reduce the scope". You slice your deliverables small enough so that if you miss the deadline, it's not an all-or-nothing situation. You can always deliver a usable subset of what you planned/forecast.
Take your example, "writing those two missing features today". You might just end up delivering one of those features if your forecast turns out to be inaccurate. It's more effective if the timebox is larger and the tasks are smaller.
This means you'll hear something like: "I'll timebox improving performance of this feature to a single day; it would be nice if we can get a quick win, but it's not really blocking if we do not.".
Maybe within 10 minutes of profiling you see that one line of code that is copying large data structures around unnecessarily and a quick refactor speeds the feature up 5x. Or maybe you spent all day on it and haven't found anything that's quick to fix: You fix up a couple of small inefficiencies and speed up the feature by 2%. You write down your findings and at least now the team will know that optimising that feature will be a larger undertaking and should be estimated as such.
I have also done it for very edge case bugs where no one is really sure what the cause is and fixing it is not high priority. You might get lucky and work it/fix it quickly; but if you don't, then at least you're not spending a week when the remaining 4 days could've been spent on something of higher priority.
That doesn't match any situation I've found myself in as a technology professional (or as a student before that). It doesn't look like most other job roles I've witnessed either. Which leaves me wondering why I see these systems pop up again and again? They must work for somebody, but from my (limited) perspective they don't seem a good fit for most people.
Factually, this is correct. In practice, it often is better to play along with the fantasy that the deadline is real.
I once got half-fired from a job because the deadlines were not, in reality, hard. All kinds of things went wrong in the project - from our team's side, from the (internal) customer's side, and from the company's side (outside of both our control). The project was very late. Sometimes I was fairly open about the deadlines not being hard. We all knew that even if I got the work done by the time they wanted it, no one was ready to consume our output for over a week after our releasing it - at various stages in the project - so we were "ahead" by many weeks.
By the end of the project, it was clear my manager didn't want me on the team. I got a terrible review that year where I was accused of causing delays. I challenged that notion, and we both agreed that had I done everything by the claimed deadlines, there would not have been any observable difference. The product would not have come out any quicker. Our delays were miniscule compared to the problems on the customer's side.
They still refused to change the verbiage on my review. Internally, the department does keep arbitrary metrics, and they want the numbers to be good even if there is no actual observable benefit.
Not all jobs are like that, but many are.
The one lesson I learned from that job and the one that followed: You can have similar jobs with the same pay, but the further you are from the customer, the more flexible everyone around you becomes. In the crappy job, we were quite far down in the manufacturing flow, and had little power to negotiate timelines. In the second job (same company), we were higher up in the flow, and more of this pressure was on people downstream from us.
Sometimes I get deadlines, and sometimes it's more that the team expressed confidence we could do certain tasks in a certain amount of time each, and then someone went and made a GANTT chart planning our whole next quarter, even though everyone knows it'll get changed up in a couple weeks, because the business needs to make related plans. Then the schedule is treated a plan and not a prediction, and people get frowny when you don't hit target dates because they're also being held to not-really-plans they based on your schedule.
There are plenty of legitimate (and illegitimate) reasons the business would want to hold you to a date pulled out of thin air, but for this discussion the important point is that the entire system is predicated against rogue individuals making unilateral plans to prioritize or delay work for opaque, arbitrary reasons without the involvement of the stakeholders who presumably were the impetus for those tasks. I.e., "theme days", 1-3-5, etc. don't seem workable in the environments I've worked in.
The fact that priorities and schedules are decided with input and consensus from lots of people who aren't me is the crux of my point. The article is about personal task management. It, like any number of similar articles I've read, offers a system that presumes I can pick and choose what I work on today based on metrics of my own choosing, instead of being bound by a decision made with other people. The article expects I'm in an environment where nobody cares if I push tasks back 2, 3, 4+ days for reasons that have nothing to do with the project or team or business, but because of arbitrary restrictions on when I allow myself to do certain things. Unless I can make a business case that "theme days" or similar systems benefit the business, the business just sees needless, disruptive delays it didn't authorize.
Even if all your work is same-day, look at whether it can be sorted in some way.
If it can’t be sorted, box in some time to work on how to stop the firefighting. :)
Could we not do this, please? It's basically shaming people for not being able to reach the super-human level of working 15-hour days AND get a good nights sleep AND have hobbies AND be a family man. This fetishization of "efficiency" is really getting to me as of late.
Also, didn't Elon suffer from mental health problems, needing medication to even be able to sleep?
You speak of shaming people only to go and narc on sleep issues. Great person you are.
It's still work and very important and impactful work, but it's not that physically or mentally exhausting. You can do 15 hours of this kind of work. But you can't fix software bugs for 15 hours every day.
But I'm now about 8 weeks into a massive code change in a 600k LOC C++ codebase. Roughly 3000 files that need to be manually inspected to change every instance of a forced compiler error report so that the code at that point uses a replacement datatype, or doesn't. The task is not automatable, requires a fairly deep understanding of both the problem domain and the specifics of each line, and isn't testable until every single file has been modified.
Granted, situations like this don't come up particularly often (thankfully). But things not so distant to this come up more often than one might guess, especially in open source contexts where avoidance of technical debt is allowed to be a major development priority.
When faced with tasks like this, there's no time management process that can help. You just have to start, and then keep going until its done. Every minute you get distracted or for any reason switch to another task just delays the intended eventual merge back into the main branch.
I don't believe that every random set of 40 hours in his 100 would be something that he would be happy to pay someone else to do.
Successful people lie to themselves like this all the time.
We have to be skeptical about "these methods" which, to me, seem more like PR myth they are trapped in.
Like Buffett saying that:
- he never set appointments (he works in isolation? he never goes to the doctor? He now flies with private jets? Everything has an impact on everything?)
- you never "leave large sums to your children" (My wife who works in asset management for (very) high profiles always rolls her eyes when earing that, replying "of course, to optimize the taxes you always create structures of foundations, so that they do not technical "get" the money but indirectly own the structure managing it.).
My guess as to how Elon Musk can run the two companies at once is that it's not difficult, and therefore, he doesn't do very much. But if anyone has more information on what, precisely, these jobs consist of. I'd love to hear about it.
The funny part about "working 100 hours a week and still having time to tweet" just sounds like a living death to me.
One thing I have learned about compulsive/addictive behaviour on that scale is that, at some point, the amount of time spent doing something is little more than a reflection of one's inability to derive enjoyment or satisfaction from it any more.
If this were just one sad man's personal problem then I might say "more power to you", but since our entire society is oriented around maintaining the lives of these billionaires, I do wonder whether the entire planet is sacrificing itself for the enjoyment of people who are constitutionally unable to experience enjoyment. And whether that is a planetary-scale human dysfunction.
If you're in control of your own day 100% then either you make a schedule or it's just a soup of everything mashed into one which I guarantee you will drive you slowly mad. I totally understand why people schedule their days like this, it removes the anxiety as your own boss of saying "what should I be doing right now".