One year left since the moment I applied to my first startup project. Excitedly I went to open-minded communities. To people with a huge desire to speed up their own personal progress. To people with challenging ideas and plans to capitalize them.
I noticed that startup world is a good place to start, fail and learn. But the typical workflow is going to drag you down to the mess as at you knowledge base and generally future life. Reading this paper over and over, I started to agree with author in some places. Thinking it over, I solved to stop to start up. And there are 8 reasons why.
1. Ephemeral engineering
I think that’s the main startup lack. You should ask: “Ephemeral Engineering? What are you talking about?” Well, we all heard about “over-engineering”, a set of solutions which hard as hell. Over-engineered solutions won’t be justified by the ends. So, the engineering at startup doesn’t bring any value almost at all.
You may work at the feature, hope it’s going to bring a huge business value, put it on the product environment. And…it’s all over! The project will be closed in the next month! Your knowledge base for a specific domain will be useless! Or owner/manager will rethink and say “Move it, we don’t need this anymore”. And the probability of this case is so high at startups.
2. Always overwork
“Startup” always means “Let’s get up from dirt to Kings for a 6 months”. 6 month means around 135 business days or 5400 business hours. How can you make the solid product assuming all consumer needs are solved and the product is stable?
Of course, you can! But, to tell the truth, we are not a time-management guru and communication ninja. There are 2 cases.
The first one: you’re avoiding technical debt, carefully doing one-by-one tasks. You’re implementing the best practices. But you always failed with deadlines! It means you take extra time to solve tasks and issues and breaking the work-life balance.
The second one: you’re setting the pragmatism attribute on the top, getting things done at the time. From the owners and users the result is clear and nice. But what’s inside? Holy crap, my friends! The time goes on, the harder to change anything. It finally ends up at breaking deadlines, suddenly broken components and system downtime. As a result, extra time to work!
So, you might think that’s fine, when you’re 20-smth (I still think so). But, I guess, we’re all be disappointed looking back at our life when we’ll be retired.
3. Unclear business requirements
It always depends. When you don’t have any users which may and must dictate the ways you should build your product. When you don’t have a clear product strategy. You just have one owner and that’s all in your business. Today he may think about one goal. Tomorrow he may forget it. The day after tomorrow he’ll switch the core concept forcing you to rebuild the product from scratch.
It’s keep going with unclear answers on engineer questions about what do you exactly want. Finally you can rebuild one area 10 times in a year.
4. Low influence level – sales solves them all
If you’ve built a great system with a high-speed change management and satisfied stakeholders – it doesn’t mean your system will be recognized by business. Actually it’s a trash when it couldn’t be sold, couldn’t be advertised. At this point of view, we see the sales staff responsibility level much higher. The startup is gone when they’ll be failed selling the product.
In opposite we may look at mature high-load products. There is much more responsibility. Because of how fast you’re going, how good is the product quality, depends almost always. We can see the ING IT-revolution which clearly points on the engineering value. We can see the progress of companies after their systems became antifragile. So, there is a lot of engineering, not only sales.
5. Does it work under high load?
When you work on solid product with a dozens of DAU, you won’t doubt about implementation results. If it carelessly handles the load – it works.
What about immature startups? I don’t even complain about premature performance optimization which is useless everywhere. I’m about the current results, results which bring the value to your system. Surely, you may realize load testing to see how does it work. But it’s not real! You’re simulating the use case which never happened in reality and which just may not happen in the future.
Your response time graphs go up and down when there are about 1-2 rps. And it’s complicated to realize are you doing right or wrong. Your business metrics are stuck because there is still a petty customer base. And so on, and so forth.
6. Low budget (almost always)
Argued point. It always depends, but always exists. As mentioned earlier, startup idea is about going from the bottom at the top. So, the start capital at the bottom level. Probably, it doesn’t matter your own income (because you knew where’re you going applying to the job offer). It matters the infrastructure budget.
I saw the tight borders and incompetent cost management at this field. For example, the monthly AWS budget at one project must be less than $300 and that’s all. Sometimes you’re wasting engineer’s time working on “unreliable, but free” solution instead of applying the SAAS by $10 in a couple of clicks.
Don’t get me wrong. Cost management is absolutely important where you’re about making business profitable. But in many startup cases budget conditions leave much to be desired and make you a headache.
7. Constant workplace switch
After 1 year (may be even less) the startup is not a startup anymore. There are 2 ways after “startup” company period. The first one: success story with solid customer base and prolonged terms. The second one: walking dead which won’t be walking soon. What is it to you, engineer? You’re going to get a new job.
For now it’s not so hard for competent folks. But anyway it takes a lot of time for interviews, test tasks, careful choice and so on. Also you’ll probably have to dive into different concepts and rules at your future job. So, does it look secure and stable? Can you plan your life with your family? Are you sure you’re a master of technology you used just 3 months at your last startup?
And one more important thing. The faster you change the job, the slicker your reputation will be for employers. I’m already at this trap, continuously answering why did I have so many jobs for my short career path.
8. It’s all about projects, not products
Yes, that’s the one more contested point. IMHO, solid products look more attractive than projects. When we’re thinking about projects, we can imagine the building. You’re hardly working at it gracefully meeting tough deadlines. Finally you came to the goal – ready-to-use building. So, what’s next? Nothing. Just a support and responsibility to your direct customers and building users. Your building may not be used at all, staying on the rate offer for years and finally became obsolete.
To keep going, you’re singing the contract to build one more building. The same building, but at another place. And that’s happened over and over again. So, does it look interesting for architect?
When we talk about software products, we can imagine, well, the product! Let’s focus on water. You can produce the water for a huge customer audience. Cause they need your product. That’s already a great feeling. You’ll continuously improve your product because of the market concurrency. You may use the new water sources, speed up the delivery, improve the transport logistics. In short, there is a lot of things to do and you’re always sure that your work won’t never-to-be-forgotten. I think that’s a marvelous feeling.
What was cool in startups?
Well, nothing is fully bad. I don’t think that I wasted the time working at startups. For fully-newbies this niche seems a cool place to get started.
1. Low failure risks
What if you failed? Well, almost nothing bad! Cause you don’t have users. Cause the customer is usually loyal to you. You’ve learned the lessons, became smarter, fixed the crucial bottleneck and gained a priceless experience.
Mostly the plenty of failures are not allowed under the high load. So, train yourself, startups are the best stage for this.
2. Public cloud experience
Startups are anyway much better than obese enterprises. They don’t care about data leak horrors, so there is no reason to close the service data under dozens of cells. They know the hardware maintenance is…well, hard and time-consuming. Therefore you’re in a highway to
hell public cloud.
When you work on public cloud and soak up the best practices, you automatically keep up on the time. And that’s a magnificent feeling, isn’t it?
3. Experience accumulation
What do you need to work at the high load world? Skills! How can you gain the skills? In practice! Startups will help to learn useful stuff which is willy-nilly applied to the current project. Such steps makes you able to go up in your career!
4. Legacy avoidance
Every system has a legacy. A lot of legacy! In startup you don’t need to rewrite the giant codebase, take a few more days to just make it stable. You can design the system from scratch assuming what may work for now and what may not work. You take a chance to easily make your system fast, secure, reliable and scalable with small costs.
Although even at startups I faced with a challenge to rewrite all that’s been done before. Because it was done terribly.
Finally I switched the job to the solid product (not enterprise) with high load and dozens of active users. Thought it through, I solved that I can cover all lacks mentioned there. Surely there must be another! But I’m going to fix only 3 issues at first: ability to plan the future, personal harmony and work quality. And there is nothing more important. Let’s see what will happen in the future.
Also I want to mention that startups are not bad, not always, not all, not for everyone. It’s just my own way to look at it. Experienced folks with dozens of years in industry make a plenty of money by consulting. Absolutely, a lot of startups are growing up to large products climbing up at the market. But, once again, it’s just my one vision.
And, yes, I still didn’t read your sacred “Lean Startup”. But I will.
P.S: That’s why the Mick Jagger and Keith Richards on the blog post cover.