Read Your Team the Way a Senior Candidate Will

Senior engineers assess the team as carefully as the team assesses them. In our conversations with candidates the questions are consistent: what will I actually build, how hands-on is this, is it building something new or scaling something that exists, and how deep is the team I would be joining. Most of those can be answered from outside if you know what to look at, and good candidates do.

Founders tend to think about this only from the candidate's side. The more useful exercise is the reverse. Read your own team the way a sharp candidate will, and fix what you find before it costs you a hire or a resignation.

What a senior candidate looks at

• Who they would be working with. Whether they would be the most senior engineer in the room, and if so whether anyone would stretch them. Strong people want to learn from someone.
• Who left recently. A run of departures from one team is visible on LinkedIn in about a minute, and it is the first thing a careful candidate checks.
• Titles against scope. A team where everyone is "senior" but nobody owns anything reads as title inflation, and it tells a candidate the next promotion will be hard to earn.
• How honest the role description is. Whether "hands-on" means hands-on, and whether the work is really new or the maintenance of something someone else built.
• What the offer implies about everyone else. Candidates compare notes, and a new hire learns the pay shape of a team within weeks of joining.

That last one is where most founders are caught out, because it works in both directions.

Your next offer is a message to your current team

When you hire a senior engineer at the market rate, you are also publishing, eventually, what the market rate is. If your existing senior engineers are paid well below it, they will find out, usually from the new hire, and usually at the worst moment.

This is the most common self-inflicted retention problem we see. The search goes well, the new person is excellent, and three months later one of the people who has been there longest resigns. Nobody connected the two, because the offer was a hiring decision and the pay gap was never looked at as a whole.

A new hire at market rate tells everyone paid below it exactly how far below it they are.

Reading the team the way the market will

The fix is to look at the whole team against the published bands before you make the offer, not one role at a time after it. Take a senior software engineer in Sydney, where the band is AUD 160-190k. The team benchmark reads each person against their band and flags four situations, each with a reason you could say out loud in a pay review:

• More than 10 per cent below the floor. For this band, anyone under 144k. High risk: this is the gap a competing offer closes in one move.
• Below the floor. Between 144k and 160k. Elevated risk: any market check they run will show it.
• In the bottom quarter of the band. From 160k up to 167.5k. Worth watching: in band, but with nothing in reserve.
• Above the band. Over 190k. No risk flag. Worth knowing when you set the next increase.

Now put the new hire in. If you offer 180k to bring in a strong senior engineer, everyone on the team below 167.5k has just been told something. The time to address it is before the offer goes out, when a correction looks like good management rather than a reaction to a resignation.

What the benchmark does not see

Base salary is one input. Retention in practice turns as much on the manager, the work and the equity as it does on base, and a tool that reads only base cannot see any of those. So treat a flag as a prompt to have a conversation, not a prediction that someone is about to leave. The benchmark states its rules in full for exactly that reason: you should be able to explain every flag to the person it is about.

It also benchmarks within one currency at a time, because nothing on this site converts between currencies. A team split across Sydney and London is two reads, not one.

Your payroll stays in your browser

Reading a team means entering what real people are paid, so how the tool handles that data matters more than anything it calculates. The team benchmark computes entirely in your browser. What you enter is never sent anywhere: the tool itself makes no network request, and there is no email gate on the result. The page records a visit through the site's analytics if you accept cookies, but never the figures you type. That is a deliberate constraint on how the tool is built, not a setting.

If you would rather check one person at a time, am I underpaid does the same comparison for a single role, and the salary checker has every band.

FAQ

How do I know if my engineering team is underpaid?

Compare each person against the published band for their discipline, level and city, and look at where they sit within it. Anyone below the band floor is exposed to a competing offer, and anyone more than 10 per cent below it is at high risk because one offer closes the gap. Being in the bottom quarter of the band is worth watching even though it is technically in band.

Will hiring a new engineer at market rate affect my existing team?

Often, yes. A new hire paid at market rate eventually reveals the market rate to colleagues, and anyone paid well below it learns how far below. This is a common cause of resignations a few months after a successful hire. Checking the whole team against the bands before making the offer lets you correct gaps before they become a reason to leave.

Is it safe to enter salary data into a team benchmark tool?

It depends entirely on the tool. The Re:Sourced team benchmark calculates everything in the browser and never sends the figures you enter: the tool makes no network request and there is no email gate on the result. Site analytics can record the page visit, but not the salaries typed into it. Before entering payroll into any tool, check whether it uploads the data and what happens to it.

What does a pay benchmark not tell you?

It reads base salary only. Retention depends as much on the manager, the work and the equity, none of which a base-salary comparison can see. A flag is a prompt for a conversation rather than a prediction that someone will leave.