Looking back at my career, the projects that have had the most impact are the projects that were not rewritten. It is unfortunately very common for projects to land and then 6 months, 1 or 2 years later to have it rewritten.
Exponential impact
Successful tech projects have this property that the growth curve is not linear but exponential. This leads to some non intuitive way to optimize for their success. Here's an example of two projects I've worked on.
Work as an investment
In most jobs, if you do X amount of work, you generate Y amount of impact instantly. If you want to generate 2Y amount of impact, you need to do 2X amount of work. As soon as you stop working on the job, you stop generating impact.
With those kind of exponential growth projects, it doesn't work like this. At the beginning of the project, you are "investing" X amount of work into setting up the project. Then based on how well you did there, the project is going to generate an increasing amount of impact over time.
This is very similar to compound interest for personal money management. You invest initially and then you have to wait 20-30 years later to see real return on investment.
Difficult impact estimation
A big challenge with those kind of projects is that when you are working on it at the beginning, the absolute amount of value generated is small. So if you are judged based on a X work -> Y impact formula, you are going to have a tough time selling your work.
Trying to map your impact using the exponential formula is not easy either. Nothing can be exponential for ever, in reality it looks more like a S curve that flattens at some point. The challenge is that it's extremely difficult to predict when that flattening is going to happen to estimate the total impact generated.
The two strategies I've seen and done myself are:
- Keep working on the project during the exponential growth. This way as time goes, you'll get more and more reward as the absolute impact of the project is getting higher.
- Leave the project but use its successful aura to help get your next [job, team, project] and help getting credibility when talking to people.
Example of failure
When I worked on open sourcing React Native, I knew that having up to date API documentation was really important. I built a system that automatically generates the documentation based on the actual source code.
Unfortunately, this system, while it solved the problem, was complex to maintain and the value proposition was not clearly communicated. I don't know the history but someone removed this entire system, likely being praised for improving the codebase and maintenance.
And now, many years later, a similar system is being introduced again. Since the project is now much bigger, it is going to be significantly more difficult to achieve than the original version I built.
