Never assume linear progress in your projects.
I recently achieved my long-term sports goal - finished the OCR trail race (22km-long/1400m-elevation) in Harrachov, Czech Republic. As the Elite runner, I accomplished every single obstacle. It all required months of training in strength, endurance, dynamics, and technique.
Similar to my other projects, this process was backed by some data. When I reviewed the last few months, the progress was - no surprise - close to the s-curve.
During the journey, it was sometimes linear, sometimes exponential. There were also plateau moments and some regression.
I worked too hard or too little. Experienced illness, injuries, or tiredness.
I have seen this chaotic pattern so many times in my professional projects.
I worked on:
- language to language rewrite
- Replatforming or other migrations
- Introducing new solutions to an existing tech stack
- Fixing crashes and customers' errors
- Rolling out a product feature country by country
- …and tens of others
No single project had linear progress.
When working with engineering leaders, I keep reminding them they will fail to deliver their promises if they assume linear progress in their projects.
Our world is too complex, with entropy playing its main role. You will experience unexpected challenges, randomness, and dead ends.
What can you do then?
- Assume your progress will be s-curve, most likely
- Maximize moments of exponential growth
- Identify plateau as fast as possible
- Don't be afraid of regression - ensure it plays a vital role in your work (recovery, jump back, etc.)
I won't tell you never give up. But rather review the data and assumptions, don't be stubborn, and try many things during the journey.
Or change the journey if the one doesn't make sense anymore.