March 10, 2021

Don't fall in love with what you do, fall in love with why you are doing it.

Dont fall in love with your code. 
Fall in love with the results you deliver to users.

This is what Jeremy Seitz said to all engineers when he was CTO at Ricardo.

When I asked Jeremy if I could quote him for this post he gave me a bit more insights 💡

Code is a cost, not an asset.
We should never be afraid to rewrite or delete code due to ego or sunk costs.
You’re a great engineer if you deliver results
The product is what has to be perfect, not the code.

First of all: I think it is amazing to hear these words from a CTO ❤️
This really speaks to the culture we have at Ricardo.
You should definitely check us out 💪

But here is my point of view: The product does not have to be perfect.
The product, just as the code, is an Output. Outputs are never complete

There will always be a way to add more features to a product, to make a user experience more appealing, or to make an API more robust.

Everything is a cost, the whole Output is expandable: The Product, the Code.
It all serves a higher purpose, The Outcome :
  • The user pains you are trying to solve
  • The benefits you are trying to bring to your users
  • The value

This is why the 🎯 Outcome should always be the starting point for everything you do.

Don't fall in love with what you do (The Output)
Fall in love with why you are doing it (The Outcome)

If it means removing code, removing features, removing product ... Do it.

Everything you do today will be considered debt in the near future.
Not only code: The market evolves, your users evolve, standards evolve.
What is considered bleeding edge will become has-been one day. 

Un-used features have a cost, but it's not money:
It is 📱 screen real estate, 🧐 mental load... and these are limited resources.

Outputs are never complete.
This is why instead of thinking in estimate: "How much time do we think this output (this feature) will be delivered ?"...
I like to think in appetite: "How much time are we willing to invest to reach this outcome? And what could we build in that time frame ?"

Read more on working with appetites instead of estimates here

I will quote:

Estimates start with a design and end with a number. 
Appetites start with a number and end with a design.

Of course, trying to reach an outcome with an appetite of a week compared with trying to reach it with an appetite of a year will not lead to the same output... the same product...
One will be much more refined than the other

Thinking in relatively small appetites (6 weeks for Ricardo) allows you to stop and reflect frequently about where you are compared to your targeted Outcome... and decide if you have more appetite or not for it. 

This is the most effective way to make sure you are always working on the most important thing and not spending time over-optimizing something that is already good enough for your users.

📖 Further reads :

Escaping the Build Trap - Melissa Perri (There even is a video 🎥)

I'll quote one of the first sentences 

Companies end up in the build trap when they misunderstand value.
Instead of associating value with the
outcomes they want to create [...], they measure value by the number of things they produce