Let me start with an assertion: As professionals, it is our job to maximise the value we create in our role.

The next obvious question is ‘but how do we do that?’. Let me put forward that we can maximise the value we create by ensuring we’re always working on the most important problem - this is almost tautological depending on your definition of

. But then that just brings us onto another question: how do you identify the most important problem?

What’s important?

Costs & Benefits

Many people start by examining the benefits of a task. A good first litmus test is does the task have any? However, whilst a task may have benefits, it’s also guaranteed to have costs (see '

'). Working on tasks where the costs outweigh the benefits is a great way to work really hard and produce nothing of value.

So let’s say that you’ve identified a task where the perceived benefits outweigh the perceived costs - is that a good task to work on now? The answer is that ‘it depends’ - this brings us to the concept of

(ROI).

$\text{Return on investment} = \dfrac{\text{Benefits} - \text{Costs}}{\text{Costs}}$

ROI represents the net benefit (the benefits over and above the costs) as a percentage of the original costs. At any given point in time, working on the task with the highest ROI will yield the best return.

Another important concept is that of the

• the payback period represents the point in time at which the cumulative benefits received from an investment is equal to the cumulative costs expended. Depending on the time horizon for which ROI is considered, a task may have a positive ROI, but a payback period that exceeds the age of the universe.

It is not sufficient to ask merely if a task has benefits, it is important to also evaluate its costs. Moreover, it’s important to try to identify if there is any other task that you could work on that has a better ratio of benefits:costs.

If you accept this thesis, the next obvious question is: how do you actually measure costs & benefits?’

Measuring Costs & Benefits

The only real way to measure costs and benefits is to make estimates based on models of varying complexity.

There are 2 important points to be noted here:

1. Estimates contain considerable uncertainty

2. The ROI of a task depends on the time horizon considered

It should be obvious that any measurements of the costs and benefits of any non-trivial task contain considerable uncertainty. Anyone who’s ever estimated the size of a piece of development work has understood the problem of cost estimation. Good estimators may be able to achieve <20% error rate on average, but even good estimators have occasional tasks where the costs are substantially underestimated. Benefit estimation is typically even more uncertain, as the magnitude of benefits realised typically depends on even more parameters.

As noted above, when conducting an estimation of costs & benefits, a time bound has to be chosen. Over what time horizon are you considering the costs and benefits of a task? If you take a simple task that costs £50,000 in year 1 and yields £50,000 in benefit from year 2 onwards, the ROI of the task over 2 years (0%) is considerably different to the ROI of the same task over 5 years (300%). There are various other metrics like NPV and IRR that I won’t go into here, except to note that they to contain parameters that control the time-horizon.

Some Concrete Examples

1. Refactoring

Refactoring is the process of restructuring an existing body of code so as to simplify the code (reduce its complexity) whilst maintaining its functionality. The benefit of refactoring is to reduce the future cost of maintaining or modifying the code, however if the code isn’t actually touched again for several months, refactoring can have a high-short term cost and no short-term benefit. It can therefore have a negative ROI in the short-term. However, if the code is likely to undergo significant work in the future, and you consider the benefits over a longer time-period, refactoring can have a positive ROI in the long-term.

2. Hiring

Similarly to refactoring, hiring is another task where there is significant upfront investment in the form of sourcing, interviewing, onboarding & wages, but with a delayed realisation of benefits that only begin to accumulate several months after the sourcing commences. Hiring is therefore another task that has a negative ROI in the short-term, but a positive ROI over longer time horizons.

What’s important depends on your time horizon

Consider 2 tasks:

• Task A has a ROI over 6 months of 50%, but a ROI over 2 years of 100%

• Task B has a ROI over 6 months of -30%, but a ROI over 2 years of 400%

Which task is more important to do now?

The answer to that question depends on what you’re optimising for - or more specifically, what time horizon you’re optimising over, a concept I’ll refer to as

.

If you’re optimising for returns in the next 6 months, task A is preferable, however if you’re optimising for returns over the next 2 years, then task B is preferable. (There’s obviously some nuance and complexity here, but the general point stands regardless.)

Your optimisation horizon shifts over time

On day 1 of existence, a startup does not optimise for it’s 20th year of operations, instead it generally optimises for near-term survivability and to prove the economic viability of its product(s). As a startup grows its revenue base and receives funds from investors, it's optimisation horizon naturally grows. It can begin to consider investments with a longer payback period because the startup can be reasonably confident that it will still exist at the end of the payback period.

It’s important to note that this isn’t a guaranteed one-way transformation - the optimisation horizon of a startup can shrink as well as grow. If a startup loses key accounts or misses out on an expected fund raise, then the optimisation horizon can shrink dramatically.

The key notion here is that existential threats drive rational short-termism, whereas stability drives long-termism. Amazon can reasonably optimise over a 10 year time horizon because it can be reasonably confident of its existence in 10 years.

If you work in an environment with an increasing optimisation horizon, you will naturally come to regret some of the choices made in the past. As those choices were optimising for a different time horizon, they are unlikely to be the optimal decision with respect to your revised time horizon.

The different optimisation horizons of different companies is always very evident in software codebases.

:

1. It ignores the lost benefits (missed revenue and fundraising) that can result from a delayed time to market

2. We may simply not care about costs in year 5 as much as we do about costs in year 1 (this is evident in the saying “do things that don’t scale”)

Due to an early stage startup’s short optimisation horizon, the optimal strategy for an early stage startup is instead to cut as many corners as possible, even if this increases total cost of ownership down the line. If the startup is successful it will come to regret these decisions, but in this case, surviving long enough to experience regret is a good problem to have.

Are you all optimising for the same time horizon?

Shifting optimisation horizons are hard to manage. Even if the optimisation horizon itself remains constant, the date for which you’re optimising constantly shifts to the right, and if the optimisation horizon is itself changing then it can pose even more challenges.

When working with others, it’s important to explicitly agree on your optimisation horizon. For a given problem there are likely to be a variety of solutions with different payback periods and superior ROIs over different time horizons. Many a good solution have been thrown under the bus not because they’re bad, but because there is an implicit disagreement over the optimisation horizon.

Summary

• We should seek to maximise the value we create

• We can do this by ensuring we work on the most important task at any given time

• The most important task is the one that has the highest ratio of benefits to costs

• A task is not important just because it has benefits

• A given task can have different benefits and costs over different time horizons

• The best task to work on depends on what time horizon you’re optimising for ('optimisation horizon')

• Your optimisation horizon will change over time

• Optimising for minimal total cost of ownership is a mistake for early stage startups

• When working with others, it’s important to explicitly agree on your optimisation horizon