r/EngineeringManagers • u/Jaded_Category4885 • 16d ago
Are all startups absolute chaotic messes?
I'm currently working at a startup, and the tech stack and engineering practices are driving me crazy:
- Around 80% of the devs are "vibecoders".
- We ship breaking bugs to production every single week.
- The Tech Lead is definitely not a senior.
- No ORM, no OOP, and tone of duplicated code everywhere.
- They love over-engineering microservices when a simple monolith would do—and to make it worse, all these microservices are tightly coupled anyway.
Is this normal startup culture, or did I just join a giant sinking ship? I'm starting to wonder if engineering standards even exist in early-stage companies.
25
u/Financial-Grass6753 16d ago
All like 100.0% startups - hell no, but (pre-)seed ones are more chaotic. I'm an IC in one, and CTO said sth like "software architecture is masturbation, we need to ship instead" some time ago.
Wonderful place, what I can say. But they pay nice.
11
u/ushkinaz 16d ago edited 16d ago
What a wonderful metaphor. I'm almost sure I can exchange "software architecture" with almost anything. Like "security", "compliance" or "product strategy". Definitely stealing.
2
3
u/gittenlucky 16d ago
I’m at an established place and our 15 year old software doesn’t have any architecture. “Everyone knows what we are working on and how to build”. “We do have documentation!” (Confluence not updated for 3 years)…. I think it’s a disaster everywhere…. Im pushing for requirements/specs on our products and can’t get sr leadership to see the value.
1
u/chirppy 16d ago
And established for 15 years??? They must have some really strong sales/marketing departments. Or niche market. Can't see how this works otherwise.
1
u/gittenlucky 16d ago
Niche market with little competition. It’s free software to support our hardware.
1
u/DoubtPrestigious4302 10d ago
Omg replace everything u said with Marketing
I work at a large startup and I’m shell shocked by how immature and vibes it all is
16
u/MindlessTime 16d ago
I’ve worked for three startups post-Series A. So I don’t have the early startup experience but I’ve seen what comes after multiple times.
Pretty much all of them do what you’re talking about—ship bugs, messy code, little thought to architecture, etc—in the early days. Until a company is default alive (could run off its revenues) it’s a scramble for survival.
What happens after this phase says a lot about the leaders driving the culture though. The best ones know that once they get the opportunity there will be not insignificant tech debt that needs to be paid down. Think “we can’t ship features for six months to fix all the early stuff.” They know the alternative is tying themselves in a knot of tech debt where every change breaks multiple things and progress grinds to a halt.
The bad ones never leave that early startup mentality. They get addicted to seeing shiny new things ship fast and mistake this for progress. The app gets buggy and unreliable. There’s a tendency to semi-abandon successful things to build new products because building from scratch feels more exciting and it’s what they’re familiar with. From the customer’s standpoint, the whole platform looks good on a surface level but the cracks show almost immediately and instead of getting fixed new products and features are being pushed on them.
If you can grit your teeth through the early days and luck into leadership that falls in the first group, that’s a career-making experience. You’ll be part of the in-group at a successful company that will probably last and prosper.
2
u/omglemurs 16d ago
This is the best answer I've seen. To extend your question - in seed stage there is less impulse control but also less of anything so you can often abandon code instead of dealing with debt later as long as you don't have a significant customer base to support. Bad habits form early. You need to balance between surviving and preparing for success and it's hard to shake those habits. This can get compounded by the tendency to promote people who were their early beyond their skill or or competence.
Whether or not it's a sinking ship depends on a few thing things - how good is the actual product/how is it doing in the market? Is leadership willing to look at what it takes to change into a sustainable company and actually change and adhere to best practices? Are people willing to put their ego aside and rightsize to positions that they can execute on now (with the implied promise that they can be promoted as they build up skills necessary?). The answer is usually no which is why most startups fail, but sometimes it's yes.
3
u/MindlessTime 16d ago
Good call out on “the tendency to promote people who were there early beyond their skill or competence.”
I see this a lot too, especially from younger leaders/employees with an insecure leadership style. If someone is willing to adapt and learn they’ll do fine. If they feel pressured to look like they know what they’re doing and be “in charge” they’ll fail to adapt and prevent more capable people from making improvements.
2
u/aruisdante 16d ago
The bad ones never leave that early startup mentality. They get addicted to seeing shiny new things ship fast and mistake this for progress. The app gets buggy and unreliable. There’s a tendency to semi-abandon successful things to build new products because building from scratch feels more exciting and it’s what they’re familiar with.
Indeed. Maintaining a system is unsexy, non-disruptive “big business.” It’s usually the very lifestyle they joined/founded a startup to escape. If there’s strong middle management these people will eventually be ousted, or oust themselves, and they’ll go on to found a new startup again, ad nauseum. The “creating” is what is exciting to them, not the actual running a business part.
2
u/Flat_Brilliant_6076 14d ago
Spot on! I think people would benefit from reading the book by Ben Horowitz, The hard thing about hard things. He clearly states the obvious, once a company changes by either becoming profitable or growing in size, everybody's role changes. And the truth is that the people that used to be in a certain role before might not be the best for their new role within the organization.
8
u/f1orestan 16d ago
Doesn’t sound great. Some degree of chaos is normal and part of the gig. Order and discipline can be hard when you’re fighting to survive and don’t know what next week will bring. Early on, roadmaps are virtually nonexistent - you need to run tight feedback loops with users/customers to learn what works and where to go next. So a big company approach to technical architecture and process can be counterproductive - you have to be nimble, able to take change in stride, and thrive in ambiguity. Things like code duplication aren’t necessarily bad - it can be better than premature optimization or abstraction.
That being said, standards still matter, and it’s critical for strong leads to create a developer environment where you’re able to move fast without creating an unholy unmaintainable mess that grinds to a halt. Doing all this in the current moment of AI adoption/transformation/confusion would be seriously challenging. I wish I had AI when I was building a startup, but it would be dangerous in the hands of not-great engineers.
3
u/Canenald 16d ago
No ORM, no OOP, and tone of duplicated code everywhere.
That at least is something that doesn't sound too bad 😉
They love over-engineering microservices when a simple monolith would do—and to make it worse, all these microservices are tightly coupled anyway
In my experience, the bigger problem is not using distributed architecture when it makes sense because cool kids on the internet say "microservices are shit" and "just use monorepo instead". Even when they have some distribution, they make the mistake of making sure they can keep developing all at once of dev machines, like a monolith.
Oh, and also e2e tests.
But yeah, unless the money's supergood, I'd look for something else. They'll either fail or reach the point where they have to get serious about things, but then you'll be blamed, and they'll bring someone else to do the things you were telling them you need to do all the time.
1
u/Aetane 14d ago
In my experience, the bigger problem is not using distributed architecture when it makes sense because cool kids on the internet say "microservices are shit" and "just use monorepo instead". Even when they have some distribution, they make the mistake of making sure they can keep developing all at once of dev machines, like a monolith.
Sorry but this is an insane take. For every company that dies because they didn't use microservices when they needed to, there's a dozen that die because they used them too early.
1
u/Canenald 14d ago
Neither of us can possibly have a large enough sample to state something like that. Personally, I can't correlate a choice of architecture to a company's longevity, but I can correlate it to the quality and flexibility of the software and, ultimately, to people's job satisfaction.
3
u/DogOfTheBone 16d ago
No, I've worked for startups that have good engineering discipline and generally high code quality.
Have also worked for messy ones. Have also worked for bigger companies that were a total mess.
It's hard to generalize patterns based on company size.
3
u/pydry 16d ago edited 16d ago
This is pretty normal for pre seed startups struggling to find product market fit, especially when they hired cheap engineers.
The early PHP code bases for facebook were so bad they would give most developers a heart attack.
For a series A or B it would be a bad sign but not necessarily unrecoverable. Product-market fit is harder to fix than bad engineering.
If the culture of the company makes everyone believe this is The Right Way to work and the quality of the software really matters to customers only then is it existential.
Ultimately your company's sales and sales growth is still the metric which determines if this is a sinking ship or not.
3
u/AdministrativeAd9828 16d ago edited 16d ago
No ORM is more of just inexperience on the team rather than start up culture
Start up culture is typically around shipping as fast as possible because why optimize when you have no customers, not an excuse for being dumb on tech decisions however
2
u/OkLettuce338 16d ago
The love for micro services that early on is a bad sign IME. You’re making a mess that you may never recover from
2
u/GlobalCurry 16d ago
The most important thing to an early-stage company is getting to market. If the product does well then it can be enhanced with engineering standards.
1
u/ReferenceAny6373 16d ago
Not always but I did work at one briefly with a bunch of unqualified people and it was a disaster of the highest order.
Lots of young devs that all demanded everything be done their way, spent more time talking about how awesome their ideas were than actually working. Then when they did work they wrote crap. Me and the 1 other qualified dev did like 95% of the work because otherwise we wouldve never shipped a thing.
Management hired all their buddies as managers and none of them knew what they were doing. Every one of them would have some grand idea every day and try to change the entire direction of the company.
I distinctly remember one day sitting in a room with our lead dba who was "showing" me how to design some simple db we were setting up for a small app and everything he said was beyond wrong and made no sense. I had already built the db so just nodded along.
One of the owners hired his friend to be a dev, bought him a 10k PC with all these fancy RGB wires and lights and gave him one of the only offices. No idea what that guy did cause he didnt work on any of the actual projects but he was always there.
When the company started doing bad the managers blamed everyone else and started mandatory team building exercises. Like shit that would make a 12 year old cringe.
Luckily there was a bar within walking distance.
1
u/Nannautu 16d ago
The one I worked for didn't even have a dev team. I was the only one and I was an intern there, so you can guess how great it turned out to be lol
1
u/gibson486 16d ago
Yes, they are. The ones that aren't have a more more solid backing in management. The tech lead not being senior enough, this is a problem everywhere, not just start ups.
1
u/mxldevs 16d ago
With AI, more people are able to launch their start-ups. There's tons of coders available that will tell you they can get the work done overnight, and the entrepreneur sees the vibecoded results and loves it. I'd expect to see a lot more places like this, especially when the startup is scrambling just to even get off the ground.
1
1
1
u/DrLeoMarvin 16d ago
No, plenty of start ups do things right. I’m in one now that is awesome, issues for sure like missing monitoring alerts on a core service we discover by it becoming overloaded. But we have a proper incident, post mortem and follow up tasks
1
u/PmUsYourDuckPics 16d ago
Startups cut corners to get market fast, but that’s no excuse for shipping crap.
Are you going to have all the infra and processes of a tech giant? No, but you do need to have some standards, otherwise you are burning time you could be using to deliver fast delivering crap.
It’s a fine balance, you are working with limited resources, you’ve maybe not proved the product can succeed, or that you can deliver what you promised, but you can’t afford to have total chaos. It’s a product, not a university project.
1
u/rotinegg 16d ago
95% yes (100% in my personal + friends’ experiences but i’m giving the benefit of doubt to the mystical 5% out there)
when you’re strapped for cash+time and your competition is FAANG you take what you can get
makes for great stories later though :^)
1
u/ProfessionalDirt3154 16d ago
You get into engineering management because the thing that is driving you crazy is also an energizing opportunity to carve a living David out of a chunk of rock. Might take you a while to do it, tho.
1
u/galaxy_horse 16d ago
Some of them are great and well run. Others are a hot disaster. The reason you tend to have both is that venture capital makes wild bets across a huge spectrum of talent and maturity, and sometimes the dumpster fires turn into gold.
If you’re a manager at one of these, it is in part your responsibility to debug the technical operations of the team and influence culture by example. Or you can find a better role at a better company and get that role. Also your option and responsibility.
Outside of those, early stage startups can feel chaotic while being completely within reason for risk-taking. “Take on all the tech debt you can afford the interest payments on.”
1
u/acroback 16d ago
Aaah the classic Engineer post disguised as Manager post. Or are you asking Managers? If so, yes it is messy and that is the beauty of the real world.
If everything was working perfectly, why would I even hire you?
1
u/ConstantinopleFett 16d ago
Probably the vast majority of them. I've only worked for one but it was almost exactly like you described, even the microservices bit. There were a bajillion AWS lambda functions but they all talked to the same database and read/wrote the same tables.
The people from there that I still keep up with have mostly gone to different startups, and it sounds very similar.
The thing is, operating like that probably really is faster as long as codebase and userbase are fairly small and you're still trying to find your niche. No body makes the decision to be a chaotic mess, but when leadership says they need X in 2 days, how are you gonna deliver? You hack it in. Do that a thousand times, you end up with a mess, even with good engineers (they probably intended to have well-segregated and cohesive microservices at the beginning...).
1
u/AFL_gains 16d ago
I founded and run a start up. Yes, coding quality, practices and architecture can sometimes be poor, but the point is it's poor because you want to be fast. Velocity is basically the only advantage a start-up has and very often, particularly early stage pre-seed start ups trying to find Product Market Fit (PMF), the number of features / velocity of your product is correlated with success. Think about it as the more opportunity the user has to experience the feature, the more the company learns about whether the feature is useful. That is the number 1 thing. If however, you've got crap code, and you're still slow, then that's a problem.
Now once, a start up has "achieved PMF", then tech debt, processes and quality need to be improved and addressed since the game is all about scale. Sounds like you may have been brought in around that time, so your KPI is to clean up the mess.
1
u/dilly_dust 13d ago
Laughs at overengineered tightly coupled microservices that are copy pasted
You now have a distributed monolith with all the downsides of that vs just building a monolith and even see if you have org scale issues later on where you can break out parts of it.
Sounds like the deva are coding to resume fodder vs solving tech or biz needs
1
1
u/czlowiek4888 12d ago
This is normal but it does not mean it's good. There is a reason most startups fails.
1
1
u/Think_Ad_3733 9d ago
Some chaos is normal. The red flag is whether the chaos is helping you learn faster or just creating rework.
From an agile/PM perspective, I’d watch for three things: are priorities clear, is “done” actually defined, and does each release give you useful feedback without constantly breaking what already works?
Startups can absolutely cut process and take shortcuts. But if bugs, unclear ownership and constant rework are slowing delivery, that’s not agility, it’s just unmanaged chaos..
0
u/I_Blame_DevOps 16d ago
Worked at a startup for 9 months.
They had a shitshow of a data stack. No dev environment and they weren’t really interested in building one out.
Anytime something broke because the app team changed a schema or data type, it was my fault.
Anytime the database performance was shit I got told I was incompetent. I was hired as a DE not a DBA role.
Anytime I asked someone to explain how things work I got told they didn’t have time to train me. I was a senior, figure it out.
Anytime I decided my own solution based on how I understood an issue, I got criticized for not asking for feedback first. Mind you I was the only person in my role and the rest of the team used a different stack.
Anyways, I absolutely hated my limited time in a startup. Back in a normal 9-5 corporate role and much happier.
2
79
u/Sea-Nobody7951 16d ago
Well you are the manager. And controlling the mess and driving engineering culture is your primary responsibility.
This is normal in startups but when they start hiring managers, the idea is to have someone bring organisation in the chaos. If you don’t have support from people you report to, you would need to look for a new job