Always Be Shipping!
Lessons learned from the field of successful/failed engineering projects
If there’s one thing I’ve learned working at fast growing tech companies that were more successful than others, it was that we’re always shipping faster than our competitors. And this is how I’m going to start my first newsletter: Always Be Shipping.
What separates good teams from the bad ones are their relentlessness to keep developing and releasing products at a very high cadence. They then repeat the process, and with every release, the small wins fuel optimism amongst team members, ready to take another chomp on the next set of tickets.
Why release this quickly? You do this for two simple reasons.
The longer it takes for you to ship, the more unlikely it’ll ever get shipped.
The longer it takes for you to ship, the more demotivated the team will be as the goal strays further by the day, the lower their self-esteem and productivity, hence 1).
Depending on the product you’re trying to build, you should still aim for a higher cadence for releases. If you’re working on web / mobile scale products, do it weekly at the very least. Daily is most optimal. It doubles as a forcing function to build great development and deployment workflows that are less error prone anyway. Engineering best practices can’t hurt.
If you’re working under a machine learning development workflow, the same thing applies to you. Taking weeks or even months for a model to go from training all the way to deployment isn’t ideal. It’s probably a symptom of churn and thrashing as well. If you can get your machine learning teams to build tools/workflows to bring model experimentation time down to days per cycle, just imagine how much time you’d save your ML engineers and researchers!
“Are you reckless and out of your mind? There’s no way we can ship this big feature in that time frame!”
Nope, I’m saying this for the sake of your team’s success. Understand that as a manager, your two main objectives are to 1) deliver great results 2) have a good team where team members like working with each other and treat each other with respect. In this case, it’s on you to deliver on 1). You should’ve already broken down projects further and have the right set of milestones to track overall team results. Shorten your time horizons for each milestone so they’re more easily measurable and attainable without diverging too far away from the larger goal, and then aim to hit them aggressively.
Don’t be a victim of Parkinson’s Law. Just like how shorter meetings achieve most, if not all from long meetings, shipping early and more frequently is almost always better than sitting down and pondering a grand plan on what the best product would be, only to never hit the market anyway.
If you enjoyed this, please consider subscribing! And please pass on the word to anyone you know who might be interested :)