Your Work Is Trash
Years ago, when Census was a baby with just a handful of people and customers, we had a problem.
Data loading tasks that used to complete in minutes or hours now needed to stretch into multiple days due to our growing business and data pipelines. But, at the time, we were using Heroku and our servers would restart daily, creating an issue for jobs that took longer than a day. These tasks, without a "resume from last stop" feature, would keep restarting from scratch, never reaching completion.
But we had customers who needed these tasks to complete!
So on a Friday afternoon, a couple of us whipped up a way for these jobs to restart from where they had last stopped, and I got it implemented. Our customer was pleased; their task could finally complete. Good weekend.
Turns out, my contribution was short lived. A month later, a colleague built a new, more robust restart mechanism that replaced what I had built.
My work was discarded. Replaced. Thrown out.
How do you think I should have reacted? Gotten angry to see my contribution wasted? Or maybe more self-reflective and doubtful of my skills, considering the replaced solution was better. Maybe I should be looking for new work?
I want to show you something:
This is a drawing I love by Henrik Kniberg that illustrates iterative product development. You don't just hand over a wheel and expect a customer to see the car you think they think they want. You start with a skateboard and incrementally develop the product as you understand their actual needs.
But there's something subtle hiding in the drawing.
That skateboard is easily leveraged into a scooter by adding something to hold, but it ultimately ends up in the trash. And then at every other stage of the journey, every product becomes obsolete, replaced by something better. Each idea becomes trash as the process unfolds.
Did the person who built the skateboard mess up? Should they feel bad because their idea ultimately ended up in the trash? Of course not. These interim solutions were great. They addressed the immediate problem and got the team the insights they needed. It all paved the way for the ultimate solution. And you and I both know that ultimate product idea won’t stay ultimate for long.
So, I hold no resentment about my discarded work at Census. The restart mechanism I developed served its purpose. Our customer was thrilled with the quick attention to their problem. My work was just a stepping stone, showing the team the importance and feasibility of a more comprehensive solution.
In product development, this happens all the time. Customers need things, and they can't always wait for the perfect solution. Sometimes, you have to devise a temporary fix, knowing that it may eventually be replaced when there’s more time to devise a better solution.
Deals also have their own kind of landfill.
“Deals are meant to fall through.”
You build features for potential customers, but if these deals fall through, where do these features end up? They might seem like they've ended up in the trash, but in reality, they’ll likely be of use to a future client. Or, they’ll lead to some other insight of something great to build.
As I write this, just yesterday our team was looking at a landing page I created for a major product launch. Someone (Daniel! I know you’re reading this.) mentioned, “It’s obsolete.” Come on man! I just published that 3 weeks ago.
Does it actually upset me? :) Not at all. Someone in another meeting said our team is shipping the equivalent of a new SaaS app every 1.5 weeks. The page served its purpose at the time of launch. But with that kind of feature velocity we easily need a refresh.
If there's a key takeaway from this, just because your work may be replaced, it doesn't reflect negatively on your abilities. Both short-term and long-term thinking are necessary, and knowing when to employ each is a skill you need to train and exercise. And if you really didn’t read any of this, just remember these words:
“Ego is the enemy.”
