Working at a Startup vs in Big Tech
👋 Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. We cover one out of four topics in today’s subscriber-only The Pulse issue. To get full newsletters twice a week, subscribe here.
Willem Spruijt is a software engineer whom I worked on the same team with at Uber in Amsterdam, building payments systems. We started as teammates, and in a twist, I became Willem’s manager. He was a very productive engineer at Uber – which I regularly told the manager group during performance calibrations – and he was the embodiment of what I like to call a product-minded engineer. After spending 6 years at Uber, Willem cofounded Rise Calendar. Disclaimer: I’m an investor in this company, having invested due to knowing Willem so well after working together for years.
Willem is two and a half years into running his own startup, which just launched the public beta. I thought this a great time to ask about his experience between working at a startup, and working at a large company, as it’s the second time Willem has gone from a large company to startup.
With this, it’s over to Willem. The material below is straight from him:
Background
Early in my career, I founded two startups. One was Yunoo, a personal budgeting tool for the Dutch market. Four years after we launched, the company was acquired by a mid-sized local company in the enterprise resource planning (ERP) sector. I stayed with this ERP company for a year. But I had the startup bug in me, and so founded a second startup. This last one was a great adventure; we went to the US to join the TechStars 2013 accelerator. However, this startup failed miserably.
I was still recovering from this failure in 2015, when a friend who designed the first version of Uber– Jelle Prins – pinged me, and said Uber was kickstarting an engineering office in Amsterdam. By that time, I’d been following Uber for years, and suspected that the ridesharing industry would only get bigger.
My time at Uber was hypergrowth as its finest. In 2015 when I joined, we had 6 engineers in the Amsterdam office. Six years later, we were at 250 people. For most of my time, I was part of the Rider Payments team and worked for 4 years with Gergely.
In 2021, I left Uber for Rise Calendar as a technical co-founder. Rise is a beautiful calendar app that helps you schedule and protects your week. Since then, we’ve raised a pre-seed round – when Gergely got involved as an angel investor – and have grown the team to 7 people.
Having spent about 15 years split between startups and Big Tech, here’s my honest take on the good, the bad, and the “ugly” of each environment.
Startups: the good
Learning: Startups are such amazing places to learn in! You usually have a small developer team, and for the most part, no infrastructure, security, data science, or observability teams – which are all commonplace in Big Tech. Engineers are expected to jump in where needed, even when you don’t have expertise.
So you are forced to learn about specific topics and immediately apply them in production. Just by doing this, you broaden your expertise incredibly fast in a wide range of topics.
Impact: you can make a large impact and directly influence the direction of the company, and very clearly influence the success of the company, as well. Startups are very flat organizations, meaning you are often involved in strategic decisions.
An example of making a company-wide impact at Rise was during our Christmas hackathon, when an engineer built a Calendly-like feature for anyone to book a slot in your calendar. It worked so well that we launched the feature a month later. Going from idea, to adding, to building and shipping this to all customers, is something you rarely see in bigger companies.
Startups: the bad
Financial risk: Startups tend to pay a lower base salary than Big Tech. They rarely have the annual performance-based bonuses that are typical at larger companies. Many startups give equity to engineers, and some startups hand out handsome equity packages to early employees. Uber is a prime example of this, where early engineers did very well from generous early packages.
But let’s be honest, with any startup there is significant risk. Plenty of startups fail and close, or end up being acquired or acqui-hired. Acqui-hiring often means another company takes over the startup’s team: but does it on terms where investors – or even the founders – don’t see much of a return on their investment and equity.
Stress: startups are often races against the clock. This focus on speed and execution often leads to fast context-switching and a working environment with constant time pressure. My personal experience is that startups are more stressful than Big Tech, where there’s the option to “lean back” sometimes. This is not so much the case at a smaller company. It’s important to add that this depends very much on the culture, and my experience won’t be universal!
Startups: the ugly
Failure: Startups fail, more often than not. This can lead to ugly situations where people lose their jobs pretty much overnight. Startups are usually a tighter-knit group because people feel a personal connection to the company and product, much more than is the case in Big Tech. So shutting down a product or the entire company can be a lot more emotional than a large company shutting down one of its many products.
Big Tech: The good
Specializing: Big Tech organizations have so many specialized teams! At Uber, they ranged from mobile feature teams (called program teams – here is some history about this split,) platform teams, networking teams, and infra ones.
Internal transfers: usually this is surprisingly easy! I’ve moved between teams, and so have so many engineers, like a Rider Payments engineer who moved over to the Developer Platform team. Combined with an environment with many specialized teams, and you have a place where engineers can go really deep in a domain while working on a variety of things.
Financial stability/perks: speaking for software engineers, Big Tech pays well and almost always issues performance-based cash bonuses. Then there’s the equity granted, which is more stable and lower risk compared to startup equity.
Joining a Big Tech, and building up a “financial buffer” before going to a startup, is something I’ve seen plenty of engineers do. Things may always go south for a startup, so it’s good to have reserves!
Networking: One of the most underestimated things about Big Tech is that it’s surprisingly easy to build a large network while working there! Many of my former Uber colleagues joined other Big Tech companies, or started a new business – and there’s this one guy who ended up writing this newsletter which blew up.
I will admit the relationships I built up at Big Tech have proved to be far more valuable in the long run than I expected!
Big Tech: the bad
Lack of purpose: In a startup, it’s easy to make an immediate impact for the end-user. I used to work with Engineer #1 at Uber, Conrad Whelan, who told me this in 2015:
“If an unexpected but important task takes less than 30 minutes, just get it out immediately! Push it to production.”
Back then, Uber was akin to a startup, and not (yet) a Big Tech business. At Rise, we perform between 25 and 50 deploys per day with a team of 7. Such a pace generates a ton of energy in the team. Our end users are amazed when they see a bug they reported fixed within minutes, or when a feature they suggested is shipped a few hours later. This feeling of actual impact and purpose is much reduced in Big Tech. Also, changes take longer.
Overhead and bureaucracy: on the Rider Payments team at Uber, we had the running joke: “we’re all just plumbers here 👩‍🔧.” This referred to how much “plumbing” was needed to build even a relatively simple feature. Uber had thousands of microservices, and our team regularly made changes to more than 20 of them. Many of the changes were simply to proxy a value from one service to another.
The problem? Each of those changes needed to be approved by the team owning the service. These teams were in different time zones, and so even straightforward “plumbing” changes could take days to land.
And it got worse. For more complex changes, we usually needed the teams owning the services to carry them out. So we had a quarterly planning process to ensure all project dependencies were incorporated into each team’s roadmap. But priorities changed frequently and – surprise, surprise! – we frequently found ourselves stuck and waiting on other teams.
If this seems to be becoming a rant, it’s because it is. Uber was a fast-moving company, but also a big company, so things started to take a lot more time. At a startup, when you have a monolith the same changes take hours, not days.
Big Tech: the ugly
I had to think quite a bit to come up with anything “ugly.” There are plenty of unpleasant things at larger companies, but nothing terrible. However, one thing really got under my skin.
Misaligned incentives around performance reviews. Doing work that results in a great performance review is not always the same work that best helps the company. And this can create pretty twisted, political situations. For example:
A recently joined senior staff engineer decided to propose a project to do a re-architecture of a system. This person wrote up a neat document that was well thought out, and sent it around to other senior staff engineers. But there was a problem, this engineer took an existing document that other engineers had written a few months before, copy-pasted it, changed a few words, and presented it as their own work.
Clearly, this engineer was doing this in hopes of demonstrating how quickly they got up to speed, and how valuable their own, personal contributions were. But by not involving the original authors, the proposal lacked context that was not in this document – such as why it wasn’t made, in the end.
This is just one example where pursuing personal recognition, that comes in the form of performance bonuses, can result in actions that are not in the best interest of the company. Anyone working at a large company sees things like this.
Which is better?
This is Gergely again.
Thanks Willem, for that dose of honesty! I have to admit I always suspected Willem would go back to working at – or founding – a startup. It was pretty clear that the more “Big Tech” Uber became, the more frustrating it was for him to wait on others, versus making code changes himself. And this attitude made Willem a really productive engineer, as he jumped to working on something else while waiting on another team. During performance calibration sessions, as Willem’s manager I had an easy job proving to other managers why he belonged in the top quartile in most years, thanks to his consistently high output.
Willem’s startup background really helped him get things done, and not wait on others. At the same time, now that he’s on his third startup, I cannot unsee how his Big Tech experience of structuring things, planning ahead and building reliable systems, has proved very valuable.
Spending time at a large company and a startup, is probably as good as it gets. Both environments have very different dynamics, and you need to lean on distinct skills to succeed in each. A more common path I see is devs going from startups to Big Tech because of the increase in compensation. Although not as frequent, I also see plenty of people go the other way, from Big Tech to startups. This step feels like a bigger adjustment, especially for those who have not worked at startups before.
Growing your network is indeed an underrated benefit of working at a larger company, either Big Tech or a fast-growing scaleup. You can meet so many more people at these companies, and this is even more true if you move teams, or the company is growing quickly. I echo what Willem said about how it’s only years later that you appreciate this value. Even for this newsletter, the first few interviews were all with people I met and worked with at Uber: Ganesh Srinivasan, Adam Rogal and Sophia Vincent.
A final note on Willem’s new startup. I got involved more than two years ago and assumed the team would ship something in a few months. After all, we were talking about Willem, who was a productivity machine at Uber! But this is not what happened. For over two years, Rise kept running a private beta product. Launching so slowly is quite rare for startups, Figma is one of the best-known examples for staying in private beta for a similar duration. Rise Calendar is now out of stealth mode. And it turns out there was a reason to take so much time to build: it was to opt to launch with a product that is polished.
This was one out of the four topics covered in this week’s The Pulse. The full edition additionally covers:
- Industry pulse. A roundup of recent events in tech, with commentary.
- Are we about to see a spike in startup shutdowns? I’ve gathered evidence which suggests startup shutdowns are on the rise, and plenty of infra and developer tooling startups are also in deep trouble.
- Is down-leveling back in Big Tech? In 2021, upleveling was common across all of Big Tech. This is no longer the case, and job market dynamics are likely to make down-leveling more common.
Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 tech newsletter on Substack.