Some tips for Working at a Smaller Company (mostly for devs)
TL;DR - A small company can be a great place to learn, and it can be a lot easier to see the effects of the results of your work. At the same time, you likely won’t have access to the same structure, level of mentorship, clarity of career path / progression, or resources. In my experience you need to be the kind of person who (1) is happy with being more of a generalist, and (2) take responsibility for your own learning - eg fill in gaps were necessary, go deeper when needed, and lean on outside resources, friends, etc.
Original (I think) meme: https://twitter.com/VishalMalvi_/status/1716422409887314302
There are certainly some huge differences in how your day to day looks when you work in a larger company or team vs a smaller one or a startup. Of course, there are pros and cons to each environment, I’ve been thinking about it a bit, talking to a couple friends at MegaCorp™, and comparing. I thought I would jot some of those thoughts down to share my experiences.
What’s my deal?
I can’t really speak to working in a large company, at least for very long. Though I feel I can at least talk about what it’s like to work in a small company / in small research groups. For reference, my career so far consists of:
- About 5 years as a grad student as part of a small lab (2-3 grad students, a few transient undergraduates semester to semester). I got a PhD in Chem. Eng - but all of my research was computational / simulation based - so all software, albeit a different kind of software.
- An internship a Chevron - obviously a huge Megacorp, though the Business Unit that I worked in was pretty small and very focused (PVT modeling in the Rock and Fluids Characterization Unit).
- About 7 years as a full time software engineer as part of a small company < 12 FT employees (FarSounder).
Of course, your milage may vary - but from my experience here are some of the biggest differences are and some suggestions that might help you along the way.
Variety / scope
Pretty much everyone is a generalist, they basically have to be, or at least, generalists tend to be valuable to a small company with limited resources. An example, in the last few months I’ve worked on:
- Technical grant writing (we got an SBIR!)
- Cloud architecture for the feature covered in the grant
- Actually implementing the stuff above:
- Backend stuff in Python mostly (some C++), postgres database, REST API interface and hosted on Google Cloud Platform
- Frontend - NextJS w/ Tailwind on Vercel (simple map viewer basically for monitoring)
- Customer support / training - remote support
- Engineering pre/post sales support + networking at tradeshows
I personally enjoy the variety, and I’m certain that it tends to taper off as the size of the company gets larger and people begin to specialize more. The upside is that I have been exposed to a lot of different aspects of the business, I’ve had the opportunity to be in positions early in my career that I would never have had the opportunity to be in with that level seniority at a large place. That potential for rapid learning and exposure to multiple parts of not only Engineering - but of the business, is something that I enjoy.
Now for the negative though - I’m not actually any good at anything! I’ve enjoyed working whatever problem seems to the “next biggest thing” for the company, and that mindset naturally leads you to be become a generalist and work on whatever is most valuable in the moment. However, I’m not really actually “good’ comparatively, at any one specific topic. What I mean by that is that in any of the things I’ve learned, obviously a specialist in that topic will blow me away in depth of knowledge / proficiency… And I know what it’s like to specialize - I spent a chunk of years getting at PhD in a somewhat niche ChE topic before deciding academia was not for me. So if it’s important to you to keep scope narrow and really go deep, a small company might not be for you as you probably won’t have the time.
What I suggest to compensate: pick topics that interest you and go deeper outside work. Read blogs, open source repos (contribute if you can / want to, or even just reading their code, checking out their architecture), journal and conference papers, etc. Maybe take some courses on one of many open courseware platforms, check MIT’s free lectures on Youtube, etc. Even chatting with friends who are more specialized than you are about their area of expertise. Part of the problem here is you don’t really yet know what it is that you specifically don’t know - so you’ve got to get clues - find some new aspect of the topic your didn’t know about and dig deeper on your own.
Resources
At a bootstrapped company, resources (or lack of them) may be more of an issue that at a bigger company or a VC backed startup. Your “IT guy” might be head of electrical engineering, you might end up spending some days fixing / building internal tooling or on DevOps, or you might hop onto helping out with some things that are only tangentially related to engineering (eg scraping leads for sales a head of a conference / tradeshow, recording and editing videos for marketing, producing “tech” blogs, etc).
This is a big difference, I don’t think that there is much of an upside - it’s something that you have to deal with in that situation. Maybe you can argue that it offers the chance to learn a few new things.
Another issue with this - there’s not really any room for people who aren’t good. I know I sound a little ‘toxic’ - but one person who just DGAF can really be a drag on the whole team and someone needs to work with them the figure what’s going on and correct it, or get them out of there quickly.
Flexibility / autonomy
That said about resources - a small team of people who DO GAF and want to succeed working together is a cool thing to be a part of, successful or not. I think it’s more common in this environment to have flexibility and autonomy to be an actual human, and will be trusted to still get things done (go get your kids from school if you need to, run that errand, take a walk if your aren’t feeling productive, etc). I’m sure that there are small companies without this vibe and large companies (or teams within large companies) with it. Certainly with devs, remote work is more readily available and autonomy is likely higher. However, I think a flat architecture and this type of environment is likely in a small company.
Contribution
If the place is small, it’s more likely that you can see real results of your contributions. This is one thing that is really cool for people who like to make things - when you contribute something it’s very visible. It’s also very visible when you mess up, which is something to keep in mind - maybe as motivation 🙂.
Mentorship & Learning Opportunities
Even if you work with great / smart engineers - you’re unlikely to benefit from mentorship from an expert in a specific field. Remember, people in these environments are usually generalists. Unless you’re coming in straight from school or something, in that case all experience is probably useful. But after that you will still have a lot of opportunity to learn from the seniors in the smaller place, but it’s not likely to be diving deeper into a single area, it certainly won’t be the same as working with a specialist in a large company. For example - when I interned at Chevron, my mentor was an industry PhD who had spent his career modeling reservoir fluid behavior for industrial processes. The opportunity to work with and learn from someone like that in some field you’re interested is great.
My advice to compensate here is similar to above - you need to take responsibility for your own learning, be curious, and expose yourself to open source, blogs, take courses etc. Basically find “experts” to learn from in whatever topic you care about, even if that just means reading their tech blogs or papers, etc.
That’s it
I’m not trying to sway anyone one way or the other. I’ve just seen the meme of the “junior dev working at a startup” recirculating a bit, and thought I would share my thoughts. Just my two cents and some things I’ve thought about when comparing my experience to that of my friends. I would love to hear whether you agree or not, and whether your experience aligns with mine or has been different.