Why Engineers With the Same Resume Earn Different Salaries
The skills, habits and choices of high-performing product engineers — and what you can do to become one.
Two engineers. Same college. Same eight years of experience. Same “Spring Boot” on the resume.
One earns three times more than the other.
People usually say it is luck. Or the company brand. Or better negotiation. The real reason is simpler. The two companies make money in different ways. And the way a company makes money decides how much it can pay you.
Put simply: your pay is not based on the skills on your resume. It is based on the most valuable work your company builds with your skills — and sells to its customers.
This article puts two ideas together:
- How engineers think. From our earlier post, Programmer, Software Engineer, Product Engineer: three engineers can use the same framework but understand it at three different levels. The difference is the question each one asks.
- How teams work. From The Pivot Model: the teams that build a product also work at three levels, from “follow instructions” to “partner to the business”.
Put the two together, and salary differences start to make sense.
Who this is for
This article is for engineers who build software products. You write code — today, usually with tools like Claude, Cursor and other coding agents. And the product you build either has AI features, or is AI-native — built around AI from the start.
Many of you work in offshore or outsourced teams — at a vendor, or at a global capability centre (GCC) — building products for companies in other countries. This article will help you see where your team stands, and where you stand.
builds = "products",
codesWith = {"Claude", "Cursor", "agents"},
ships = "AI features" | "AI-native"
) // if this is you, read on
The Pivot Model book covers three things: the three levels a team can work at, the technical skills a product engineer needs, and product mindset — thinking about the product, not just the code. Readers of the book sent me questions. I answer them here. Where the book already explains something in detail, I point you there instead of repeating it.
Three questions software engineers ask
A quick recap of the earlier article. These are ways of thinking, not job titles.
The Programmer asks: “What do I write here?” They follow the existing pattern and make the code work. When something breaks in a new way, they search online, copy a fix, and move on.
The Software Engineer asks: “What problem was this built to solve?” They know why dependency injection exists. They know how Spring uses a proxy to make @Transactional work. They fix problems because they understand the cause, not because they found an answer online.
The Product Engineer asks: “Will this still work after a year in production? And should we build this at all?” They think about the live system, the customer, and how much each request costs to run. For them, a bug can lead to a design change — or even a change in what the product does.
Everyone starts with the first question. That is normal. The problem is staying there for years.
Two things move you up. In-depth technical expertise takes you from the first question to the second. A product mindset takes you from the second to the third.
Step 1: Develop in-depth technical expertise
The Pivot Model book explains in detail what technical skill means for a product engineer — far beyond programming. Use the book as your guide, and build the skill through practice. Certificates do not give you good judgement. Practice does.
What separates a good programmer from an average one is mostly one thing: how much real, hands-on coding they have done. Practice changes how you think. It helps you write code that works under heavy load from day one — not code that works on your laptop and fails in production.
This matters even more now that AI writes code. A coding agent can give you ten solutions in a minute, and even explain how each one will perform. But you can only trust that explanation if your own experience lets you check it. Only an engineer who has written, broken and fixed real systems can tell when the agent is right — and when it only sounds right. The agent types faster than you. You still decide whether the code is right.
Step 2: Develop a product mindset
The Product Engineer’s question — “should we build this at all?” — is product mindset. It means you care about why the product exists, you work toward the product’s goals, and you take responsibility from the first idea to long after release — not only for the part where you write code. The book covers this in detail:
- knowledge of the business domain
- understanding the customer’s problem
- the product roadmap
- the product lifecycle
- working with customers
You learn far more this way than by only writing code. Yet fewer engineers than you would expect are willing to take this responsibility. Most prefer clear, simple tasks.
Three levels of engineering maturity
The Pivot Model describes these levels from the point of view of a product company’s management — how they see the team that builds their product.
L1 Execution Layer. Management sees the team as people who do tasks. The product company decides what to build. Work goes to the team as tickets and comes back as finished tickets.
L2 Engineering Ownership. Management trusts the team with the quality of its own work. The team raises problems early, finds its own bugs, and starts to have a say in what gets built.
L3 Strategic Partnership. Management trusts the team with end-to-end ownership of the product — from managing the roadmap, to working with customers, to growing the product’s revenue. The team understands the business numbers — revenue, cost, growth — and suggests ideas. It does not just run and maintain systems. It helps decide what the business builds next.
A note on where each level is found.
- L1 is almost always an outsourced or offshore team — a vendor, or a product company’s own offshore centre (GCC). The main reason is to reduce operational cost.
- L2 is found in two places: in offshore teams that have earned more trust, and in the product company’s own teams — often in large product companies, where detailed process and many layers of management decide what gets built.
- L3 is found in product startups, in strong in-house teams, and in offshore teams that have earned the product company’s full trust.
The Pivot Model is the path for a team to move from L1 to L3.
One more note. These L1/L2/L3 labels describe how a product company sees and uses a team. They are not job titles or HR grades. This is not “Google L4”. A fresher can work in an L3 team. A twenty-year veteran can work in an L1 team.
The two lists match almost one to one. That is not an accident. A team’s level is the deepest question its engineers are expected — and allowed — to ask. In an L1 team, “what do I write here?” is the whole job. In an L3 team, “should we build this?” comes up in every design discussion, and everyone is expected to give an opinion.
A level chosen by the business
@Engineer(level = "personal choice") // not fixed for life
Here is the part most people miss.
The level a team works at is a business decision, made by the product company. It does not show how good the team’s people are. It depends on practical things: how much the product company trusts the team, how critical the product is, the rules it must follow, the skills the team has, and cost.
Take a large retailer. It may give the upkeep of its old store systems to an offshore vendor, to be done reliably at the lowest cost. For that work, L1 is the right choice. That is not a weakness. The same retailer may ask its own offshore centre to build a new mobile app — and expect L3 ownership from that team. Many product companies mix levels on purpose: L1 work to keep core systems running at low cost, and L2 or L3 work for new products. A forty-person product startup is different. It usually keeps its engineering in-house and cannot afford anyone who waits to be told what to do. Almost every role there is an L3 role.
In India you can see all three every day. Offshore teams that run and maintain systems for overseas companies at the lowest cost. Global capability centres (GCCs) moving from L1 toward L2 and L3. Product startups whose own teams work at L3 from day one because they have no other option.
So no level is wrong. A level is only wrong if it does not fit what the business needs.
And company size does not decide the level. Many large product companies run L3 teams at scale and pay very well. Some small software firms take only outsourced L1 ticket work.
What this means for your learning
But the level you work at decides what you learn. So choose your manager and your company based on what you want from your career.
Large companies avoid depending on any one person. They use detailed processes and many layers of management, so the work continues even if someone leaves. That makes business sense. The side effect is that many engineers never get a real chance to learn. We recently interviewed candidates who had been laid off by a large multinational. Many had much less hands-on experience than their years suggested — not because they lacked ability, but because their jobs never asked them to own anything.
Smaller companies give you responsibilities. They are more likely to give you a responsibility than a task. That builds technical judgement, communication, and the habit of setting your own priorities. The biggest gain is confidence. “I finished the task I was given” and “I delivered what I was responsible for” feel very different. The second kind of confidence stays with you.
Smaller companies have their own problems too. Both have pros and cons, and that is a topic for another day. Weigh them for your own life — but do it consciously.
And here is the key point. The level of work your team is given decides how much money your company earns from each engineer. And the way a company makes money sets the upper limit on what it can pay you.
How each level makes money
L1 L1 work is valued for keeping costs low. The product company sends L1 work offshore to reduce operational cost. It measures the offshore team by cost per engineer and on-time delivery, so salaries are kept within that cost budget. The hard truth: in a pure L1 setup, the budget usually does not grow just because you are more skilled. You can be brilliant, but your company has no way to turn your extra skill into more money. The limit is not your skill. It is what the product company wants from L1 work: lower cost.
L2 L2 work is valued for results. Better quality, faster delivery, fewer outages. Now your skill shows up directly in the results the product company sees: bugs fixed faster, fewer production problems, code that is easy to change. Two more skills become valuable here. Domain knowledge — you understand banking, logistics or healthcare, not just the framework. And turning business requests into clear requirements — when a manager says “we need a faster checkout”, you can turn that into specific work the team can build, without ten rounds of back-and-forth. The product company can see your skill in its results, so it has a reason to pay more for it — whether you are in its own team or in an offshore team.
L3 L3 work is valued for what the product earns. A successful product company can earn far more from each engineer’s work than it costs to employ them. And it earns from exactly what a Product Engineer does: not building the wrong feature, keeping running costs low, and shipping features that bring in more revenue. Here, pay is not about keeping cost low. It is about the business results you create. The top salaries here look unbelievable from inside an L1 team. They make sense when the company pays for business results, not for keeping costs low.
An example: one feature, three levels
Here is a simple example. Take one payment integration, built by three different teams:
L1 Builds the payment-integration ticket exactly as written. Done when the ticket is closed.
L2 Builds it so it does not fail in production: retries, no duplicate payments (idempotency), monitoring, clear error handling. Done when payment failures go down and the integration is easy to support.
L3 First asks which merchant problem this solves, and whether it will increase sales or reduce cost. Then builds the smallest version that improves that number. Done when the business result shows up.
Same feature. Same framework. Three very different things the company is selling — and three very different things the teams are paid to do.
In one line: L2 makes sure the feature works well. L3 makes sure the feature is the best among competing products — and gives the most value to end users.
As a simple example (not a rule): if an L1 role pays X, an L2 role may support 2 to 3 times X, and an L3 role 5 times X or more. Same resume. Same year. Same city. Your own salary will not match these numbers exactly — company size, cash versus stock options, and negotiation all change it. But how the company makes money sets the upper limit.
This gives us one rule of thumb that explains most salary confusion:
Your salary is set by the lowest of three things: your skill level, your team’s level, and your company’s level.
A Product Engineer in an offshore team that only gets L1 work still gets L1 pay, because the company has no way to earn more from your extra skill. A Programmer hired into an L3 team will not keep L3 pay for long unless they grow. Companies pay for the right fit between you, your team and the company — not for your skill alone.
This is why moving to a product company — or to an offshore team that does L3 work — often brings a big salary jump. It is not luck. The level of work changed, so the limit changed.
It also shows a career move most engineers forget. Sometimes the best next step is not learning more of a framework. It is moving to a team — or a company — that works at the level you are ready for.
What each level gives you, and what it costs
For the product company, the level is a business decision. For you, it is a personal choice. And every choice has a cost.
L1 gives you stability. Lower pay, yes. But clear direction, proven ways of working, and support from the team. The work can still be complex and need deep domain skill. What it gives you less of is the chance to make your own decisions. For many people, at many stages of life, this is a perfectly sensible choice. Nothing in this article says otherwise.
L3 gives you growth — and it costs you two things.
L3 is not the “best” level. At L3, you give up a clear, predictable path. In return, you get ownership, faster learning, and possibly higher pay. It is right for some people and some stages of life — not for everyone.
The first cost is hard learning. At L3, nobody gives you a clear specification. You do not learn from code review comments. You learn from production failures, lost customers, and numbers that refuse to improve. You learn fast because the consequences are real.
Experience grows your value — and interviewers can see it
This is where many careers quietly get stuck. Your growth depends on the experience you gain on the job. The production issues you debug. The design decisions you argue for. The unclear problems you take all the way to delivery. This experience grows every year, like savings that earn interest, and it has a big effect on every salary after your first. If you avoid unclear work, you stop growing it.
Lots of hands-on work brings one extra benefit: original thinking. It comes from confidence, and that confidence comes only from your own experience. I hire engineers for my own teams, and this is exactly what I look for. In my interviews, I ask technical questions they will not find in any interview-prep book — questions you can only answer from real-world experience. To an engineer who has worked hands-on with real systems, the question feels familiar, and they start thinking out loud. To someone who has not, it sounds completely unfamiliar. I am looking for clear, step-by-step thinking about how systems work, and ideas of their own — not a memorised answer.
The second cost: the courage to face the unknown
The second cost is mental strength. At L3, this may be the most important strength of all. But be clear about what this means. You are not born with it. You build it, one difficult decision at a time. And choosing stability does not mean you are weaker. It is simply a different choice.
You will often see two working styles. The first kind needs to know every step before starting a task. The second kind will promise to deliver a module by next Tuesday — even when there is no clear way to get there. They take the risk. They learn what they need along the way. And they are determined to prove they can deliver on their responsibility.
This is not about long hours. Long hours are easy to see and easy to fake. It is about the mental strength to do work nobody has done before. At L3 you promise to deliver a product with many unknowns and no clear plan, and you take real risk. Your guesses about the customer turn out wrong. Requirements change midway. Technical choices fail. You make decisions with only 60% of the information, knowing you may be proved wrong in a few days. You are wrong in front of others. And you make the next decision with your confidence still intact.
What helps you through is a simple combination. The mental strength to face the unknown. A willingness to experiment — try something, measure it, learn, try again. And real care for two groups of people. Care for the end user, so you build what actually solves their problem. And care for the investor, because every experiment spends someone’s money and someone’s trust. A Product Engineer respects the user’s time and the investor’s money equally. That is what separates a smart risk from a careless one.
This is why fewer engineers work at L3 than you might expect, even though everyone knows the pay is higher. If the gap were only knowledge, many would close it. It is not only a knowledge gap. It is a strength you build by handling real uncertainty. Books can help, but only real responsibility builds it fully. The extra pay at L3 is not only for rare skill. It is for the rare ability to stay calm and keep working when nothing is certain.
So before chasing L3, the honest question is not only “can I do the work?” It is also “can I sleep well while the outcome is uncertain?”
Not all uncertainty is L3
Be careful here, especially early in your career. There are two kinds of uncertainty, and only one is worth the cost.
Good uncertainty comes from the problem itself: a new market, a new product idea, a customer problem nobody has solved yet. It also comes from the technology: a machine learning model whose results you cannot fully predict, or a new technology that nobody on the team has used before. The unknowns are real, but the people around you are working hard to answer them.
Bad management comes from the company itself: priorities that change for no reason, managers you can never reach, deadlines nobody believes, old code problems nobody is allowed to fix. That is not L3. It is just chaos, and you learn very little from it.
Before you accept uncertainty, ask where it comes from. The first kind helps you grow. The second kind only tires you out.
This matters most when you judge a job offer. Say a company offers you 40% more to work on a new product with unclear requirements. The extra pay is not for your Spring Boot skills. It is for handling uncertainty. If you can handle that at this stage of your life, the offer is a good deal. If you cannot, no salary will make it worth it.
And choosing not to work at L3 is a valid choice, not a failure. Some excellent engineers do their best work with clear instructions, and good companies need them. The real mistake is wanting L3 pay while avoiding L3 difficulty — wanting fast growth without hard learning. Only you can fix that gap.
Train yourself. Use companies to practise.
Here is how I see skill development.
Your learning is your own responsibility. Focus on the areas that interest you, and teach yourself. This does not depend on any company. Do not wait for your employer’s training plan to decide what you learn.
A company is where you practise. See each company as a chance to practise what you have learnt — in real situations, with real users, real traffic and real deadlines. A company also gives you all-round professional growth that goes beyond technical skill: working in a team, explaining your ideas to managers and customers, handling pressure, and taking responsibility for results. You learn on your own time. You practise and grow on the job. You need both.
When you are starting out, salary should be your smallest concern. Choose the company that gives you the most chance to practise what you have learnt. Your first job is where your practice starts. The practice you get has a big effect on every salary after it.
Your ambition decides how much responsibility you want. If you want responsibilities instead of tasks, you will usually get them sooner in a smaller company. And a smaller company means fewer of the comforts, benefits and big brand name that large companies offer.
One honest note. Small companies depend on the skills of their people, not on detailed processes. So you are often given real responsibility early — sometimes in your first year. But small companies also carry more risk: stock options may never turn into money, and the company may shut down.
Large companies depend on process, so responsibility usually comes later. You first have to prove yourself — often for a few years — before you are trusted to own something important. And those roles are fewer and harder to get.
That is the trade-off. There is no single right answer. It is a choice each person needs to make carefully — based on their stage of life, their family, and their goals.
How to grow to the next level
- Find where you stand. Which question do you usually ask? What level is your team at? What level of work does your company get? Your salary sits at the lowest of the three. Find that one first.
- Build deeper skill — through practice, not certificates. Learn why something works, not just how to use it. When a framework surprises you, read its source code. Check the code your AI agent writes instead of just accepting it.
- Ask for one unclear problem every quarter. A responsibility, not a task. Most companies that do L1 work also have some L2 and L3 work. This is how you get L3 experience in small, safe steps.
- Practise deciding with 60% of the information. Start with small decisions. Decide, write down why, and check later. Learn the difference between “it turned out badly” and “it was a bad decision”.
- When you stop growing, change your team or company. More courses will not help if your company does not need your level. Before you accept an offer, ask:
- How much of the work is unclear?
- What can engineers decide without approval?
- Do engineers ever talk to customers?
- What happened when the last big bet failed?
What I look for in a candidate
Put it all together and you get the list I actually use when I hire product engineers. If you are a candidate, read it the other way: it is your practice plan.
- Proof of practice. Not certificates. What have you built? What broke under load, and how did you fix it? Can you check the code your AI agent wrote, or do you only accept it?
- Thinking on a real-world technical question. Does it feel familiar or unfamiliar? Do you work through it step by step? Is the idea your own, or a memorised answer?
- Responsibilities in your history, not just tasks. Tell me about something you owned from start to finish — including the parts that went wrong.
- Signs of product mindset. Do you know why your last product existed, who its customers were, and what happened to your feature after it was released?
- Courage. Tell me about a time you promised to deliver something before you knew how to do it. What did you learn along the way?
The same rule, from the company’s side
If you lead an offshore team and your best engineers keep leaving for product companies, it is not because they are disloyal. It is because your company cannot pay for what they are able to do — the work you get from the product company does not use it. Four places to start:
- Listen to your design reviews. Which question do people ask most — “what do I write?” or “should we build this?” That tells you your real level, whatever your presentations say.
- Measure results, not tickets. Engineers start owning their work when you measure speed, reliability and product numbers — not how many tickets they closed.
- Start small L3 teams. A small team with developers, testers and a product person. A truly unclear problem. A real customer number to improve. Other teams learn from working examples, not from instructions.
- Pay for the level you expect. If you expect L3 ownership but pay L1 salaries, your good engineers will leave, one by one.
The Pivot Model is a guide for this journey. Moving a team from L1 toward L3 — earning more trust from the product company, step by step — is what lets your company afford to keep its best people.
Choose on purpose
Skill decides what you can do. Attitude — the question you usually ask — decides what you actually do. Your team’s level decides whether you get rewarded for it. Your company’s level decides how much it can afford to pay you for it.
Salary is not a mark for your talent. It shows how well you, your team and your company fit together.
And with AI, coding agents write more of the code every month. That does not make product engineers less needed. It means the rest of the job — judgement from practice, original thinking, ownership, product mindset and courage — decides who gets hired, and who gets paid well.
Product companies choose the level of work they give a team, for their business. You choose your level for your life. Just make sure you chose it — and did not end up there by accident.
Whatever level you are at today, you now know what each level gives and what it costs. Choose on purpose.
A follow-up to Programmer, Software Engineer, Product Engineer (Pivotrics blog) · Framework: The Pivot Model — four pivots, three levels, one transformation.