For Software engineers, how is working in a startup of less than 10 people different from a big company?
Recently I came across a full stack developer opportunity in a startup which has just few developers working on a SaaS product. Overall team including development, sales, marketing and customer support is less than 10 people. How is doing daily development in such environment different from a company with multiple departments where multiple development teams are working in sync on same product? I understand that when team is small then you get to wear different hats depending on the task and one has to get comfortable on all aspects product engineering (planning, development, testing, deployment, hosting, bug fixes). What are challenges of daily development in a small team when compared to a large team? What are the opportunities one should look out for when working in a small team? Please share your experience if you have worked professionally in such environment, be it full time, part-time, remotely or at office location.
4/13/2021 8:12:23 AMMorpheus
5 AnswersNew Answer
CamelBeatsSnake thanks for the response. Looks like Code review time and testing is what I am worried about. I guess we'll have to take strong ownership of the code we are merging and test it ourselves. I don't have any clue how will it turn out in the long run.
Morpheus When I had joined a startup company then we had 2 sales team, 1 sales manager, 1 technical manager, 6-7 developers. We all developers were doing development as well as handling support, doing testing and releasing on production server. Now we have more than 25-30 employees with different departments. That time we had more than 50 clients. Now we have more than 200. Challenges comes but we all have to face it, we all have to work together for better future. Well This is OFF Topic question. 😃😃😃
Many hats: this point you made is one of the biggest differences. In such a small team, you're unlikely to have designers, dev ops, business analysts, QE and some other professionals, most or all of which you tend to have in bigger companies. Not only will you not benefit from the knowledge of those experts, doing some of that work means less time doing software development. A similar principle applies to the development itself: your knowledge will be wide (full-stack) but shallow. Salary: startups tend to pay less. Engineering quality, processes & workflow: startups have fewer processes so features get put in quicker but the quality can suffer. E.g. more likely to merge in code that hasn't been well-reviewed and tested due to lack of resources and/or time. Learning resources & tech: startups are less likely to pay for training and give you the highest spec machines. Culture: you're more likely to feel as though you're working with friends. People are more bought into the company mission & product.
To start a big company first make your company with one man army when you become famous people came across you 🤳🤳🤳🤳🤳🤳🤳🤳
Morpheus Yes, exactly. That's a great, positive way to approach it if you're in that kind of situation. To be honest with you, you'll probably learn loads of stuff so I'm sure it'll be worth it. You could ask them about their review and testing processes before accepting an offer. I'd encourage this but I guess how that's received will depend on the work culture in your country/area. Personally, if they say anything along the lines of "we don't have time to test" or "sometimes we just need to ship something to meet client deadlines" (i.e. no/minimal testing), that would be a red flag for me. In terms of pull request reviews, the more thorough the better (generally speaking). In a bigger company, the code repository protection rules will mean that you can't merge in your changes without at least 1 review approval. Some startups won't have that, so they may not even do PRs.