When to start

Paradise Wright

December 4, 2024 · 3 min read

It’s difficult to find the sweet spot between understanding enough of a problem without taking investigation too far, that lets you seize the opportunity to get started. One way to think of this is as a graph over time, with different points yielding different results.

an-athlete crouched-at-the-starting-line

When you’re starting a new project, you’re faced with a lot of questions - you need to understand the problem you’re trying to solve, how much effort it's going to take to solve it, and the benefits you’re going to get from the solution


I like to think about problems as a comparison between the opportunity cost and the amount of knowledge about a subject. The point in time when the project starts is reflected in the opportunity cost; you need to obtain a certain amount of knowledge before you can make a plan and choose a path to execute on.


At the beginning, if you're able to seize an opportunity you might achieve a lot of value output. For instance, getting a new UI library out in a moment that teams can immediately use for an upcoming migration can create value. Whereas rolling it out in a few months later could have almost 0 value (if not negative!), as teams could be past the time of needing it and may even have to spend significant effort switching to it.

When it comes to knowledge, generally the longer you spend researching a subject the more you know. You may not be able to know everything, but the deeper you get into something, the more you understand edge cases and nuances, and give more and more precise estimates.


Seizing opportunity and gaining more knowledge are in obvious, productive tension. This is represented by the graph showing the relationship of opportunity and knowledge in regards to value creation over time. As time goes on the opportunity slips away, while your knowledge increases.

When you first start at T1 you know nothing, but it's probably the time in which any action you take would have the most impact. The direction is unclear, at this point estimates tend to be fuzzy, and because the impact could be large, a wrong direction has a large impact down the road.


On the other hand if you spend weeks or even months researching something, then by T2 you will have all the knowledge to make a very accurate roadmap with great estimations, but the opportunity to have any impact has passed.


Where you want to be is somewhere around the intersection of the two lines at T3, or even earlier! It's good to have some knowledge to be confident you're not going in a completely wrong direction. However, you also have to acknowledge and live with a level of uncertainty. By starting to build something at that point, you can start having an impact.


Finding this point is hard, and is not an exact science. Thinking about this opportunity cost and value creation helps to push for a bias towards action to take the risk and get the reward.

Recommended for you

pair programming

Pair Programming

March 7, 2024

2 min read

Pair programming is a great way to see a problem from a different perspective. It gives you the opportunity to learn and be inspired by the people around you. And most of all, it stops you from tunnelling in on a problem and going down the wrong path for too long.

Read more

cat-doing-code-review

Code Reviews

July 25, 2024

12 min read

As engineers, the quality of the codebase is one of our core responsibilities. Code reviews are the final line of defense before code enters a codebase. Once code is in place, it becomes a challenge to address issues that do not break core functionality. At limehome we are a fully-remote agile team, we want to take advantage of what code reviews have to offer.

Read more

Kayaking in the see

The Evolution of Our Release and Quality Process

February 12, 2025

5 min read

When I joined the team as the first QA engineer in 2019, we were preparing to release the first version of our website. At the time, our process relied heavily on manual testing. Later we did implement some automation but it had lower priority. As I was the only QA for a long time, we didn’t have enough time and team members to cover everything. Five years later, we've come a long way and made much progress in our quality process. It was a tough journey, but looking back, I believe it was worth it.

Read more

Back to Blog