Gergely Orosz
Every salary survey said he had hit the ceiling. Then an offer doubled his pay.

One strange thing: the 90th percentile, and then double

In 2016, Gergely Orosz was a principal engineer at Skyscanner in London, earning £93,000. He figured he was near the top, and this was not a feeling — it had data behind it: salary surveys kept telling him he was well above the median, in the 90th percentile. What more does a man making ninety-odd thousand pounds in London expect?

Then Uber Amsterdam made him an offer. Total compensation of roughly €220,000–250,000, almost exactly double. By year four it was €283,000.

Worth pausing here. The point is not "he changed jobs and got a raise" — that happens constantly. The strange part is this: the data telling him he was in the 90th percentile was not wildly wrong. It had simply been sampled from a world that did not include the place he was about to go. The percentile was real, as long as you accept whose percentile it was.

He later described the moment:

It felt like I discovered a "secret, upper-tier" of the market that no one else knew about.TechPays has been acquired by Levels.fyi, 2026-05-13

If the story stopped there it would be one man getting lucky. What turned it into a decade-long project is that he then moved to the other side of the table.

Who he is

Gergely Orosz is Hungarian, based in Amsterdam. His career, in his own ordering: Skyscanner; Skype/Microsoft (he was on the team that shipped Skype on Xbox One, and also worked on Skype for Web); Uber, where he worked on the rewrite of the distributed payments system and open-sourced RIBs, Uber's mobile architecture framework. From 2016 to 2020 he was an engineering manager at Uber Amsterdam.

One detail is more vivid than the CV: he has written that across four years of managing at Uber, not one of his direct reports left the company — up to the summer 2020 layoffs, that is. He credits part of it to the compensation system and part to other things; and the way he writes that sentence is very him: give a checkable fact first, then admit the explanation is incomplete.

He started the blog in November 2015. Around 2021 the centre of gravity moved to a paid newsletter; today he claims over a million readers, the largest technology publication on Substack, and states that he takes no sponsorships of any kind. The blog itself has not gone quiet: there was a new post four days before this page's review date.

What he has been wrestling with

You only see his real subject once the offer story is finished.

After the doubling, Orosz became an engineering manager at Uber and started hiring for his own team. And he kept meeting the same kind of candidate: strong, but unwilling to start the process. Their reasoning was that they had already asked around — they were near the top of the market, a move would get them 5–10%, and that wasn't worth several rounds of interviews.

I had no way of telling them "your data is wrong, this place pays a lot more!" and so several of them just never bothered to interview, assuming the most raise they would get would be 5-10%. When they could have potentially doubled their compensation…

Note the first clause: I had no way of telling them. This is not a complaint about slow candidates. He is saying that he — the one person in the conversation who knew the truth — had nothing that could make anyone believe it. A hiring manager saying "we pay more" is just a hiring manager saying the thing hiring managers say. For that sentence to carry weight it has to come from somewhere other than him: a dataset, a site, a checkable record. None of which existed.

That is his decade-long subject. In one sentence: software engineers are systematically blind about their own industry, and the blindness is not an accident — somebody is maintaining it.

What the blindness covers looks, on the surface, like four unrelated things: what I'm worth, what other companies are actually like on the inside, what "good" even looks like, and whether this company is about to die. But they share a shape: the information sits with a small number of people who have no incentive to hand it over. Nearly everything he has written since is an attempt to fill that hole, and the method is remarkably consistent: don't publish opinions, build instruments.

His ideas, told as how he found them

1. Three peaks: there is no "average salary," only who your employer benchmarks against

The first thing he noticed was not his own offer letter. It was two numbers that didn't line up.

On one side, the public surveys. Honeypot's 2019 Amsterdam developer survey put the most experienced developers at an average of €55,000, with the high end above €70,000; talent.io's 2021 report put the most senior software engineers in Amsterdam at €60,000/year.

On the other side, what he could see from inside. Average senior total compensation at Uber went from €110,000 in 2015 to €170,000–230,000 by 2020. And not only Uber — he was running EU salary research at the time, and watched Booking.com's senior packages go from around €100,000 in 2016 to over €150,000.

In the article he reduces the gap to four words: "Where is the disconnect?"

There is a fork here, and it matters which branch he refused. The easy explanation is that Uber is an outlier — top companies pay more, surveys measure the whole, no contradiction, move along. Most people stop there. He didn't, because Booking.com's curve looked exactly like Uber's, and Booking.com is a Dutch company. Two points make a line, and an outlier stops being an outlier: it starts looking like a population the survey simply missed.

So he counted. He gathered close to 200 compensation data points from engineers in the Netherlands and laid them out. What came back was not a normal curve with a long tail — the "most people in the middle, a few lucky ones on the right" shape that intuition defaults to. He got three peaks, and the peaks barely overlap.

The definition of the three tiers is the most counterintuitive and most usable part of the model. It sorts neither by company size nor by industry, but by something that sounds extremely boring: who the company benchmarks against when setting pay. Tier 1 benchmarks only against local peers — the IT department of a local supermarket, a local e-commerce site; his tell is that these places usually call engineering "IT" and treat it as a cost centre. Senior roles in the Netherlands: €50,000–75,000, essentially no equity, bonuses capped around 10%. Tier 2 benchmarks against all local companies regardless of industry (Adyen, Nike, Miro, MessageBird): €75,000–125,000, bonuses up to 20%. Tier 3 benchmarks regionally or globally — Uber, Booking.com, Databricks, Stripe, Netflix, plus proprietary trading firms like Optiver and Flow Traders: €125,000–250,000+, with equity for everyone including entry level, and cash bonuses reaching 40–50% of base for top performers.

His numbers are always itemised, which matters again below: a typical senior Uber offer in 2020 was €115,000 salary + €20,000 target bonus + roughly €50,000/year of vesting equity ≈ €175,000.

Then the summary line:

There is no longer an "average" salary for software engineers in Europe / the Netherlands: just an average salary per one of the three, distinct categories.The Trimodal Nature of Software Engineering Salaries in the Netherlands and Europe, 2021-03-08

And with that the opening puzzle resolves. Tier 3 compensation data is almost entirely absent from Glassdoor, Payscale, Honeypot, talent.io and Stack Overflow Jobs; what those sites capture is tiers 1 and 2. So the "average" in those reports really is an average — it is just the average of the first two tiers, circulating as though it described the whole market. The 90th percentile he saw in 2016 wasn't lying. It honestly computed a number from a distribution that didn't contain tier 3.

And the error runs both ways. He drops in the sharpest inference in the piece, and it is aimed at employers:

Most companies tend to assume they are a tier higher than they actually are - because they have little data points that prove otherwise.

The asymmetry is not "companies know and engineers don't." It is that both sides are reading the same mutilated dataset, and both conclude they are standing higher than they are. As for why the three tiers split apart in the first place, his explanation carries no moral charge: Silicon Valley companies opened European offices. Between 2016 and 2018 Uber re-benchmarked — no longer against the Netherlands, but directly against Facebook in London and Google in Zurich. The evidence is concrete: Uber's 2018 packages were nearly identical to Facebook London's, which was no accident, because the same candidates were holding offers from both.

The article did not stop at being an article, and that is what separates it from a normal "insight piece." He open-sourced the data points he had collected and built TechPays, a European compensation site with anonymisation, freelancer coverage, and a breakdown of how each package is assembled. In 2024 and 2025 he extended the model to the US, UK and India using Levels.fyi data. In May 2026, TechPays was acquired by Levels.fyi.

One last thing has to be recorded, because it is what separates him from a straightforward high-pay evangelist: much of tier 3's total compensation is equity, and equity goes down as well as up. Many Uber engineers held RSUs priced at a $48 reference; Uber IPO'd at $45; by the time the lockup expired and they could sell, the stock was at $30, and it touched $21 in 2020. His line: "The highest compensation packages will also typically be the most volatile ones, value-wise."

2. Write it down: the only thing that scales in an organisation is sentences

He wrote three pieces on this line — one on process, one on architecture, one on writing — ranked 2nd, 3rd and 5th on his own Popular Articles page. Read together they are three faces of a single idea.

It starts with two things that bothered him for years. At Microsoft and at Skyscanner he kept hitting the same pair of problems: first, no visibility into other teams building, or having already built, the same thing; second, tech and architecture debt piling up because different teams did things differently, in approach and in quality.

That sounds like two problems. At Uber he found one process that solved both: plan before building; capture the plan in a short document; have a few relevant people approve it before work starts (he compares this to requiring a review before merging a pull request); and then — send the document to every engineer in the company and let anyone comment. That last step is where the eyebrows go up, and he says so himself: "Yes, this the step that probably sounds crazy." (His typo, not mine.)

What is interesting is his defence of writing it down, because it avoids the usual "documentation is good for you" route entirely. His argument is about efficiency, and it runs backwards: if the team genuinely agrees, writing it down should be easy — a few hours, one person, everyone else nods. So if it is hard to write, that is the finding. And in practice, the moment someone starts writing, things surface:

"This is not what I meant when we talked." or "What about this important edge case we forgot?" and "If we change this here, it could break this other part of the system" are things that often come up when writing the plan down. It's great to have these discussions before having the same realizations when the project is halfway done.Scaling Engineering Teams via RFCs: Writing Things Down, 2018-10-03

In other words: the real output of a design doc is not the document, it is the disagreement the writing exposes. It is an integration test you run before writing any code.

His defence of the company-wide broadcast is similarly indirect. He does not claim everyone will read them — he concedes the noise goes up, and offers an unromantic fix: email filters are easy to write. What he claims is something else: "The type of information pushed to people in an organization shapes the culture considerably." Then he offers himself as evidence — in his first months at Uber he obsessively read other teams' planning docs, and learned more about what other teams were doing than in years at a large company where that information was not visible.

The second face is architecture. He opens by establishing standing: the Uber distributed payments rewrite (replacing two live payment systems used by dozens of teams, with no business impact permitted), Skype on Xbox One, open-sourcing RIBs. Hundreds of engineers, millions of daily users. Then he says something a lot of people find uncomfortable:

…none of these designs used any of the standard software architecture planning tools. We did not use UML, nor the 4+1 model, nor ADR, nor C4, nor dependency diagrams. We created plenty of diagrams, but none of them followed any strict rules. Just plain old boxes and arrows…Software Architecture is Overrated, Clear and Simple Design is Underrated, 2019-09-17

And: "there were no architects on the teams that owned the design." Experienced engineers drove the discussion, but no single person owned the architecture, and the most junior people on the team took part, challenged decisions and offered alternatives.

The weight of the piece is not in the "we didn't use UML" fact, which is just an anecdote. The weight is in a historical argument that inverts the causality of the entire methodology industry in one sentence: "Architecture patterns are tools that came after the solution was solved, in hopes of making the lives of others easier." Engineers independently arrived at similar solutions; someone noticed the similarity; only then did it get a name and a literature. So starting from the pattern gets the causation backwards.

He also offers a test you can apply on the spot, cheaper than any methodology: you should be able to explain your system's architecture clearly on a whiteboard, starting high-level and going deeper as needed; if that is hard, or not clear enough, there is still work to do on the details.

The third face is writing itself, and it stitches the other two together. The argument is short: companies grow, and past a few dozen people face-to-face stops being enough, so "Writing becomes essential to make thoughts, tradeoffs and decisions durable." As for the threshold for moving up, he is blunter — "the ability to communicate and influence beyond your immediate team," he says, is the essential skill for engineers growing in seniority.

Put the three faces together and he is saying one thing: the only thing in an organisation that crosses headcount, floors, time zones and years is a written sentence. So anything that makes sentences harder to write or harder to read — jargon, UML, formal methods, an architect approval chain — is spending in the wrong direction. "Keep the design simple" is therefore not an aesthetic preference in his hands but an inference with a mechanism: simple designs are better first because they are easier to write down clearly, and therefore easier for more people to poke holes in.

3. You cannot see engineering culture from outside, so build instruments — all the way to doing journalism

This line starts from a problem that has already been solved. In 2000 Joel Spolsky wrote the famous Joel Test: twelve yes/no questions about a software team (do you use source control? can you make a build in one step?). Twenty years later essentially every company passes all twelve — it became a floor, and stopped discriminating.

So Orosz wrote a 2021 version. And the real design rule of the new test is in its first sentence:

12 questions to get a sense of what a tech company is like to work at, based on things most job postings do not mention.The Pragmatic Engineer Test: 12 Questions on Engineering Culture, 2021-10-11

"Things most job postings do not mention" is a very good filter: it automatically excludes all marketing copy ("we have a great engineering culture") and leaves only facts a company has to confirm or deny. And each item is written so there is no wiggle room — on equity, discounted employee stock purchase plans explicitly don't count; on oncall, the question isn't "do you have oncall" but whether fixing an unhealthy oncall takes priority over any product work.

Twelve yes/no questions is not laziness, it is design. Yes/no questions can be walked through out loud once you have an offer — which is exactly the "reverse interviewing" he advocates: in the back half of the process, you interview the company.

Then comes the move in this section most worth stealing. He published results from 200 submissions: 31% passed all twelve, 68% scored at least 10. The numbers flatter his case. And he immediately turned the knife on himself:

I realize there is lots of selection bias at play here - teams who score higher on these questions are more likely to fill it out.

That sentence sits directly underneath his own best result.

But the twelve questions have a boundary they cannot cross: they can only measure what a company is willing to say. A company that has stopped paying wages can still answer all twelve beautifully. So the line had to go one step further — stop asking, and start checking.

Pollen, 2022. A British events-tech company that had raised over $200M, announced another $150M in April 2022, laid off a third of its staff three weeks later, and assured everyone remaining that all was well. Then wages stopped, pension contributions went missing, and US employees' health insurance was cut without notice. On 9 August, Atlassian suspended the company's JIRA over unpaid bills. On 10 August, Pollen collapsed into administration. He spoke with 20 former employees, most of them in technology. And the question he set the piece is not "how did this company fail" but something useful to the reader: could these tech workers have realised sooner that they were on a sinking ship? The answer is buried in signals nobody could read at the time — unknown to most employees, all the external investors had quietly resigned from the board, and when a venture partner described himself as a current board member at a company-wide town hall, documents show he had resigned the previous day. Ten months later the BBC made a documentary out of it, Crashed: $800M Festival Fail.

He is unambiguous about what it cost: the piece created potential legal jeopardy and had to be reviewed by lawyers before publication. His conclusion:

I decided that while I greatly respect investigative reportage, it's not an area I would venture into, again. And I intended to keep this promise.The DevTernity Tech Conference Listed Fake Speakers for Years: I Accidentally Noticed, 2023

I intended to keep this promise. A year later he saw a friend announced as a speaker at the DevTernity conference. He clicked through to look at the lineup; most names were familiar, and one was not: Anna Boyko, core Ethereum contributor, at Coinbase.

His reason for suspicion is specific, and entirely an insider's instinct: there are not many core Ethereum contributors, and someone committed full-time to an open-source crypto platform joining Coinbase at the same time is odd. So he checked. Nothing on LinkedIn. Nothing on Google except the conference itself. Nobody similar among Ethereum's core contributors. He asked friends at Coinbase, who had never heard the name. He looked at the same organiser's other events and found two more people who do not exist; he looked at earlier DevTernity editions and found more. Four fake speakers across four conferences, all of them women.

The clinching evidence came from a hole the organisers left themselves: the conference website is open source, so every change is visible in the commit history. On 3 August 2021 at 5pm GMT, someone publicly criticised the all-male DevTernity 2021 lineup on Twitter. Two hours later, a commit added the first invented woman speaker.

Then the footnote. It is not about DevTernity, it is about the industry:

All this took about 30 minutes of research to find out, including the pinging of contacts at Coinbase and Meta. Other people must have discovered what I did with such little effort, but it seems they said nothing.

That is the argument of the whole line. The DevTernity evidence was entirely public: the website, the commit history, LinkedIn, Twitter. The barrier was thirty minutes. What is scarce is not capability but somebody willing to say it — because saying it costs you something and staying quiet costs you nothing.

Which brings us to the notice at the top of this page. In July 2026 Google delisted the Pollen article over a copyright infringement claim — and he is the only possible copyright holder. He dug up the complaint: it asserted that his 2022 piece Inside Pollen's Collapse had copied a 1998 New York Post article titled Band Leader Hits Winning Chord. His verdict on the comparison is one line: "The two do not even share a single sentence!" The complainant was listed as "Ellie Piee," residing on Bouvet Island — a Norwegian dependency in the South Atlantic, one of the most remote places on Earth, with zero inhabitants.

It seems that anyone can file a bogus copyright claim to get an article they don't like removed from Google's search index.Pollen tried to remove my article…, 2026-07-08

On who was behind it he offers exactly one sentence, explicitly flagged as his own speculation, and otherwise leaves the checkable facts on the page. His sign-off is a dry reminder that Pollen's executives should look up the Streisand effect.

A decade-long project closes here. He started from "engineers can't see what they're worth," moved to "engineers can't see what a company is like inside," and arrived at "somebody is paying to keep engineers from seeing" — and the tooling for that last step is almost comically cheap: a person who doesn't exist, an island where nobody lives, and a form.

How he thinks

Reading someone with a decade of output, the transferable part is usually the method rather than the conclusions. His method has a spine, and he may never have stated it outright: he keeps finding that a practice's real value is not the one it advertises, but a side effect.

Once you see the pattern it is everywhere. The output of a design doc is not the document but the disagreement. The value of broadcasting RFCs is not that everyone reads them (he concedes most don't) but that what an organisation pushes to people shapes its culture. The prettiest instance is in Yes, you should estimate, written against the #noestimates current. He begins by saying he is good at estimating and then delivering on those estimates — and then dismantles himself:

Remember how I said how I'm pretty good at estimating, then delivering on them? I was not telling the truth about delivering. For every major project, we shipped something different on the launch date, than what we agreed to originally.Yes, you should estimate, 2019-10-15

Skype on Xbox One shipped on launch day without group video calling — running alongside games, the platform didn't leave enough CPU to decode more than two streams reliably, so they cut it, and it "made little to no difference" to the launch. His conclusion: the real function of an estimate is not prediction, it is manufacturing time pressure, and time pressure forces tradeoff conversations. Without the estimate, nobody ever asks whether a feature this complex is carrying its business value. So an estimate's worth is largely independent of its accuracy — arguably, it pays off precisely when it turns out to be wrong.

Around that spine, a few habits worth copying.

Trust your own eyes first, then go find data — the order matters. He did not start from a suspicious report and go verify it; he started from a number on his own offer letter that didn't line up, and then went and collected 200 data points. Most people, when first-hand observation conflicts with authoritative aggregate data, assume they are the outlier. He assumed the aggregate had a sampling problem. The transferable rule: when direct observation fights a statistic, ask who the statistic was sampled from — often enough, "the average" is only "the average of the people we could reach."

Always state your position, and be specific enough to be contradicted. "I was a hiring manager at Uber." "I was making £93,000 as a principal at Skyscanner." This isn't just credentialing — it hands the reader a discount rate, so you know from which angle to mark his claims down. And he almost never writes "the pay is high"; he writes €175,000 = €115,000 + €20,000 + €50,000. He doesn't write "Pollen was a mess"; he writes that Atlassian suspended JIRA on 9 August and the company collapsed on 10 August. A vague claim cannot be refuted, which is also why it cannot really be believed. This runs both ways, too: someone who has spent years publishing his own salary and his own mistakes is someone other people are willing to tell things to — his source network was largely bought with self-disclosure.

He doesn't close the argument. In 2025 the METR study found developers using AI tools were 19% slower while believing they were 20% faster. The finding cut against the prevailing narrative; he published it anyway, and laid out everything that weakens it in the same breath: a sample of 16, of whom 44% had never used Cursor, and the single participant with 50+ hours of Cursor experience was 38% faster — "a sample size of one is not very representative of a group of 16." He argues neither for AI nor against it; he hands over the shape of the evidence as it is.

And he lets himself grieve, without offering a way out. January 2026:

It feels like something valuable is being taken away, and suddenly. (…) I wonder if I'll still get the same sense of satisfaction from the fact that writing complicated code is hard?The grief when AI writes most of the code, 2026-01-07

A man whose blog is called The Pragmatic Engineer offers no pragmatic advice in that passage at all. He says he will miss it, and leaves a question mark.

Where he might be wrong

1. The bias he named himself, he named in the small case — and it is worse in the big one. He wrote the selection-bias caveat honestly under the twelve-question results. But the same problem exists in a far heavier form in the trimodal model, and there he didn't write it. The original 200 data points came from Dutch engineers willing to submit their pay to an English-writing hiring manager at Uber; TechPays data is self-submitted; and his million readers are self-selected in one direction — people who already care about compensation, read English, and work at or aspire to international companies. That sample is extremely accurate about tier 3, because tier 3 is where he stands; the tier 1 numbers read more like inference than measurement. And tier 1 is the most populous tier. The model's descriptive power at the top and at the bottom are not in the same league, and the article doesn't flag the difference.

2. It is a descriptive model being used as a prescription, and the prescription's shelf life is tied to one particular decade. "Move toward tier 3" was good advice during zero interest rates and years of rising equity. He wrote the counter-evidence himself in the same piece (Uber's $48 → $45 → $30 → $21), and in 2025 reported that software developer listings on Indeed were 35% below January 2020 and under a third of the mid-2022 peak — a steeper fall than sales, banking or marketing. He reported both sets of facts, but never went back and rebuilt the trimodal framing. It is still read in the register of "the top tier is always there, the only question is whether you can get in" — while his own 2025 data describes an opening that is narrowing.

3. "What Silicon Valley gets right" is the piece that reads worst today. In 2020 he wrote it well: autonomy, internal data transparency, engineers talking directly to the business, each illustrated with concrete dialogue. The problem is that he framed these as a kind of cognitive superiority (these companies "get it") without explaining why any of it would persist. And the densest subject on his blog in the years since has been layoffs, return-to-office mandates and hiring freezes at the very same companies. A colder and more durable explanation is that a good share of that "culture" was a product of a labour market tight enough that companies needed it to keep people. He reported what happened when the market loosened, but never went back to repair the causal claim in the 2020 piece.

4. The investigative line has a structural ceiling, and he has already written it down himself. The Pollen piece exposed him to legal risk; he wrote that it was not an area he would venture into again, and then did. That honesty is rare — but it also exposes the selection rule: a bankrupt events company and a small conference organiser are opponents he can absorb. Whether a company that can field a legal team on demand, and that is also contributing to his subscription revenue, would be equally absorbable is a question his writing has not handled. He does state that he takes no sponsorships, which closes off the most obvious route for capture; but a subscription model transfers the incentive to readers, and his readers are heavily concentrated among senior engineers and engineering leaders. What leaks out of that group, and what leaks out of support staff, contractors and tier 1 engineers, will not arrive in the same volume or point at the same stories. There is a more fundamental tension underneath: his product is an antidote to information asymmetry, while his business requires the asymmetry to persist — the paywalled scoops sell precisely what other people cannot get. He does not pretend otherwise (the Pollen piece and the trimodal piece both ended up on the free side), but handling it gracefully does not make it go away.

Sources

• The Trimodal Nature of Software Engineering Salaries in the Netherlands and Europe (2021-03-08, updated 2025)The primary source for the trimodal model: the definition of the three tiers, the compensation ranges in each, how a senior Uber offer breaks down, and why tier 3 is invisible in public salary data. Links at the end to the 2024 and 2025 follow-ups extending the model to the US, UK and India.
• Software Architecture is Overrated, Clear and Simple Design is Underrated (2019-09-17)One of his most-read posts. How the Uber payments rewrite and Skype on Xbox One were actually designed — no UML, no architects, just boxes and arrows — plus the argument that architecture patterns are tools named after the solution was found.
• Scaling Engineering Teams via RFCs: Writing Things Down (2018-10-03)The full version of the process that "sounds crazy": plan, write it up short, get a few approvals, then mail it to every engineer in the company. Includes the real field lists from Uber's backend and mobile RFC templates.
• The Pragmatic Engineer Test: 12 Questions on Engineering Culture (2021-10-11)All twelve yes/no questions, the loophole each one closes, the distribution of 200 submissions, and the selection-bias caveat he put underneath his own results.
• Inside Pollen's Collapse: "$200M Raised" but Staff Unpaid (2022-10)The long report built from 20 former employees: a dated timeline, the board that quietly resigned, the $3.2M charged early. The BBC made a documentary from it ten months later; in 2026 someone used a forged copyright claim to pull it out of Google's search results.