In engineering, we live and die by shipping. If we aren’t shipping code, we are either doing somebody else’s job (marketing, product, customer service, etc) or we are not doing anything. And if we’re doing someone else’s job, by definition we aren’t doing our job. Our jobs are to launch new products, ship new features and somehow hold back bugs and production outages. In a small company a single person can cover all of these functions. In a larger one this is distributed across people or teams. Why speed matters If you are not embarrassed by the first version of your product, you’ve launched too late. — Reid Hoffman If your startup hasn’t shipped code, then you’re just a science fair project. Your product has to see the light of day, so you can get feedback from your users. Does it suck? Do they like it? What is holding them back from paying for it? What would cause them to say “Shut Up and Take My Money!”? If you don’t know this, then you’re going to go on a random walk and might waste your time building things that nobody cares about. Your leadership team does not have all of the answers. They can be good at hunches, but at the end of the day they are hunches and must be validated by the real world. Does Technical Debt matter? It matters if you’re a big company and you’re about to go live for millions of users. Then again, you should have a better idea of how many people your new launch is going to reach and plan accordingly. But if you’re a startup … Y.A.G.N.I. No startup has ever died from technical debt. Not even Twitter died during the #failwhale years. The thing that matters is throwing stuff against the wall until it sticks. And when you start flinging stuff against the wall, there’s a great chance that you ain’t gonna need it. Note that technical debt does not mean “shitty code”. It means that you are consciously delaying engineering your system for a larger use case. If your reports are quick enough, don’t build OLAP. If you’re launching US-only, you don’t need internationalization. If you are only getting 1000 users/day then you don’t need to rewrite your Rails app in Go. As a matter of fact, never do a rewrite. If you do run into “scaling issues”, you’re hitting it because of adoption. Your product is successful. If you have a good business model, then that means you are generating money and can use that money to hire engineers to fix your scaling issues. If you’re not making money, then you need to convince rich people that there is a pot at the end of the rainbow, provided they give you money to get there (and hire those key engineers to attack your scaling problems). How can you tell if you are fast enough? If everything seems under control, you’re not going fast enough. — Mario Andretti When you’re firing on all cylinders and shipping quickly, a funny thing happens. People gravitate to you when you’re able to accomplish things. You’ll get asked to do a lot more work. WHOA! The solution here is not to work 80 hours a week. Your job is to show up to work and keep the pedal to the metal while you’re there. The sheer amount you are accomplishing gives you dopamine hits and should keep you motivated. You’re setting ambitious goals and you’re hitting the mark. But don’t overdo it. You’ll get burnt out and studies have shown that work over 40–50 hours a week provides very little output. Go home and relax (or dive headfirst into personal projects). After it ships Ironically, I’m finishing up this article about shipping things quickly and it has taken me a full week to write it. My New Year’s Resolution for 2017 is to double-down on quantity and get stuff done, even if it means it isn’t perfect. If the work is interesting and worthwhile, you’ll get feedback and you’ll have time to make it better. If it isn’t then you didn’t waste time polishing a turd. After it ships, celebrate your wins. Make sure you let your team, partners, or customers know what you accomplished. Ask for feedback. Expect Feedback. And hopefully you’ll get feedback. Take what you’ve learned and now is the time to refactor your code, clean up the interface, and fix edge case bugs you did not consider. In engineering , we live and die by shipping . If we aren’t shipping code, we are either doing somebody else’s job (marketing, product, customer service, etc) or we are not doing anything. And if we’re doing someone else’s job, by definition we aren’t doing our job. engineering we live and die by shipping Our jobs are to launch new products, ship new features and somehow hold back bugs and production outages. In a small company a single person can cover all of these functions. In a larger one this is distributed across people or teams. Why speed matters If you are not embarrassed by the first version of your product, you’ve launched too late. — Reid Hoffman If you are not embarrassed by the first version of your product, you’ve launched too late. — Reid Hoffman — Reid Hoffman If your startup hasn’t shipped code, then you’re just a science fair project. Your product has to see the light of day, so you can get feedback from your users. Does it suck? Do they like it? What is holding them back from paying for it? What would cause them to say “Shut Up and Take My Money!”? If you don’t know this, then you’re going to go on a random walk and might waste your time building things that nobody cares about. startup Your leadership team does not have all of the answers. They can be good at hunches, but at the end of the day they are hunches and must be validated by the real world. Does Technical Debt matter? It matters if you’re a big company and you’re about to go live for millions of users. Then again, you should have a better idea of how many people your new launch is going to reach and plan accordingly. But if you’re a startup … Y.A.G.N.I. No startup has ever died from technical debt. Not even Twitter died during the #failwhale years. The thing that matters is throwing stuff against the wall until it sticks. And when you start flinging stuff against the wall, there’s a great chance that you ain’t gonna need it . you ain’t gonna need it Note that technical debt does not mean “shitty code”. It means that you are consciously delaying engineering your system for a larger use case. If your reports are quick enough, don’t build OLAP. If you’re launching US-only, you don’t need internationalization. If you are only getting 1000 users/day then you don’t need to rewrite your Rails app in Go. As a matter of fact, never do a rewrite . never do a rewrite If you do run into “scaling issues”, you’re hitting it because of adoption. Your product is successful. If you have a good business model, then that means you are generating money and can use that money to hire engineers to fix your scaling issues. If you’re not making money, then you need to convince rich people that there is a pot at the end of the rainbow, provided they give you money to get there (and hire those key engineers to attack your scaling problems). How can you tell if you are fast enough? If everything seems under control, you’re not going fast enough. — Mario Andretti If everything seems under control, you’re not going fast enough. — Mario Andretti When you’re firing on all cylinders and shipping quickly, a funny thing happens. People gravitate to you when you’re able to accomplish things. You’ll get asked to do a lot more work. WHOA! The solution here is not to work 80 hours a week. Your job is to show up to work and keep the pedal to the metal while you’re there. The sheer amount you are accomplishing gives you dopamine hits and should keep you motivated. You’re setting ambitious goals and you’re hitting the mark. But don’t overdo it. You’ll get burnt out and studies have shown that work over 40–50 hours a week provides very little output. Go home and relax (or dive headfirst into personal projects). After it ships Ironically, I’m finishing up this article about shipping things quickly and it has taken me a full week to write it. My New Year’s Resolution for 2017 is to double-down on quantity and get stuff done, even if it means it isn’t perfect. If the work is interesting and worthwhile, you’ll get feedback and you’ll have time to make it better. If it isn’t then you didn’t waste time polishing a turd. After it ships, celebrate your wins. Make sure you let your team, partners, or customers know what you accomplished. Ask for feedback. Expect Feedback. And hopefully you’ll get feedback. Take what you’ve learned and now is the time to refactor your code, clean up the interface, and fix edge case bugs you did not consider.
