I think it's very easy to make folksy intuitive sounding rules from almost any angle here, and none of them are really definitive because the world is infinitely complex. Move fast, but not too fast. Think, but not for too long. Do, but not too early or too late. I don't think there is a one size fits all answer for any person or organisation.
I think the correct fundamental framework, which is compatible with all sides of the argument, is that you must be mindful of your learning rate. Some approaches are depth first - perhaps that depth is satisfactory to learn what you need to solve real problems. But perhaps what you actually need is breadth. There is no way to say which is right - you literally have to just stress it out, it's not fun. Some problems only yield information when you have skin in the game - there's no way to reason out the right approach, you need to push at real boundaries and see what happens. Some of the boundaries, all of the boundaries, keep pushing, take a pause... again, you can't know for sure what's right. All you can do is constantly ask yourself - am I learning? Am I generating hypotheses, testing them, proving at least some? The framework is different for everyone, and it's _work_.
“In the words of the ancients, one should make his decisions within the space of seven breaths. Lord Takandobu said, “If discrimination is long, it will spoil.” Lord Naoshige said, “When matters are done leisurely, seven out of ten will turn out badly. A warrior is a person who does things quickly.
When your mind is going hither and thither, discrimination will never be brought to a conclusion. With an intense, fresh and undelaying spirit, one will make his judgments within the space of seven breaths. It is a matter of being determined and having the spirit to break right through to the other side.”
Works well for a warrior (where 7 breaths is a long time) - but not so much most business leaders/managers. After witnessing it so many times, I'm guessing the standard playbook they teach at business schools is "Don't bother taking time to understand a situation - just make a decision unnecessarily quickly and over-confidently, and then stick to your guns no matter what".
So much wasted effort results... but, hey, at least I got paid for it. And now I make sure I don't work anywhere where they run this playbook anymore!
it seems to come from the same place of wanting a simple rule to pattern match against some problem space so we don't have to think too hard about it every time.
also ... the author cites sam altman as evidence that his thinking is on the right track, but can you really argue against a statement like "Almost everyone I’ve ever met would be well-served by spending more time thinking about what to focus on"? that's about as close to a one size fits all statement as "almost everyone who succeeds thinks"
i sometimes wonder if this comes from a place of fear. Maybe we're scared of really listening to customers / users / colleagues / stakeholders and so we invent these rules to hold ourselves accountable for what's probably pretty obvious from the outside
I'm a consultant, been on thousands of calls with customers, partners, colleagues ... after all this time it is still truly astounding how many people wait to talk instead of listen, and cannot or will not exhibit professional empathy and curiosity.
By nature we choose the path of least resistance. Because it’s easier if possible. It costs less.
We are also always trying to navigate the world constantly, and talking is a way to test our world view against other people. This is why we talk.
So; Talking (articulating the world view) and hopefully getting a affirming response to that is less expensive to our system than throwing away that paradigm and learning a new one.
I agree with the first part of what you said, but I don't think plain listening is a "new paradigm", albeit I'll grant that it's probably a skill that can be improved.
to circle back to the original topic of understanding the problem, a big part of that is being observant and attentive to the needs of users. In that context and using your framing of this in terms of cost and resistance, I agree that simply talking and stating opinions is far easier than shutting up, talking to users, and gathering real information about what they actually want
it really sucks and I feel it's gotten worse with zoom. Sitting in retro meetings in the past year I've definitely noticed an uptick in people just talking and not actually responding to what someone just said. very frustrating.
The wisdom of folksy statements is usually a distillation of a morality tale of some sort. Reasoning about them in the abstract is missing the point. It isn't a pure logic kind of exercise.
Anyway, discussing the wisdom rally cries, 15 years later... Most business wisdom is temporal. What applies to a >10 person startup hoping to raise $4m by the end of 2006 may not be the applicable wisdom today.
I don't think this is advising you to spend all your time understanding the problem. Clearly, you can't ever have perfect information, and you can waste your time in analysis paralysis.
I read this post as saying that, given how product development is path-dependent, most people should do a lot more up-front discovery work than they are today.
What I mean is, it's empirically very rare for people to just throw away a bad idea: they're more likely to modify it, pile more features on to it, or just delude themselves into thinking it will work eventually. But, usually it doesn't.
We can say "be willing to throw it all away and start over when you learn new information", but in practice people don't do this. So, it might be more effective for most people to do, say, 50% more up-front work than they're already doing to de-risk their ideas before committing anything to them. It's clearly not a guarantee of success, just a way to improve your chances and save your own time.
To me, the secret is being okay with failure, learning from it, than trying again.
I've heard this called the Feynman technique before. Pretend as if you know what you are doing and what to do, than start doing it as if you knew how, and each time you fail or realize you don't know how to proceed, stop, go learn only as much as you need too unblock your next step, rinse and repeat.
It's a really good way to eventually learn and succeed, while wasting as little time as possible.
The issue is that, when it comes to software development, where you need to build upon what you've done before to keep moving forward, the risk is that all your prior steps weren't considering your next ones, and at the time you built them you didn't really look further, you were focused on figuring out only the next move pretending you knew it all.
So in a startup setting, it kind of means that if you follow this technique, you'll quickly learn and figure out what and how to do things, but you'll also fail a lot, and those failures will pile up, and all you built during that process might not end up being usable in the end, as it could be a monster of tech dept, limitations and bad decisions.
That's where a lot of startup have a "big rewrite" phase normally.
This still works if you are okay with having that big rewrite/refactor phase, and as long as your monster was still good enough to carve you a big customer base or investor interest, that'll be patient enough to wait for your rewrite.
I'm not sure how to summarize this, but there are some problems that each step you take you've now advanced closer to the solution, so it's fine to not think holistically about it all, but focus one thing at a time. While there are other problems where that only take you so far, and at some point you have to think holistically, do I need to do anything about this foundation in planning of what I'll later build upon it? That kind of thing.
But I think often what happens is people are too afraid to fail, and they start thinking holistically, except they actually are not expert enough to be doing so. So they start thinking all hypothetical, imagining the problems that will come, and that all ends up a waste of time.
If they'd tried, tried and tried some more, then they'd actually have learned a lot, and now would possibly be on a place to actually think holistically.
I heard a pretty good saying on that:
"The difference between the master and the beginner, is that the master has failed more time than the beginner has tried".
I think the point is that people focus too much on the tech solution and not enough on the system into which the tech solution will be introduced.
There's this idea of "problem holder" that Walt Beleyer at Sandia National Laboratory talks about. Holding the problem and deeply understanding is sometimes neglected in the rush and joy of building. Fwiw, I wrote a post about that here:
I've found the multiple contradictory sayings ("don't force it", "where force doesn't work, more force will", "doing nothing is better than doing the wrong thing" and its reverse) useful as a way of characterizing the problem space. ie in positions of uncertainty, figuring out which proverb applies is a great framework for approximation.
Agree, or I would just say “just never give up trying” because they might be working on something stupid and they should sometimes pivot/give up this one but not all together.
That’s really the only universal advice imo.
I don't understand how people take "move fast" and interpret it as "move fast with no understanding". The whole point is to "move fast towards understanding". If understanding isn't the goal here, that leaves all the activity as little more than stirring your mixture to accelerate Brownian motion. It seriously undermines the mystique about intelligence being in any way involved with the tech industry.
When your KPIs are "velocity" and your measurements of that KPI are duly myopic, then all your local incentives are best served by the fastest random walk to nowhere in-particular.
I've observed this most pathologically at organizations running the "hyper growth" playbook.
Self-selection bias. Clearly those who love the saying are predisposed to move fast. But they move so fast they haven't had a chance to understand the saying!
> Clearly those who love the saying are predisposed to move fast.
I don't think that's clear at all. Many "loved" sayings are "loved" because they help spur one into behaviours one otherwise would not partake. If you think about it, sayings about predisposed behaviour can often seem unremarkable. It's like corporate values: the published corporate values are ultimately as much aspirational as actual, because the purely "actual" values are assumed. (For the same reason, if you ask someone what is most important to them, no one says "breathing" or "air".)
> But they move so fast they haven't had a chance to understand the saying!
Iterating on NOOP can be done a lot faster, and at much less expense, than iterating on something; I'd like to think the eventual steady state of such folks will be to do absolutely nothing very, very quickly. ;-)
Hey, human reasoning can take you to some dark places, so I don't begrudge people where they end up. I'm just confused by how... broad? the phenomenon is. I'd expect some kind of Darwinian forces/selection bias that would eventually relegate such thinking to a quite corner of the universe.
I get the sentiment, but 9/10 you won't actually understand the problem until you actually work on it. Work leads to understanding but understanding usually doesn't lead to work.
The counter to this are stories like Stripe. Collison has famously said they never would have started the company if they actually knew how hard the problem was when the started. They identified the problem and committed to solving it. But jumping in blind increased their chance of actually making something unique instead of just another credit card gateway.
Not sure it counters the story, it just sounds like selection bias -- for every Collison that won big, there must be a hundred shadow Collisons who jumped in blind but failed. I totally agree with your first point, though.
re: Stripe, it feels like what was more important was that they understood that what they were working on truly _was_ a problem -- I don't think the point of the article is to say that you need to completely understand every nuance of the problem you're solving before you can move fast, but that there's a base level of understanding you need to have in order to be effective (which is probably less common in founders/startups than most people think) ¯\_(ツ)_/¯
Very true. And I can relate to that on a hardware startup I’m working on giving people bathroom privacy.
I went in thinking “oh I’ll just pay some people to fix all the technical things and I’ll do what I’m good at: sales.”
Money ran out and so far I coded a website from scratch, learned web design, written software for the unit and just finished the first circuit boards. And the further I get the deeper the rabbit hole goes. It’s probably gonna take 20 years to get where I wanted to be in 5 and that’s fine.
Usually the people asking for the solution don't even really understand the problem. How often are your probing questions at a requirements-gathering meeting met with "we'll have to get back to you on that"
As a programmer-turned-founder, this is something I have to remind myself all the time... it's often very hard to resist the urge to just keep coding and launching and throwing things at the wall until something sticks, because that's what I'm "good at" and it creates an illusion of productivity and "moving fast".
It seems like some people are commenting that the advice in the article is common sense, but I think when your mindset is to move fast, it can be easy to delude yourself into thinking you understand a problem when you're really just married to an idea but too scared to go out and discover whether it's actually solving something real or not.
My team and I, 4 engineers, we focused for about 2 years only on moving fast, and moving on doing a feature battle with the competitors.
After all this this we stopped and restarted a new journey focusing on things that really matter:
- Why
- How
- What
Are we doing it, and it changed everything for us.
My teammate has posted the story of the last 7 years of my team today, i give you the link if you are interested in knowing more:
(maybe off topic; these questions are highly subjective)
I wanted to get your opinion on this situation.
In the group I work in, almost all the high impact projects are assigned to foreign educated coworkers partly due to their faster execution pace.
Do you think foreign educated engineers in your group/company execute at a faster pace than engineers educated in the US?
I've wondered if the highly competitive educational paths foreign educated coworkers have had to take is a "filter" so those who eventually "make it" to the US are a very unique subset.
Basically, do you think there are issues (for non-foreign educated engineers) with project assignment and performance ranking because of this at your company?
It is ok to cut corners as long as you spend a little bit understanding what would be the correct solution and what is it going to cost/benefit you.
I have a notebook with all corners we cut at my current project. Also a bunch of other stuff (like various types of problems). The new designs are getting evaluated against my notebook.
I know it sounds funny but I just can't get into agreement with other people on how to make notes of technical debt and so, not wanting to spend too much effort on it, I just made it a notebook which I am diligently filling whenever I hear something that I would like fixed.
The key to this approach is basically pacing. If we think about a birthday cake and apply ‘measure twice, cut once’ to the actual cutting of the cake, this would be a waste of time. However, ‘measure twice, cut once’ for getting the ingredients right before baking is critical.
This is usually a critique of younger star athletes where they only have one gear when they first come into a league (usually that gear is just pedal to the metal). It takes a little bit of time to understand how to adjust pace so as to be able to move quickly in some phases, and slowly in others.
Great advice. Anytime you do things quickly, it's best to carefully understand the details of what you are doing, otherwise mistakes are made and/or accidents occur.
most problems in startup like environments(particularly from my experience in social networks), "understanding the problem" is not as easy. That's why trial and error, moving fast works.
Absolutely riveting and insightful article, this one.
Who'da thought it that to get stuff done quickly but correctly, ya gotta move fast, actually do things, but also think about what you're doing. Mind = b l o w n!
> to get stuff done quickly but correctly, ya gotta move fast, actually do things, but also think about what you're doing
As much as this seems self-evident, I think it's worth saying it explicitly, because I do think a lot of people skip the thinking and sometimes even the doing, and end up just moving helplessly in urgent nonsense that takes you nowhere, doing nothing more than panicking.
I think the correct fundamental framework, which is compatible with all sides of the argument, is that you must be mindful of your learning rate. Some approaches are depth first - perhaps that depth is satisfactory to learn what you need to solve real problems. But perhaps what you actually need is breadth. There is no way to say which is right - you literally have to just stress it out, it's not fun. Some problems only yield information when you have skin in the game - there's no way to reason out the right approach, you need to push at real boundaries and see what happens. Some of the boundaries, all of the boundaries, keep pushing, take a pause... again, you can't know for sure what's right. All you can do is constantly ask yourself - am I learning? Am I generating hypotheses, testing them, proving at least some? The framework is different for everyone, and it's _work_.