Iterate as fast as possible

Have an aptitude for serendipity

Get more parts on the table

Stay motivated with recurring small dopamine hits

Incremental correctness

Keep it simple, stupid

Measure output, not outcomes

Non-technical regrets at Spectrum

Solve your own problems

Design a process

 Make it easy to jump in

# Always be shipping

The more things I ship, the more chances serendipity has to strike one of them. ([[Have an aptitude for serendipity]])

If you never release that song you composed, how is a music label meant to discover you? If you never release that novel you wrote, how is a publisher meant to stumble upon you?

This doesn’t just apply to big projects, since I try to [[Iterate as fast as possible]] any small change counts, which also makes me [[Stay motivated with recurring small dopamine hits]].

> _”I like shipping things, and shipping consistently has helped put me at the forefront of a number of big shifts in technology over the past few decades." - Seth Godin_




# Be as cross-functional as necessary

[[🌱]]

- Figure out if this is actually valuable and why

The broader your knowledge the less coordination between people you have to the easier it is to [[Iterate as fast as possible]].

Inter-person coordination overhead is a non-trivial for innovation and is often the bottleneck when trying to [[Iterate as fast as possible]]. The more a single person can cover in a vertical the better.

- Is this actually often the bottleneck?

Rather than splitting work up vertically (e.g. design vs. dev vs. data science), split it up horizontally (e.g. person1 works on thing1, person2 works on thing2)




Invest in force multipliers

Work in public

Talk to people

Be interested

Sell your story

Personal brand as moat

# Build a diverse network

The more people I know, and the more diverse their perspectives are, the more parts I can theoretically access. ([[Get more parts on the table]]) This requires me to [[Be open]] to new perspectives and to [[Seek discomfort]].

The more I talk to my big diverse network ([[Talk to people]]) and [[Work in public]], the higher the chance that one of them serendipitously connects my ideas to something I had not considered before. ([[Have an aptitude for serendipity]])

It also makes it easier to [[Iterate as fast as possible]]. I can solicit good feedback quicker, which lets me speed up some of my iteration loops.

> _”This is not the wisdom of the crowd, but the wisdom of someone in the crowd. It’s not that the network itself is smart; it’s that the individuals get smarter because they’re connected to the network.” — Where good ideas come from_




Always be shipping

Build a diverse network

# Have an aptitude for serendipity

My career is almost entirely based on serendipitous connections. While they are random chance, of course, the one thing I take credit for is having (what I like to call) an “aptitude for serendipity”. I try to create as many opportunities for luck to strike me as possible.

Some ways I try to influence serendipity are:

* [[Iterate as fast as possible]] and [[Get more parts on the table]] so I have a higher chance of inventing something novel. ([[Invent by combining things in new ways]])
* [[Always be shipping]] so serendipity has as many chances as possible to strike one of them.
* [[Work in public]], [[Talk to people]] and [[Build a diverse network]] so more people have a chance of stumbling upon my ideas and connecting them with their own thoughts.

Personally, publishing open source projects has been a great way to do this. There is no downside, assuming you [[Solve your own problems]], and the upside could be career-defining. My career was defined by react-boilerplate being posted and upvoted to the HackerNews frontpage!




# Incremental correctness

Incremental correctness is a concept I first heard from [Guillermo Rauch](https://twitter.com/rauchg) and internalised after [Max Schoening](https://twitter.com/mschoening) repeated it often enough. Essentially, start off with a minimum-viable product and then [[Always be shipping]] small, incremental updates. In theory, if you [[Iterate as fast as possible]] this the fastest way to build something great from scratch.




My morning routine

Thinking practice

Have a great morning routine

Invest in the best tools

About these notes

My mental models

# Invest in force multipliers


Force multipliers are anything that increase your effectiveness by (ideally many) multiples. Adding new or improving your force multipliers is a great way to move faster towards your goal.

These are some force multipliers I am thinking about at the moment:

* [[Get more parts on the table]]
	* [[Build a diverse network]] and [[Talk to people]]
	* [[Work in public]]
	* [[Seek discomfort]]
* [[Have an aptitude for serendipity]]
* [[Iterate as fast as possible]]
* [[Invest in the best tools]]
* [[Have a great morning routine]]
* [[Thinking practice]]




Be as cross-functional as necessary

# Iterate as fast as possible

The more iterations cycles I can go through the faster I will arrive at a great result. ([[Incremental correctness]]) It also helps with [[Always be shipping]], if you have lots of iterations you have lots to ship. Iteration cycle speed is a force multiplier, and keeping it as fast as possible is crucial. ([[Invest in force multipliers]]) 

Some ways I improve my iteration speed are [[Invest in force multipliers]], [[Keep it simple, stupid]] and [[Be as cross-functional as necessary]].

For example at the micro level, I make sure my build setups are fast enough that I never have to wait to see changes in development. For example at the macro level, I try to give my users a quick and easy way to submit feedback and for me to see it.

Hunch: Anecdotally, I think the 80/20 rule applies to iteration speed bottlenecks. There seems to be bottlenecks which will speed up iteration cycles 80% without a lot of work, the hard part is figuring out where they are.

> _“Speed of developer iteration is the single most important factor in how quickly a technology company can move." — Paul Biggar, founder of Darklang and CircleCI_




# Keep it simple, stupid

Complexity is the root evil that makes it difficult to [[Iterate as fast as possible]] and thus [[Always be shipping]] in the long run. See [KISS principle - Wikipedia](https://en.wikipedia.org/wiki/KISS_principle).

- Fill this out




# Measure output, not outcomes
I have always measured myself based on out_comes_ (e.g. being featured in Forbes), not my out_put_. As [@chantastic points out](https://chan.dev/blog/outputs-and-outcomes/), I am probably hurting myself by doing that: I have zero influence over eventual outcomes, but I can control my output.

I should celebrate myself whenever I am as productive and creative as I want to be, not when some random outcome occurs. That would help me [[Stay motivated with recurring small dopamine hits]] as long as I [[Iterate as fast as possible]] and [[Always be shipping]].

For example, at the moment I want to improve my endurance, so I added a 5km run to [[My morning routine]]. I do not measure myself based on outcomes (e.g. I can run 5km in 30 mins), I measure myself based on whether I run every single day. Whatever endurance improvements come from that are incidental.

Of course, I do eventually want to get somewhere, so I have direct my outputs to where they _could_ help me achieve the outcomes I want. I don’t know how I can ensure that is the case, however so far it’s worked out fine.




Spectrum

# Non-technical regrets at Spectrum
In hindsight, these are the things I wish we had done differently at [[Spectrum]].

## We should have focused on our niche
- Wanted to build for our use case, open knowledge communities (e.g. open source)
- Needed to make money, so built business features
- Businesses were not interested, and had we focused on our core niche use case we would have grown much faster
- Easier to raise money if necessary, more satisfying, ultimately more momentum and higher chance at success

**It's better to have 100 true fans who love the product than 10,000 barely interested users.**

## We should have done way more marketing
- Spend too much time on building new, shiny features
- Should have spent more time on marketing, typical engineering mistake
- Not just social media, but also in-product growth marketing, marketing pages on the website, etc.

**Do way more marketing and sales than you think you need to do.**

## We should have told our story
- Branding was good and unique
- Brand did not have minimum viable personality https://avc.com/2011/09/minimum-viable-personality/
- It differentiates you from the "big guys" as they cannot have a story as personal as you in most cases
- For example, The Practical Dev (dev.to) is doing a great job at this

**Tell your story, it differentiates you from the big players in a crowded market**

[[Sell your story]]

## We should have launched all the time
- Launches are great for marketing, every new release excites customers
- Shipped tons of stuff without ever announcing it
- Missed opportunity to showcase a new feature and get more users at the same time

**Launch before you think you are ready and then again and again and again.**

[[Always be shipping]]  [[Iterate as fast as possible]]

## We should have stuck with the MVP technology
- Had an early MVP built with minimal technology (Firebase)
- Saw some tiny traction, thought we needed proper setup for custom functionality

**Stick with the minimum viable technology setup until you feel product-market fit. You will know in your heart if you have it.**

## We Did Not Talk Enough With Users
- Went into a hole and built a shiny feature for months (e.g. WYSIWYG editing) without talking to users about their priorities
- Ended up wasting valuable time and adding a lot of unnessary tech debt

**Talk with your users, they should be your guiding star.**




How I overcome the Resistance

2020-03-24

# Stay motivated with recurring small dopamine hits

The best way I have found to stay motivated once I have started working is to get constantly give myself small dopamine hits. I try to [[Always be shipping]] tiny changes, to [[Iterate as fast as possible]] and to [[Measure output, not outcomes]] to make that happen.

The idea is from the great book “The Motivation Myth”, which I thoroughly enjoyed. Here are some quotes from the book itself about this:

> _“Motivation isn’t something you have. Motivation is something you get, from yourself, automatically, from feeling good about achieving small successes.”_
> _“If you want to stay motivated, if you want to stay on track, if you want to keep making progress toward the things you hope to achieve, the key is to enjoy small, seemingly minor successes—but on a regular basis.”_




@mxstbr's working notes

Iterate as fast as possible

Links to this note

What do you think?