Advice on how to succeed at a startup

[-]

No_Respond6706@reddit

Congrats on joining a YC-backed startup! 🎉

I’m 16 and building Kaelis, an AI Ops Copilot, and I’m always curious about life inside fast-moving teams.

What’s the biggest shift you expect going from FAANG/mid-size to a 40-person YC startup?

Anything already surprising you as you prepare?

[-]

Repulsive-Count4626@reddit

The best i can give is not waste your potential and opportunity just because its an startup you never know what future it holds.

[-]

aviboy2006@reddit

Welcome to startup life. Be a listener at first — what worked at FAANG won’t plug in 1:1 here. Understand why things are done before suggesting changes.

A few tips I’ve learned from 3 startups:

Understand the customer: why they buy, what pain points they have. This helps you focus on the 80/20 work that actually moves the needle.
Read up on startup dynamics : The Mom Test (customer feedback) and High Growth Handbook (scaling) are worth your time.
Keep a backup fund: not every Series A has perfect cash flow; salaries can be late. Learned this the hard way.
Write as you go: you’ll often be the first to touch something. Documenting now saves everyone later.
Mindset shift: you’re here to help the company survive and grow, not just write code. Sometimes that means hacking a quick prototype instead of the “perfect” system.
Bias for speed : ship fast, adapt when things change unexpectedly, but track tech debt so you can clean it up later.

You’ll wear every hat like PM, QA, architect, whatever it takes to ship. In short: be a product builder, not just an engineer.

[-]

AtharvaLarva@reddit (OP)

Just bought these two books. Thanks for the helpful reply

[-]

Buttleston@reddit

What do the other 35 people (87.5% of the company) do?

I've worked at a ton of startups and my advice is don't be too eager to change stuff. Look around, see how stuff works, think about what you'd like to change. Keep notes. Update the notes when you find out why certain things are the way they are. Resist the urge to suggest changes for probably at least a month.

A lot of times the developer UX sucks because a) people don't have time for it and b) they know the code/infra really well and have developed a workflow that is OK for them but not great for new devs. So a good way to figure out the moving pieces is to get a decent local dev environment working, or improve the one they have.

[-]

AtharvaLarva@reddit (OP)

They're mostly in sales or customer success

[-]

stevefuzz@reddit

That is a ton of dead weight. So 5 people do all the actual business domain work? Like do you need more than 5 sales people? 3? Damn, keep it lean.

[-]

joshisinsf@reddit

I agree the ratio seems insanely off, here. Usually, SaaS companies do end up being Sales/GTM heavy, but that's only after product-market fit.

[-]

AtharvaLarva@reddit (OP)

The startup has reached PMF, but one thing to note is that it's a point of sale product

[-]

stevefuzz@reddit

It reminds of the show Silicon Valley when they show up and the office is fully staffed with sales people.

[-]

AtharvaLarva@reddit (OP)

Thank you all for the replies! Y'all are so helpful :)

[-]

zhamdi@reddit

First, congrats for the position, it is very interesting to work in a startup that already raised an A turn: you have clear indicators of potential success, so it's a chance to get shares still early.

Now what you do in a startup is to be reactive, pragmatic and efficient. It's not only about skills, it is mainly about having "the deliver 20% before the 80%" mindset. Because a startup cannot afford to have all the features it would like to, you have to pick wisely and communicate with your picked choices and the reasons behind them to your team and CXOs.

[-]

WhyIsItGlowing@reddit

The culture of most startups like that is Glengarry Glen Ross monologue, but with "shipping" rather than "closing".

Nobody cares about making something nicer for six months down the line, the attitude is "now". This then becomes a massive problem when everything turns into a pathetic, unmaintainable ball of mud a couple of years down the line, but none of the devs care because the company will probably already have imploded and even if it hasn't they'll all be laid off to juice the finances to prepare for an IPO at that point. It's all about "personal brand" in that kind of culture.

[-]

YodelingVeterinarian@reddit

The thing with a startup is a "couple of years" is forever. Usually you have funding for \~1-2 years at most at any given time. So if you build the perfectly maintainable, scalable product but it takes too long you run out of time and die.

There's so often where some big tech person comes in to try startups and thinks "Okay we need Kubernetes, we need 5 monitoring and logging tools, we need a week of architecture meetings before bulding" etc., all the things that work great for big companies. But then you spend six months doing those things and one of the following happens:

You run out of money
Turns out there's no demand for your product
You spend too long building and you build something perfect, but someone built something decent and captured the whole market
You need to pivot and build something completely different, and throw out all your existing code

[-]

WhyIsItGlowing@reddit

Yeah, it's understandable and there's definitely sense to most of it early on.

The issue is most people who get used to that way of doing things will try and roll with the approach that works for "5 guys in a shed trying to find product-market fit" for way too long, because the company culture and what it incentivises will lag behind the changing needs as it goes from that earlier stage to scaling up.

[-]

YodelingVeterinarian@reddit

Fair. Tech debt is a powerful lever when you're starting out but as you scale you do need to start cleaning it up at some point.

[-]

thewritingwallah@reddit

If you join a startup, the #1 thing you can do to increase your personal chance of success is work super hard in the first 100 days.

This won't necessarily be your steady-state later, but the company should become your exclusive focus while onboarding. You should immerse yourself in the product, connect with the team, and get your projects rapidly completed to show your skills and build trust. Fast onboarding and time-to-impact are a unique way to impress.

When you work at a startup, treat your job like your career depends on it. Because it does.

Your outcome financially and professionally is high linked to the success of the company you work for.

And even if the company doesn't succeed, how well you perform has a massive impact on your upside. After all, joining a startup is a high risk / high upside decision.

If the startup does well, you'll have your pick of jobs, everyone wants to work with someone who was on a winning team.

If your startup does poorly, but it has a great reputation and you worked with smart people, that will still propel you into the next era of your career. Despite Sprig failing, all of our early employees went on to have great careers.

But if you spend years at a startup and neither gain a reputation nor direct success, it will be hard. Hiring managers won't know how to assess you, whether to take your experience seriously, and what to make of a "jack of all trades" when they need a specialist.

This is why you need a fire under your ass when working at a startup. Besides picking a great company to work with, it is the second best way to ensure a strong outcome.

[-]

devfuckedup@reddit

startup co-founder here. What I want from new devs is for them to aquaint themselves as much as possible before asking questions. odds are I have documented what your asking some where so if there are docs READ THEM ALL. Other than that be flexible and go above and beyond. The new hires that annoy me are the ones who ask things that are clearly spelled out in the READMEs

[-]

AbbreviationsFar4wh@reddit

Do everything. Dont wait to be told what to do.

You are expected to figure it out

[-]

zayelion@reddit

Avoid the ego driven people. Usually start ups have enough vision to get to market and then start coping. Things go wrong when leadership egos run haywire to cope for skills they obviously don't have and have to fake or outsource to someone that is a jerk.

[-]

LogicRaven_@reddit

Don’t panic and carry a towel.

Things can be less mature: processes, tooling, dev practices. While you might feel the urge to fix things immediately, don’t. Listen and learn why things are on the way they are.

There will be little to no documentation. Talk with people. Also non-technical roles: customer service, sales, marketing, finance. Learn the platform, learn the product and the current pain points.

Be ready to wear multiple hats. There is no such things as “I am an X developer I don’t do Y”. If it’s bleeding, you jump on it and fix the best you can. You are an engineer.

[-]

WhyIsItGlowing@reddit

Be ready to wear multiple hats. There is no such things as “I am an X developer I don’t do Y”. If it’s bleeding, you jump on it and fix the best you can. You are an engineer.

I don't think that's universal. I've been at some (admittedly hitting the scale-up stage) that were worse than anywhere else I've been for that, because they were all so focussed on building a rep for shipping x to the point where doing anything that wasn't x would just get you blanked.

[-]

The_Startup_CTO@reddit

Context: I have built (and am building) multiple companies around that size as technical cofounder CTO, but I've never worked at a FAANG or any other company with more than 100 engineers (at least not with those engineers).

At this size, there are way more problems to solve than there is time to solve them. People mostly know about these. Spotting problems is not really valuable in this context: Prioritising or solving them is. Don't be the "hey, I spotted a problem, here it is" person, but instead be the "hey, I spotted a problem, here I solved it" or the "hey, we all spotted problem A, but let's ignore it for a while and focus only on problem B for now which is more important" person.
At this size, the benefits of specialisation are way, way lower than the benefits of fewer handovers. A good dev that can also create an 80%-good-enough design will outperform a pair of a great designer and a great dev. Don't rely on others covering part of your work. Don't wait for systems to be in place. Take charge.
At this size, just building stuff isn't good enough. The engineering team needs to consistently build the right thing. And remember the part about specialisation being worse than fewer handovers? This means: Congratulations, you are a PM now, too! Again, you don't need to be perfect at it, but if you don't talk to users regularly and really understand the problem you are solving, you will struggle compared to those who do.

Apart from specific hints how to be a good startup engineer, there are some other things to keep in mind: - A startup isn't as stable yet. If it turns out that the eng team spent half a year building the wrong thing and the company now has to pivot, there might be a lot of layoffs without any heads up. Not because people are greedier or worse at their job in management, but because startups are bankrupt by default and the alternative to letting go a lot of people usually is letting go of all of them and closing the company. There are not enough cash reserves to make a slow turn. - Shares are also worth zero by default. They can be worth a lot more than shares in bigger companies, but the chances of that are slim. From a pure monetary perspective, a big company with consistent bonuses is usually better than a volatile startup, which is closer to going to a casino. - So why do this at all? Because of the broad access. At most startups, you will learn skills that are very broad, as devs might also build landing pages or set up Google Ads when needed, it is faster to grow into a management role, and even for purely technical topics like architecture, you get much broader influence than in an estabslished organisation.

[-]

turningsteel@reddit

At a small startup like this, you’re going to be expected to be nimble and deliver in a relatively quick timeframe. Things could change on a dime as the business evolves so be flexible and focus on creating value for the business. You’ll be expected to be able to manage in all realms of development from FE to BE to dev ops to whatever else.

Biggest advice I can give you is don’t burn yourself out. At the end of the day, it’s just a job and they’ll cast you aside if it suits them so learn to manage your workload and stress in a way that keeps you sane.

Also, don’t count on getting rich off stock options. The chances are higher that the business will go under long before you ever get a chance to sell shares (if they even offered you any).

[-]

justUseAnSvm@reddit

Whatever tech stack they use, just like any job, do a quick project and get familiar with the docs. Nothing too complex. Second, is understand as much as you possibly can about the business case, the end user, and customer (if different). Start ups put you very close to the decision making, the more you have a sense for what's right, the better off you'll be, as there likely won't be a sophisticated (and bloated) product organization in many cases.
Just go through whatever onboarding they give you, then try to find small tasks you can do quickly. You'll want to be producing PRs (not big ones) as soon as possible, at least in my view. The great advantage of start ups is that they can move fast, coming from FAANG, that's not something they will generally do. My big tech onboarding was weird since i went to a greenfield project, but it was like 5 months before we started producing production code.

You've seen how it works at scale, when security, compliance, and governance are built in, don't assume the way you've done things before is the right way to do them at the start up, and the the same systems and processes are required. Consider the spectrum of software sophistication, between the LLM coded compiler I made last week and stopped when the tests passed, and a piece of enterprise software like google ads or AWS on the other. You'll be closer to a weekend project than anything else.

Finally, invest in the relationships with people around you. Tread softly, you don't get to switch to another team if this one doesn't work out, it's up to you to figure out how to work with the people there, find what important problems exist, and solve them.

The team you're going to will be able to tell you where they've found themselves on the tech debt vs. velocity tradeoff, and just go with what they have. Remember, nothing else matters besides serving your customers and hitting your targets, and a lot of engineers get caught up in the "craft" or "right way. Your bosses will care about the product and end user outcomes, and that's what you should care about most.