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.
I do believe that "do something for a set period and see what happens" is the wrong way to look at timeboxing.
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.
I always see timeboxing as ensuring that an exploratory task does not blow up in terms of time spent on it.
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.
If Scrum is X, but everyone saying "Scrum" is referring to Y, is Scrum X or Y?
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).
Scrum/Agile are useful tools to get buy in and a bit of restructuring done, but I feel as soon as you start doing real work you will just have to figure out what flavor works for your team, and what modifications need to be made to the process to make that happen.
I always found these task management systems unrelatable because they assume you have a bunch of tasks you can schedule and order at your discretion, that you can freely ignore most tasks for days at a time, that you can actually predict your priorities up to a week in advance, and that if your workload and your timeboxing conflict then your workload will be the one that budges.
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.
This is probably due to differences in the schedules of "makers" vs. "managers" . If you're a one-man operation (which I believe the author is), this approach is easy. If you're an individual contributor within a team, it's a bit harder. If you're a team lead or a manager, it's even harder. I'm an engineering manager and if I try to timebox a certain type of task into a specific day of the week, my teams are likely to get blocked until that day arrives.
Really? I find this rather surprising, because I would say about 80% of all of the work i’ve ever done didn’t have a hard deadline in the near future. People sure liked to try to invent emergencies, but they weren’t actually urgent.
The environments I work in presume or dictate my task ordering and priorities according to the needs of my team and the broader business, with no concern for the restrictions imposed my my personal task management syntem. My boss/team expect me to work on The Things We Agreed on, in The Order We Agreed On, and I'm expected to start as soon as I wrap up my WIP from our last round of planning.
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.
Well usually those kinds of things would be not just how you worked but discussions had with the team about how work got done. More or less all of the environments I have been in how work was done was an open discussion with the team and management, not just something dictated to us.
I suppose I'm not speaking clearly here. Generally yes, my tasks come from a combination of my team pushing priorities up from below (ideas for improvements, paying down tech debt) and the business pushing requirements down from above (strategic/financial objectives, promises to customers). Prioritization and assignment is usually a group discussion with everyone relevant.
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.
> I find this rather surprising, because I would say about 80% of all of the work i’ve ever done didn’t have a hard deadline in the near future.
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.
Oh definitely, I've never met a deadline that didn't inevitably evaporate, but for management they're still very real up until that moment. It's comical, but also you come to realise that the deadline isn't for you anyway. It's for everyone around you so they can plan their tasks. When the deadline is once again pushed due to reasons outside of your control, just rest assured that everyone saw it coming and the blame probably isn't on you.
> Musk is an interesting example of someone who manages his time so well that he can work 100 hours a week and still manage to take time out for his hobbies, family, and even Twitter!
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?
I don't think Elon Musk is working that hard. He is a CEO. His work includes having a lunch with a business partner in a fancy restaurant, or listening to his direct reports while scrolling Twitter.
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.
I don't know how well this works for the type of scenarios referenced in TFA.
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.
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.).
Basic math. 168 hours in a week. -100 for work, -49 for sleeping 7 hours. That leaves 2.7h per day. Probably lose at least an hour of that for basic human body related activities and general inefficiency. So 1.7h for being a family man and hobbies per day? Plus time spent driving to and from said hobbies? Plus the hundred small things we don’t track? Yeah it’s BS
An honest question: how do you cope with the feeling where you have much more coding to do and you haven't finished what you were working on, and now it's a non-coding day but you are constantly thinking about the code that you'd better off finish before doing anything else?
Articles like this are so ridiculously tone-deaf. As a working stiff, I can't reasonably shove all communications into one day and spend another writing code. I suspect the overwhelming majority of readers of this site are in a similar position.
I can’t help but think this is a result of capitalism gone awry, the need to never let any time be wasted, to the point of scheduling time with ones kids. And I’m not far left of center, but yeesh. If you enjoy living life this way, more power to you. When I was younger I might have thought this sounded great. Now that I’m touching 40, it sounds like a self-made prison.
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.
No, it's just the result of someone being nearly 100% in control of their own schedule. If you work at a traditional 9-5 job your company effectively schedules the bulk of your day... you go to work at x, leave at x, take lunch around x, the company will direct you towards the work it requires.
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".
I schedule time once a week for date night with my wife. It allows me to focus on my time with her, instead of following random whims, eg, “I need to finish that feature, I’m gonna spend my weekend doing that.”