The Real Cost of a Developer's First Month

The real cost of a developer's first month is not the salary you pay them. It is the salary you pay them plus the hours other people stop doing their own work. Reviewer time, pair sessions, environment setup, questions answered in the middle of someone else's focus block: all of that is paid for out of existing headcount, and none of it appears on the hiring budget.

Here is the short version. A new developer's first month costs roughly one salary plus a meaningful slice of two or three other salaries. If you plan as though it costs one, you will be surprised twice: once when nothing ships that month, and again when the rest of the team's output is lower too.

The four costs nobody puts in the plan

Reviewer time

Every pull request from a new person takes longer to review than one from someone who has been there a year. The reviewer is not just checking the code. They are checking whether the person understood the problem, whether they followed conventions nobody wrote down, and whether the approach will cause trouble later. That is slow work, and it usually falls on your most senior person, whose time is your most expensive.

Pair and shadow hours

Some of the fastest onboarding happens sitting next to someone. It is also the most expensive kind of teaching, because two people produce one person's output. Worth doing. Just count it.

Environment and access setup

Getting a laptop working, accounts created, permissions granted, a local build running against real data. This is rarely one person's job, which is why it drags. It is usually a bit of IT, a bit of the team lead, a bit of whoever knows the one undocumented step. The elapsed time is days. The person-hours are lower, but the blocked time in between is real. Someone relocating for the job has a second setup running alongside it, with visas, housing and a bank account in the same fortnight.

The output dip across the team

This is the one people miss. When a new person joins, everyone near them slows down. Interruptions break focus. Explaining something takes ten minutes and then twenty more to get back into what you were doing. The dip is small per person and adds up across a team.

How to count it without pretending to be precise

You do not need a fancy model. You need an honest estimate written down before you hire, so nobody is shocked later.

• Estimate hours per week the reviewer will spend on the new person's work, for the first four weeks
• Estimate pair or shadow hours, and note who is giving them up
• Estimate setup hours, split by who does what
• Add a rough interruption cost for everyone sitting near the new person
• Convert to a share of a salary, not to a rupee or dirham figure you cannot defend

The point of writing it down is not accuracy. It is that the number stops being invisible. A team lead who has seen the estimate makes different choices about when to hire and how many people to start at once.

Why two starters at once is not twice the cost

It is usually more. Two people joining in the same week share nothing except the calendar. They ask different questions at different times, they break different parts of the setup, and the same senior person answers both. The reviewer load roughly doubles while their own capacity stays flat.

If you can stagger starts by two or three weeks, do. The first person becomes a partial answer to the second person's questions, which is the cheapest onboarding there is. Staggering is easier to arrange once you have done the notice period maths for each offer.

The part that is easy to fix

Most of the setup cost is avoidable and most teams keep paying it anyway. The undocumented step that blocks a new laptop for a day is the same step that blocked the last three people. Nobody writes it down because by the time you know it, you no longer need it.

A small habit fixes this: the new person writes the setup notes as they go, and the next person corrects them. It costs almost nothing, and the notes are accurate because they were written by someone who did not already know the answers.

What this means for planning

If a role opens in a quarter where the team already has a hard deadline, hiring into it will make that deadline harder, not easier, for at least six weeks. That is not a reason to avoid hiring, though it is a reason to check whether you could resequence the work instead. It is a reason to say so out loud when the plan is written, so the deadline moves or the scope does.

The cost of a first month is real work done by people who are not the new hire. Count it, name it, and give it to someone as an actual task rather than a thing that happens to them.

Tools help at the edges. Something like SicherOne, which keeps project records and people records together, at least makes it visible when a team lead is already carrying two other things in the week a new person starts. The judgement stays with the manager. The visibility should not be optional.