Menu

Subscribe

Surprising Things About Working at Well-Known Tech Unicorns

My past few companies - Skype, Skyscanner, Uber - have been well-known companies that I've joined in their "unicorn" phase. Unicorns are private companies that have reached the $1B valuation - and they usually do this in less than ten years.

All of these companies were well-known consumer brands by the time I joined, many of my friends using them daily. As such, I had high expectations and was excited to start. But expectations and reality don't always match. Here are the 13 most unexpected things I've learned from these working experiences.

1. Don't readily believe the press - neither the hype, nor the anti-hype

Skype, and especially Uber had beyond average press coverage both before, and after I joined. Before I worked at any of these companies, I would have taken many of the stories at face value. How Skype growth was seemingly unstoppable - hitting over 100M monthly users in 2011. Or how Uber had a terrible 2017 - reading the articles, I would have assumed it's a company no one would want to work at.

When you work at a company, you realize how selective the media and press articles are. I am sure you did not read any articles on the alarmingly slowing user numbers at Skype in 2013, nor the comparison on Whatsapp's meteoric rise in 2013-14. This was the hot topic at most company all-hands - yet, there was no press reporting on it. The only thing savy people might have noticed is Skype simply stopped reporting user numbers in press releases after a while.

Same with the terrible year of Uber in 2017. From the inside, it was a turbulent year, but a lot more nuanced with plenty of good parts - and you probably heard nothing of the good parts. There was no press reporting on the 5% or above spot pay raise to all staff. The listening sessions, where people, mostly women, grabbed the microphone and talked about what needs to change, starting now. How the whole company sat in shock, internalizing that things were broken, and it was more than just about one case - it was something bigger we needed to fix. How on the internal private chats people were messaging each other and saying things like "if we don't change the culture, I'm out". Implementing of equal pay - by raising the pay upwards only - and the regular diversity, unconscious bias, and microaggressions training that were not just for ticking the box. How, when a board member made a sexist comment on another board member on an All-Hands, hundreds of employees immediately stood up, demanded action, the board member resigned the next day and this set the tone of what is (not) acceptable.

The media usually writes about things that get clicks. Sensationalist headlines that point to something more exciting than what's actually happening get more views. Shocking news - the type of "oh my god, you need to read this" do even better. Skype was not nearly as amazing, and Uber not nearly as terrible as you'd gather from reading mainstream media articles or ones on the front page of Hacker News. If you're considering joining a well-known tech company, do your research and form your own opinion. You'll do far better than relying only on the press and forums where sensational speculations fare better than mundane details.

2. A lot more things are broken than you'd think

All of these companies were wildly successful ones, with tens or hundreds of millions of monthly customers. All of them touted that they only hire the best and that they are cutting-edge on innovation. Yet, when joining, I was surprised to see a bunch of things broken or ignored I would not have expected within billion-dollar companies.

The main Skype client - used by around 200M people at the time - had no unit tests when I joined. This was at a time when TDD and testing were pretty mainstream. Still, the release was dependent on dozens of manual testers going through thousands of test cases. You committed your code, and in two or three weeks, you'd get a ping that it might have introduced a bug. Oh, did I mention releasing took months or that the client was written and maintained in Delphi, with several unsuccessful attempts to move it over to something less niche of a language?

I've seen the accounting system of a unicorn broken so that accounting had to reconcile monthly what digital purchase was miscategorized by the software, resulting in an accounting error. This went on for years, even though both the problem and the solution were software based. I observed another unicorn mistakenly spending millions of dollars buying ads on one of their digital marketing channels - sending all this money down the drain, because of a bug on how conversions were tracked. A year later, a developer got suspicious and finally found and fixed this bug. The main system of another unicorn going down for hours after a team ignored a company-wide communicated guideline on how to store data - exactly to avoid the kind outage that followed. I could go on.

To be clear, pain points like the above are pretty normal at fast-growing and young companies. What made them seem shocking to me is how, during the interviews, I was sold - and wanted to believe - the image of a well-oiled company. I also saw several engineers joining from Google quit multiple of these unicorns their first month - after realizing that what they've been sold - working at a "small version of Google" - was not what was actually the case: a small, but quite much more messy version of something that was far away from Google.

3. A lot of the company's initial success is pure luck

You read the articles on how all these successful unicorns were founded, and it seems like the founders had these amazing visions that came together. How Garrett Camp could not reliably hail a cab, so he founded a Uber to solve this problem. How Gareth Williams couldn't find the cheapest travel deals so he built Skyscanner.

You don't even need to work at these companies to question just how much luck was involved in the company taking off in the early days, as much as it did. Each of the unicorns had several competitors, having the same idea, executing in similar ways. For Uber, there was Sidecar that launched earlier, with amazing investors. For Skyscanner, there has been far more competition, yet they won the European market, making large dents in the US and Asia as well.

Working at the company, you start hearing many of the stories that tell the story of luck being a big part of the success. Timing, early events, random decisions that seemed insignificant at the time, but proved valuable. For Skype, the P2P nature that allowed it to scale quickly in the 2000s right when operating servers was still very expensive, but people having good-enough bandwidth connections started to become more common. For Skyscanner, both the persistence and timing was remarkable. They had several competitors when starting, but there was no real money in scraping flight deals. Still, Skyscanner persisted, playing the whack-a-mole game of scrapping data even as sites actively tried to block them. They did this for years and years until they grew too big for the sites they were scraping data from - and directing traffic to - to ignore and start paying for traffic they received. Their early competitors folded midway, and their later competitors bought data straight from Skyscanner over going through the expense of doing their own scraping.

Even more interesting, the early employees I talked with also often told me how they had no idea things will grow this much, or there was that much demand for what they were building. Execution certainly matters - and the lack of it can kill a company. But the pure luck of starting the right thing, at the right time when demand is building up: this has been something all unicorns I've worked at shared.

4. There are more gut call product decisions than anyone will admit

When you launch a successful product feature that becomes the core part of the company, many people assume the company must have known it will be a success. People think we at least did some user testing before.

The reality is not like that. Usually someone - more often a product manager than not - makes a suggestion to build this feature. If it's the early stage of the company, they tell the engineers what they're thinking, and they ship it. If it's later in the company, they write a document and get approvals. While data is necessary at this point to back things up when you really want to ship something, getting the right type of forecasts is not a huge deal.

While you might think that using little data, but a lot of gut is a bad strategy, I've seen the opposite. Skype was the place where we did the most user research testing on one of our projects. And guess what? We made the poorest decisions: or should I say, we barely made any decisions. Our user research test that took two days with 14 people often came to 8:6 preferring/not preferring our suggestion. So we ran two more of these, which was a tie again and the product manager decided we'll build both versions, then A/B test it. And when the A/B test was close to a tie, we chose the one that the product manager felt would do better from the start.

Compare this with a team at Uber the early days of Uber launching a product based on a few customer discussions, but no real good projections beyond a gut feel that this will either be huge or fail spectacularly. They built a barebones product super fast, launched it, started to see hockey stick growth... and this is how both paying with cash for an Uber and - though a bit more complicated - Uber Eats was born. Both billion-dollar businesses today.

5. Process matters far less than everyone pretends it does

In 2011, Skype was doing waterfall development. Make the changes, do the long manual testing, release it. They were market leaders. If you did video calls, it was Skype. From 2012, Skype did an agile transformation, where all teams got trained on Scrum, we got certificates and setup to do bi-weely sprints and ship value more iteratively. By 2014, we were more agile than ever. Yet our market share dropped, competitors like Whatsapp making large gains on Skype. In 2020, what's left of Skype has better processes and agility than ever before. So what is your goto video calling app these days? For me, it's not been Skype for a long while now - unfortunately.

You read the blogs, go to conferences and hear engineering leaders talk about the importance of process, and how they made process changes that resulted in this or that. The Spotify model. Agile. Scrum. Kanban. Scrumban. Here's what few people will tell you, but what I've seen: the focus on process is overblown. Focus, clarity, transparency and a healthy culture are far more important: but they're harder to get right than to change a company-wide process. They're also far less sexy to talk or write about, as they are both not that exciting.

At Skype, focus got quickly lost after the Microsoft acquisition. It didn't matter that we had a new and shiny agile process with hundreds of certified Scrum masters. Most of the company was treading water, not having a clear goal that we needed to chase. Were we optimizing for NPS? Taking on Whatsapp? Increasing monthly user numbers? Growing revenue? Company vision explanations were printed and put in the cafeterias and toilets - two-page continuous texts that did not answer any of these questions.

Compare this with Skyscanner. There were screens in the office showing live how much commissions we've earned that day, and we got detailed email revenue breakdowns daily. I could not believe this level of transparency when I joined. Is it a wonder that Skyscanner was one of the very few profitable unicorns for years, and that every person knew how much their team was contributing? Or that hackathons shipped features that moved this metric up? Same with Uber. Uber had no shared processes across teams, but clear goals and metrics, with tons of internal transparency. Execution was laser-focused. In some years, the focus was on growth and active customers. Others it was partner satisfaction or safety. We always knew where we're going and why.

6. Autonomy and growth over the roof

Unicorns can grow ridiculously fast because they pour VC money to speed hiring and execution, with the calculation that this faster execution will pay off handsomely. The reality of fast growth is that you can't do this without giving high autonomy to teams and individuals. This is why you'll find few places with more freedom to operate than with unicorns in a high-growth stage.

At Uber, we more than doubled the office every year for three straight years. This meant that processes that worked for 20 developers in Amsterdam - when I joined - stopped working at 50 people. Whatever we came up for 50 people broke down at 150 people. And it was down to people on the ground - us - to make changes to keep things working efficiently.

Uber was an extreme example with its hypergrowth, but high growth and autonomy went hand-in-hand at all of the unicorns I worked at. Autonomy was not just an option: it was a necessity to thrive. Being an owner and stepping up to proactively fix things was not just something nice to have: it was the path to succeeding at places like these. Autonomy and ownership were not limited to software development. It meant stepping in and challenging product decisions, jumping in to make customer support right, and stepping out other ways of an engineer's comfort zone. This exposure is what helped so many developers working at these companies become product-minded software engineers.

Autonomy and high professional growth is one of the most rewarding aspects I've found working at unicorns, in their growth phase.

7. Not messing up the basics is just as (if not more) important as innovating

All of these unicorns were less than 10 years old when I joined. For the most part, they did one thing really well that brought customers and revenue. For Skype, it was calling others reliably. For Skyscanner: finding the cheapest flights. For Uber: getting a ride in 5 minutes or less.

Additionally, all of the companies invested tons in innovating and building new lines of businesses. Skyscanner launched hotels and car rentals. Uber launched Uber Eats, Uber Freight, and dozens of other incumbents. But the consistently successful unicorns kept being laser-focused on making sure that their "core" product kept growing, people used it, liked it, and paid for it. Skyscanner was religious about flights coverage and revenue. Uber about trip taking rate and driver satisfaction, and measuring various things around it. And when metrics or market share started going down, they reacted swiftly, reversing the trend.

Skype was the place, though, where I saw what it leads when you forget about ruthlessly focusing on your core value add and when you let competition slide. Skype was building lots of clients at the time - I was working on Skype for XBox One - buying group-calling GroupMe and starting a new app called Qik. While all the talk and focus was on the "new" - new platform, GroupMe and Qik - we seemed to have forgotten to listen to our users. Users who were frustrated that their text messages on Skype were taking minutes or hours to get delivered. This was because messaging also used the P2P protocol - and this setup simply couldn't compete latency-wise with a centralized model most other chat-only apps were using.

On the quarterly all hands, the recurring question from employees was, "what are we reacting to Whatsapp gaining huge popularity?". And there was not a clear answer from leadership that we were hoping to hear. Instead, it was a "don't worry about it; they're not in the same league" type of brushing aside. Skype leadership kept stressing how messaging apps were not our competitors, as they did not offer video calling, and thus they didn't connect people at the level we did. We forgot that seamless and best-in-class communication is what the core value add of Skype was. We focused on many things, but making the non-video part of messaging reliable was not one of them. It took years to make messaging reliable, and server-based, and it was too late by then - Skype being a video-only tool that is unreliable for text was a common perception. And despite all the innovation happening, from new features, new apps, and later a massive redesign - Skype lost market share and went from a market leader to one of the many video calling solutions.

8. The CTO is more important and influential than you'd assume

Every single 5-10 years old unicorn I've seen has had an insane amount of tech debt. And much of this tech debt is understandable. The company started out as an idea that was quickly validated. The MVP did far better than expected; the company scaling up faster than anyone had hoped. The v1 of the product was still running on the prototype. For the v2, there was little time to address things like architecture. Now, 5-8 years, millions of paying users and hundreds or thousands of developers later, moving fast is still essential. But what about paying down the massive architecture and tech debt that engineering has been carrying for so long?

I've seen strong CTOs be vital to instilling a healthy engineering culture that allowed the organization to keep delivering while taking a pragmatic approach to tackling tech debt. Also, the lack of such a CTO was visible early on. The places where there were only interim or hands-off CTOs or CTOs that were places with engineering output and quality being very adhoc. Some teams were good, but many other teams were unable to deal with the piling up of debt, and they took painfully long to ship even small changes.

Uber was the place where I experienced what a difference a stable and hands-on CTO can make. Uber had higher growth in a shorter time than any of the previous places I've worked at. When joining, I was surprised to see a large developer tooling team improving the workflows of developers. There was an upfront investment in developer and oncall tooling, and in monorepos. Discussions on tech debt happened not only between engineers but also at the CTO level. We started top-down supported initiatives like Fixit weeks: a week when all of engineering - thousands of developers - only worked on tech debt removal. Engineering was able to pull off investments that I've not seen other companies do: and I am convinced much of this came from the CTO having built strong trust and credibility with the rest of the business.

I saw a similar transformation when Bryan, one of the most hands-on engineering leaders I knew joined Skyscanner as SVP Engineering, quickly becoming CTO. In a matter of two years, Bryan made a noticeable dent in building an autonomous engineering team culture. Bryan was one of the most hands-on executives I've known, being up-to-date with tech and going deep in architecture discussions, both challenging, as well as empowering engineers and engineering managers. He built up trust within engineering quickly: using this trust to make changes in introducing company-wide development best-practices to iterate faster, with higher quality.

9. Not all old-timers grow with the company

Some of the best and most inspiring people I've worked with were early employees. But not all early employees were equally great. In each company, there were a few who you figured out is best to sidestep. There were two types of these people.

Some people just stopped growing with the company. Typically early employees who went from being an engineer to a senior engineer to a tech lead - but then they turned out to be a not-very-good lead. They stopped growing, and it became visible that they were unhappy with the situation, and with other early employees progressing faster. These were people who knew how to get things solo but were not pleasant to work with on the same team.

The other type of person was the person who struck me as a "rest and vest" type of person. Several of the unicorns did not yet have liquidity events when I joined, meaning if early employees left, they would have had to shell out often big money to exercise options, but still not be able to make money on them. So several people - who must have been paper-rich - stuck around, waiting for the first liquidity event. When this eventually came, they usually left quickly.

The difference between early employees was striking as of them were really talented people. I was lucky enough to work with some of the founding engineers at Skype and mobile engineer #1 at Uber, who all were ridiculously effective. But when joining a unicorn, don't assume that every early employee is amazing: figure out who is and you'll quickly also find who might not be.

10. "VIP" bug reports get 100x the attention of normal ones

The CEO and the whole C-level at these companies were always champion users and advocates of the product. And they were also avid bug reporters. In theory, this would be a good thing. In practice, it can be quite stressful.

At every company, I've had at least one CEO-level bug come my team's way that needed sorting ASAP. It did not matter if it was a known issue that we prioritized to fix in the next quarter. Or that it was an issue visible only to internal employees. We needed to drop what we were doing, and patch up to make sure the specific issue by the CEO/founder/executive would not occur again.

What made these exercises annoying - beyond the stress of it - was that they rarely improved the product by much. Rarely did my team, or the org start to triage customer issues better or fix more of them. There were exceptions, but even when we had a solid triaging process and a culture of paying attention to customer issues, the "VIP escalation" never went away.

11. Early employees don't always do that well

I always assumed being the first 10-20 employees in a unicorn must mean those people are millionaires by the time the company reaches unicorn valuation. While this might be true for some companies - mostly those generous with equity early on - it's not the rule of thumb I've seen.

In several cases, people who joined years later, but negotiated better were better of financially than early employees who had been there for years - being on the same level. This was especially eye-opening at Skype, which seemed to have a very different run than most unicorns. The eBay acquisition did not make many of the early Skype engineers rich, as I understood: and the subsequent private equity acquisition brought little to no incentives to old-timers. I knew a veteran engineer whose Skype equity from seven years back was worth a months' salary after several Skype acquisitions (eBay, Silverlake, Microsoft).

Of course, I also got to know early employees who did do very well, thanks to their timing and their continuous value add to the company. But it wasn't a universal rule. If you're joining a startup early on with the hopes of making big money, you're up for disappointment.

12. People associate you with the brand more than you'd expect

I happened to work at well-known brands that millions of people used. And this came with some "fame" in unexpected ways.

My friends and family would message me for any issues they had with Skype, Skyscanner, and Uber. I would get random emails on my work account from strangers making bug reports or trying to get to customer support. And if on a public forum, like Hacker News I'd mention I work at the company I did, I'd get a bunch of questions on how we implemented this or that.

Brand association has also been an unexpected positive in doing tech talks or writing blogs. I am certain I would have had fewer of my talks accepted by meetups and tech conferences if I did not have the "developer at {Skype/Skyscanner/Uber}" title next to it. Talks about technology choices and best practices at each of these companies had an outsized interest - after I've been able to get signoff from the company to talk about things. My post on things I've learned building a distributed payments system at Uber is still one of the most read posts on this blog.

While brand association has usually been a net positive, it's also worked against me. A tweet that I thought was insignificant - mentioning how my team are moving from microservices to "macroservices" at Uber made its way around tech Twitter.

Many people interpreted this as Uber abandoning microservices, very few outlets reading my follow-up replies and interpreting the message as I intended. High Scalability and their article One Team at Uber is Moving to Macroservices was a decent summary of the thread.

13. It's a HUGE thrill - especially the first year

In the first three months, my head was literally spinning at all of these unicorns. These high-growth - sometimes hypergrowth - places have incredible energy that you sense when you join.

In my first year at Skype, we shipped Skype for XBox One. At Skyscanner, we built a B2B travel booking tool and launched it with Transferwise as our first client, while opening the London engineering office, where I was engineer #1 on the site. And at Uber, we rewrote the Rider app from scratch, in less than four months. It was an adrenaline-filled and thrilling experience, in all cases.

And for the most part, this thrill kept up for a long time. Most unicorns kept growing while I was there, which meant new teams, new projects, new opportunities and after a year, I was the "old timer" with the war stories. And just around the one-year mark when doing the same thing would have been boring - I was doing something completely different, jumping on a new, high-growth opportunity within the company.

It's this fast growth that has helped me grow professionally, from a starting as a mid-level developer at Skype to a principal engineer at Skyscanner and going from developer to engineering manager at Uber.

See the Japanese translation of this article here: 有名なテックユニコーン企業で働いて驚くこと（前編）and 有名なテックユニコーン企業で働いて驚くこと（後編）.

Featured Pragmatic Engineer Jobs

  1. Full-Stack Engineer at Farmlend. £85-95K + equity. London.
  2. Senior Backend Engineer at Farmlend. £85-95K + equity. London.
  3. Senior Full Stack Engineer at Perfect Venue. $150-180K + equity. San Francsico or Remote (US).
  4. Senior Software Engineer at AI Build. London or Remote (Europe).
  5. Senior DevOps Engineerr at AI Build. Remote (US).
  6. Full-Stack Engineer at Vital. $70-120K + equity. Remote (Global, within 5 hours of GMT).
  7. Backend Engineer at Vital. $70-120K + equity. Remote (Global, within 5 hours of GMT).
  8. Technical Lead - Platform at Vannevar Labs. Remote (US).
  9. Senior Software Engineer, Fullstack at Vannevar Labs. Remote (US).
  10. Computational Geometry Engineer at AI Build. London or Remote (Europe).
  11. Senior QA Engineer at AI Build. London or Remote (Europe).
  12. Lead Backend Developer at Cineville. €53-79K + equity. Amsterdam.
  13. Senior Software Engineer, Distributed Systems at Mixpanel. $200-270K + equity. New York, San Franciso, Seattle or Remote (US).
  14. Senior Software Engineer, Fullstack at Mixpanel. $200-270K + equity. New York, San Franciso, Seattle or Remote (US).
  15. Principal Engineer at Shoplift. $185-205K. New York.
  16. Senior Engineer at Sixfold AI. New York.

The above jobs score at least 10/12 on The Pragmatic Engineer Test. Browse more senior engineer and engineering leadership roles with great engineering cultures, or add your own on The Pragmatic Engineer Job board and apply to join The Pragmatic Engineer Talent Collective.

Want to get interesting opportunities from vetted tech companies? Sign up to The Pragmatic Engineer Talent Collective and get sent great opportunities - similar to the ones below without any obligation. You can be public or anonymous, and I’ll be curating the list of companies and people.

Are you hiring senior+ engineers or engineering managers? Apply to join The Pragmatic Engineer Talent Collective to contact world-class senior and above engineers and engineering managers/directors. Get vetted drops twice a month, from software engineers - full-stack, backend, mobile, frontend, data, ML - and managers currently working at Big Tech, high-growth startups, and places with strong engineering cultures. Apply here.