37 replies
5d9h
I've also done this a lot, as has everybody. My experience is that there are two problems.
One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed.
The other is that I really hate working like this because it seems all the creative effort of thinking about how to make something is put in the first part. And then, the rest is still most of the work, but it's the really boring part. It's much more fun (and therefore faster, and resulting in better work) to spread the creativity and the boredom out more equally.
The two are probably related, and it's not inconceivable that I have ADHD.
Whenever you talk about breaking down tasks, estimations etc, those usually are for multi-person teams, and/or projects that have some specific budget or something.
Of course if you are exploring or building your own projects and/or don't have any other accountability, you wouldn't start planning that.. unless you are really into planning in and of itself.
But as soon as you have a boss and the boss asks "how long? who does what? where do we start?" - you have to have some framework.
I also have a very high aversion to "conforming to the system", esp. when these systems seem arbitrary or are overly rigid .. but systems in general need to be simple and flexible. Productivity systems are there to help people.
I don't think the author intended for this to be like a detailed recipe.. but more like an example of how he approaches these things, which can hopefully help others have their own ideas.
Why?
Does it work? Is it productive? Is it better than not doing that?
On average: yes, yes, and yes.
For what it's worth, I think it's more like: On average: no, no, and yes.
It doesn't really "work" in the sense that the plan turns out to be an accurate and useful reflection of the work; that is not the case on average in my experience (sometimes it is, but not usually). And for the same reason, it isn't usually a productive exercise; it usually costs more time up front than it earns in productivity.
But despite those two things I think it still turns out to be better on average, in a team / "you have a boss" environment. Because productivity is not the only thing that matters, legibility is also important to organizations, and worth some productivity cost. Though this will chafe me until I'm in my grave, I still think it's true.
The plan being an accurate reflection of what then happens is not the point.
Having people assigned to tasks, a starting point, some initial steps to follow is something that increase delivery speed in the beginning a lot.
Edit: to some extent, legibility is productivity, as it means others are aware of what is going on and can interact/refer/etc.
It's a balance of time spent planning against the value of the plan. Immediate-term "planning" is definitely valuable, IMO. Thinking through how some immediate work can be split up so that multiple people can make progress simultaneously, without stepping on each other's toes, that is definitely valuable. Having some discussion about what the next steps might be after those immediate steps are complete, that's also pretty much always valuable. Spending a small amount of time thinking about the next next steps can be valuable. But past that, in my experience, people often put more time into planning detailed steps than ends up being valuable. It's not that it has zero value, it's that it has a pretty high cost that, in my opinion, usually outweighs that value.
Also, just to note that I think spending time thinking about a "north star" vision of what a project is trying to achieve is also pretty much always strongly positive ROI.
It's time spent coming up with a detailed plan a few steps out from the immediate term that I find dubious. I don't mind other people spending that time if they want to, but I don't like spending my time in those planning meetings; I'd rather be getting to work on the immediate term tasks.
I think making plans/planning needs training to be good at - which in turn reduces "overplanning". Knowing what to include, discuss in which forum, what task or deliverable granularity, etc. is useful doesn't come naturally to most.
Agreed.
But actually, I kind of feel like people who have had training to get good at planning, are not the most likely people to be good at avoiding "overplanning". I think it's the same kind of incentives as how dentists have a natural bias toward recommending dental work, or chiropractors toward recommending adjustments, or programmers toward recommending writing software, or anyone toward doing a bit more of whatever it is they are trained at and good at than a totally unbiased third party might really need or want.
Maybe there's also a bit of a "midwit meme" to this (in all of these cases): inexperienced: don't do it!, some experience (midwit): do it!, extremely experienced: don't do it ... except in these cases where you really should, and include just the right amount, and be very thoughtful about the forum and who to include in the discussion, and calibrate the right level of granularity for this specific project, and ...
I think that happens typically when the planning and the execution are very divorced (someone good at/selling using the techniques of planning). I'd say a good operational planer doesn't overplan.
I agree, but I guess the point I was trying to make is that I think everybody is susceptible to over-biasing toward thinking the thing they know how to do is super important, to the point that they sometimes over-do it, despite their best intentions.
I would say that "a good programmer doesn't write more software than is necessary", but despite my best intentions, I'm certain that I write more software than is necessary, because writing software is my hammer and lots of things look like nails to me.
I think it requires more than just being "good" at something to overcome this tendency. I'm sure the very best operational planners, like the very best software engineers, consistently strike the perfect balance, but I suspect most "good" planners, like most "good" (even "great") software engineers I know, still struggle with this tendency.
Suppose it doesn’t work, it’s not productive, and it’s worse than not doing it.
You still have a boss asking these questions. Any answer you provide constitutes a framework.
Well, one answer you can try is to push back on the concept of providing status updates. For many (but not most) high-trust individuals working on many (but I think not most) kinds of projects, that's totally fine. (Ideally it is an expectation set much earlier on than the point where a status update is being requested, though.)
Tangent: I can't recall where I first heard "plans are worthless, but planning is essential", but there's definitely some truth in it.
Certainly holds true for having a baby.
You can plan all you want and it is essential... however you'll quickly find out that most of your plans are in your newborns' hands.
Yes! Also Mike Tyson's famous "Everybody has a plan, until they get punched in the face."
For babies, everybody has a plan until they get pooped on / thrown up on.
Dwight Eisenhower, who also created The Matrix.
For clarification, "The Matrix" refers to the urgency vs importance decision matrix and not the movie: https://asana.com/resources/eisenhower-matrix
It's a framework to prioritize important tasks instead of falling into the agency trap, akin to prioritizing meaningful strategic tasks such as product development and tech debt instead of fighting fires.
Another perspective is that planning is a breadth-first traversal of the solution space, and coming up with a path to the solution. When reality hits and the path is often wrong, one can switch to other paths quickly since the graph was created ahead of time. It's writing the table of contents for a book before fleshing it out.
Without planning, a depth first traversal is a high risk endeavor in the likelihood that the that path is wrong but backtracking and creating the graph is comparatively expensive and susceptible to sunk cost fallacy. Depth-first traversal is writing the book a chapter at a time without a table of contents in mind.
I make lists and break tasks in to smaller tasks, however I rarely reference these lists. They basically end up in the void. The act of making the list gets my juices flowing and reminds me of the side effects / bigger picture of my current challenge.
Realizing this also helps me avoid yak shaving over list making tools, since I could care less about even saving the lists! I keep a folder of text files in any project I'm working to hold my lists, but tbh it's unnecessary to even save them.
Sometimes planning is more important than having a plan
I see this a lot in this thread (and have heard it a number of times before), and it sounds intuitively right to me, but could you give an example of when and why that is the case?
Writing an idea down just seems to reinforce it and makes you flesh it out. I think it engages your brain differently, but I’m no neuroscientist.
Even if this is right (and I definitely think there is a lot of truth to it!), planning is not the only kind of "writing down ideas to reinforce and flesh them out" activity. Is it the most valuable one? And is this the only and best way to reinforce and flesh out ideas, or are there other ways that might be even better, like creating prototypes or just actively fiddling around with different approaches and possibilities? In my view, it isn't that there is no value in pondering the detailed sequence of work it will require to accomplish something over the next three months, it's more that I think beyond a horizon of a few weeks, most of the other things I could be doing with that time usually ends up seeming more valuable, to me.
The plan not being perfect and prescient is part of the plan.
Next time you plan for same or similar activity, your future plan will be better.
The Project Managers even have a mantra: "fail to plan is plan to fail."
And Eisenhower's "plans are useless, planning is essential", of course. I know.
But for me it's very easy to overdo it. Give me interesting chunks of about a week or two, with a tight deadline, and I'll do my best work.
Remember, Linus wrote Git in two weeks. And there was no project manager in sight.
On the Linus point, I'd bet there were countless months where he was bringing ideas together in his head and planning how he'd do it before actually finding the time to sit down and write it.
It would be interesting to know whether he had devised some kind of project plan ahead of time. But I suspect not. I'm sure he had been thinking about the technical details of what he wanted to build - which yep, we all like to do that! - but I doubt he bothered to break down a set of approximately-ordered 1- to 3-day work units, which is what many of us struggle to be good at.
I do the GTD thing of only thinking about the _next_ action, not trying to think of every action.
Seriously asking : how? I can't cheat my brain into not automatically seeing the next steps after that and the cascading relation between the all. Within a second or less.
A related if not the same thing I've been trying to do, especially with some DIY type work, is that it doesn't matter, deal with that later, just get this done thing for now.
I.e. not somehow trick yourself into not thinking about it, but just think who knows if/when I'll actually get around to that, for now just do this. Don't worry about optimal order.
If the skirting doesn't look as great as it could because I fixed and painted the doorframe first, only painting the wall and rest of skirting later, meh who cares, if it turns out to be that noticeable maybe I'll get around to giving it all another coat; in the meantime at least I got it done, not stuck in 'analysis paralysis'.
I'm a person who hates lists and plans for personal tasks. But, am learning to love them. Because as I often realize, things get missed in the myriad of things to remember.
The plan to me is just a way of reminding my future self what I thought of as ideal output in the past. Instead of infinitely changing my plans and chasing fireflies
That's slightly different, IMO. Writing down things that need to get done as you think of them is not the same as writing down a plan.
I also can't get myself to do it seriously for my own tasks, but when I had to do it for a jr colleague I found out... yeah, breaking it down its hard, as hard as coding - then you get most of the hard work already done, and coding the solution becomes trivial. Chances of false starts go from 80% to 20%.
(A few times there is prototyping involved but I won't share that with non-devs, since they don't seem to get it.)
I am somewhat like that myself. I do formulate a plan and break down tasks in advance, but I give myself an absolute right to change and modify it at will whenever new ideas come to light or just because I'm feeling like it.
This is an accurate and insightful way of looking at work. It touches on something that I've been considering a lot lately: I love programming, but I hate doing it in a work environment. The fun thing about programming is that it is a flexible, flowing, and creative endeavor. You make things up as you go; it is an organic experience. In a work environment, this organic nature is removed mainly because there is a need for oversight and accountability.
Holy... It still amuses me how much HN comments brings the reality to these kind of articles.
Sometimes it's even worst. As we add more tasks during execution, at the end, these tasks get twisted with the ones you created while planning. Then we end up with a messy list of undone tasks that aren't really required anymore (because they were created without having the full context, that only happens during the execution).