I think there are areas where slow movers have an advantage. For instance, an area where the cost of an iteration is high - a slow mover may have an advantage planning and executing the iteration.

But, if you want to get faster, one thing is to ask yourself - do I have enough information to make a decision; is it possible to get more information - almost always the answer is yes, but will the cost in money or time or other resources be worth the additional information for the decision - or do we discover just as much moving forward to discover if a decision is wrong. Another question is if a decision is wrong, can we recognize that outcome quickly and what is the cost to move to a different decision.

I struggle with this daily.

At the core, I was afraid to fail combine that with, as a technical person, I _really_ don't like to do things I don't like to do. But, things I don't like to do are absolutely at times necessary to do, i.e. answer a simple email from a customer; answer an angry email from an investor.

It took me about 5 years and some very large, public (to my circle) failures to realize that it is okay to fail. That I wasn't going to get better over night, over days or months - it would take me years.

I've incrementally improved and shed a lot of who I was. It was extremely hard and it's not for everyone - but if you are willing to try and take small steps, the payout is absolutely worth it.

I changed myself to handle this and then reverted. I'm trying to fix it again. I think the key thing is related to something else they say about effective founders: when faced with a hard problem they must solve, they run towards it.

Don't get trapped in the siren song of "it's okay to be slow". Speed is itself part of quality.

I know it's possible to change. The factors that cause me to slow are:

- Fear of trying too hard and seeing myself fail: Failure is inevitable. Earlier > Later.

- A misplaced confidence that I can knock it out late: You can't do this anymore.

- Uncertainty of the next action: Any action is better than no action 80% of the time. Just eat the other 20%

- Wanting to make things 'nice' (especially if I've already been slow): Present > Nice, and nice_delta(t) < nice_delta(t-1) so you'll be producing less nice per unit time as time goes on, so just release.

Hope this helps. I know it can be changed. I've done it. I have to do it again.

I've worked on this part of myself alot, and I think the core idea that changed it for me is clearly articulating the problem you're solving and not over identifying yourself with your work product.

If the problem you're solving is all the libraries/sw for x are shitty / half baked, then it makes sense to take things slow, think it out, and design something robust.

If the problem you're solving is trying to validate a business idea / market idea, it might make sense to hack something shitty together to test that hypothesis.

For me, the issue has always been that I _personally_ identify myself with my code being robust / well designed, and that makes it difficult for me to put something hacky out there, but if I focus on the objective - to validate or invalidate a potential idea - it makes it clear how to prioritize my time / energy.

I’m successful by taking advantage of it:

when you invest in disruptive technologies, being patient and a slow mover is your friend. Many fast mover friends of mine don’t have the guts and patience to go through volatile phases of some assets, and I outperformed them (even the ones who spent 14 hours a day trading profitably)

At the same time I would never work at a startup at any position again, because looking at a TODO list of 50 items is stressful and boring at the same time.

(Ark invest is the closest to what assets that I like, they are looking 5-20 years ahead and not at quaterly results).

In my experience, a great founder should be good all three of these: 1) thinking fast, 2) thinking slow, and 3) knowing when to think fast or slow. It's easier to determine if someone isn't great at thinking fast (or doesn't know when they should think fast), for example if they don't respond quickly to an important email.

I don't think this is a binary thing. Moreover, I think the ability to meld the two and manage the balance of decisions across a growing number of stakeholders is one of the biggest challenges for founders.

As a fast mover, with a team of slow movers, I'd suggest that you can recognize your slow mover tendency and team up with a fast mover.

We unfortunately are unbalanced, and therefore move slower than I'd like (though everything always takes longer anyway).

I'm sure there are benefits to balancing out the two personalities if you can work well together.

I'm somewhat lucky that we are in a technically challenging space and the market will develop over a few years, but still, it's painful.