Hacker News Reader

Comment by d--b | Hacker News Reader

I very much disagree with the article.

Long term plans do not work very well for sure. But they're not _meant_ to. Long term planning is meant to give people an idea of what's coming after.

This is important because what's coming after may change the implementation of what you're doing now. Some people in the team may say: "hey if we did 3 before 1, then we'd have 2 for free".

Estimating the time it will take to do things is also important cause you may think that you know what's coming after, but if you don't know how much time it may take (apply a 0.5-2 multiplier range), you may actually never have time to do it.

Keep making plans. Keep selling them to stakeholders, and keep telling them that it's just a rough plan and that details will be very different.

In any case, it'll cost you more pain to fight your CEO and tell them that you don't want to make a 1-year plan, than to actually making a 1-year plan...

View on HN

> Long term planning is meant to give people an idea of what's coming after.

This is precisely the problem though. Your statement is contradictory because if (as you say) long term plans don't in fact work, that "having an idea of what's coming" is complete fiction.

And trust me, confidently believing in fiction is much much worse for effective planning than proactively preparing your product for uncertain outcomes.

If I am 100% sure our product will be doing X and not Y in 18 months, I'm going to build that product with a strong bias toward X and zero consideration for Y. If I don't know what's coming, I'm going to build it with weak contracts toward both and a heavy emphasis on being refactor-/pivot-friendly. Which of those approaches will serve my company better when we unexpectedly end up switching to Y after a year?

Well that's a different organization, I prefer moving towards something that's likely to happen rather than stepping in the unknown.

I am pretty sure there are teams / projects for which one methodology is better than the other.

Stating that there are no situations in which it is beneficial for some team to make long term plans is simply too strong a statement.

That's fair. This isn't a binary, and the ideal is likely somewhere in the middle.

Still, I do think there's quite a large portion of detail-planning that can be radically different dependent on the high-level expectations, even where the range of high-level outcomes is small.

i.e. (random off-the-top-of-my-head example): I'm building a piece of software offering some kind of service to end-users. We're considering staff-curated -vs- user-generated & curated content & we opt for the user-gen approach as we don't think the first option will scale. As we get into the market, we quickly realise the demand for content is high, we're in a good position to adjust our pricing upward, but engagement in content-provision & curation activities is low. So we decide to pivot to staff-curation.

The above pivot doesn't involve a radical product change (the offering remains similar overall), but does involve radical technical changes under the hood. A long-term-planning oriented company may have invested heavily in building robust (expensive & complex) community features that may be thrown out later. A short-term-planning oriented company would more likely hedge their technical decisions - leverage some 3rd-parties temporarily during user-testing, maybe test earlier, be more sensitive to priority changes.

I think parent’s point still stands: expecting that X and not Y will come in 18 months might be worse than not expecting anything, if X actually comes in 36 months.

Even within the same organization, it’s such a gamble when:

- X might never come if the project takes too long or gets deprioritized. 18 months is a long time, perhaps half of an engineer’s average time in the company. X’s sponsor going away could mean the project stays in limbo for the rest of its life

- X might become Z when you realize midway that X wasn’t a good idea in the first place, or the assumptions behind X changed enough for the project to not make sense anymore. The org might not care for the cost to readjust now that X is gone, but you’re still worse off than if you weren’t waiting for X.

The refactor question is not just about the next 18 months. How likely the project will be in active development in 5 or 15 years?

That’s something long term planning can give you a reasonable idea about. If your working on Madden 24 then the business model is about minor changes every year, while most games are one and done.

>And trust me, confidently believing in fiction is much much worse for effective planning

Absolutely TRUE - and this becomes a political problem in some organizations, depending on whether you're around people who can handle hearing the truth (whether they just don't want to hear bad news, or whether they don't understand complex webs of interdependencies that can cause time estimates to be wrong).

I feel like you are talking about something more like roadmap.

Of course long term plans/road maps have their place when everybody agrees on that it is an "idea of what's coming"

However most long term plans I have encountered at my last two companies have absolutely been treated as commitments to detailed plans two years ahead of time, before we have no idea what we really want.

This is causing project members constantly stressing/hurting about not meeting plan still years after everyone knows that the plan does reflect real life anymore.

I think there's a lot of confusion in this area. A long term plan tends to become too rigid, making us unable to respond to change. If we are dealing with a complex problem where the outcome is hard to predict this is a death sentence to the project.

On the other hand having only short term "agile" plans can on the extreme end turn us reactive and without any focus. If we are dealing with a "big" problem this is a death sentence for the project.

If the project is big complex and hard to predict we have to be able to be agile on both the short term and the long term, and sometimes on the really really long term, all at the same time. Oh, and also for the group and the whole organisation at the same time.

No, in my team we've been doing 1y actual plans for the past twelve years, with time estimates and project breakdowns and who's going to do what and when.

It just works very well for us.

What does work well mean? Compared to what, and is that a fair comparison?

Long term plans "work", but by sticking to them you might be giving up opportunities to do something more profitable. They can also "work" in the sense that the culture encourages abandoning them if something more profitable comes up, but then you've spent time planning for something that doesn't happen.

How often do you decide to abandon your long-term plan for something more profitable? And how often do you decide to pass up on something more profitable to stick to the plan?

>> However most long term plans I have encountered at my last two companies have absolutely been treated as commitments to detailed plans two years ahead of time, before we have no idea what we really want.

That is an issue with your company, not plans themselves. I'd agree with avoiding long term plans in a disfunctional organisation.

> something more like roadmap

Yes and: Strategy & Tactics

Beyond the inability to reason about stuff, not even asking Who What Why When Where and How, the inability to divide & conquer, the hostility to verifying assumptions (eg will any one buy our stuff?), etc. etc.

I've met very few people, any where, in business or politics, that can war game scenarios. Much less reason about tactical decisions. Or even know the difference between strategy and tactics.

My hunch, totally unvalidated, is a strategic thinker isn't especially smart or talented, so much as everyone else is fantastically, tragically inept.

I always marveled about the rise of Microsoft. Sure, they did some good stuff, made some good moves. (And then later was simply criminal.) But OMG their competition was terrible. Ashton-Tate, WordPerfect, Novell, Lotus, and probably a zillion others. So many defeated themselves. Microsoft was like the Bolsheviks; they found power lying on the street, after every one else imploded.

I feel this is a problem in our entire mindset. People so often get confused with the difference between a plan and a goal. One is the what and one is the how. What most people call plans are really just goals. Plans require sufficient data to make a how. Or they need a whole set of contingency plans that would be the plan if and when sufficient data becomes available. This is why "long term plans" are so vague in general because they are just a goal. As time progresses, the long term becomes the short and the data becomes available to turn goals into plans that can be executed.

Agreed. The alternative to long-term planning is often a feeling of aimlessness, chasing the next incremental improvement with no idea of what, if anything, will be achieved. Useful fictions can still be useful.

Reply on news.ycombinator.com