Last week I wrote about developer experience and how friction quietly burns payroll. There is one moment where that waste is the most brutal and the most invisible at the same time. The first two weeks of a new hire.
Picture the common version. A new developer arrives, gets a laptop, a list of repositories, and a cheerful “let me know if you need anything.” Then they disappear into a swamp. They spend a week fighting the dev environment alone. They read code with no idea why it exists. They are afraid to ask the same question twice, so they guess. Two weeks later they have produced almost nothing, and worse, they have learned that this is a place where you sink or swim. I have watched this happen, and the bill is paid in salary, in slow ramp up, and sometimes in a person who quietly starts looking for the next job before month three.
I do it differently, and I do it on purpose.
A framework I built, then carried with me
I first put this together back when I ran my own company. With my money on the line, a new hire lost for two weeks was not an abstraction, it was a hole in the budget I could feel. So I turned onboarding into a real process instead of a shrug.
Years later, when I became a lead at Benevity, I implemented the same framework on my team, and I shared it with other leaders too. I did not control what every team did, of course. Some adopted it, some did not. And that is the honest part. Not every developer I have worked with looks at onboarding as an operational cost. Many see it as paperwork, or as someone else’s job. This is where my entrepreneur hat shows again. I cannot stop seeing a new salary sitting idle as money leaving the building.
I build the two weeks before they start
As the senior on the team, doing the lead part of the work, I treat the first two weeks like a project with a plan. I write an onboarding agenda, a simple day by day document. And here is the part people skip. Every session in that agenda, I book in the new person’s calendar ahead of time, with the right people already invited. No “we should schedule something.” It is already there on day one, with names and times.
The goal of the whole thing is context. A new developer is not slow because they are weak. They are slow because they have no map. My job in those two weeks is to hand them the map as fast as I safely can.
A few things I always include.
Introduce the person to the team on day one, as a human, not a ticket account. Then we sit together and set up the dev environment, about two hours. That sounds like a lot of my time. It is nothing compared to the one or two weeks I have literally seen people lose trying to get an environment running alone. Two focused hours beats two lonely weeks every time.
I pull the domain expert for a product overview, and I book an architecture review. Not because the new person will remember all of it, but because it draws the borders of the map. Later, when they read the code, they have somewhere to put each piece.
Most afternoons I block pair programming hours, and I mark them optional on purpose. The time is reserved in my calendar so I am available, but the new person only pulls me in when they actually need it. Some days that is the full block, some days it is five minutes, some days nothing at all. This is the heart of it. I am senior and I am close, so the new person is never alone in the dark guessing at answers. A question that would cost them half a day alone costs us five minutes together. And because the block is optional, I am not throwing away my own week on hours that may never be used.
The week one deploy, on purpose
Here is the part that surprises people. From day one, the stated goal is that the new hire ships something to production in the first week. Not a big feature. Usually a small bug that has been sitting in the backlog for months, the kind nobody prioritizes. The point is not the fix. The point is that they walk through the entire pipeline once, with me beside them. Branch, review, CI, CD, the deploy, the checks after. They see the whole road while it is safe and small.
When a person ships to production in their first week, something changes in their head. They stop feeling like a guest and start feeling like an owner. Confidence is not a soft word here. A confident developer asks better questions and makes braver, better decisions.
Give them the right resources, not all of them
I also hand over the resources up front, but only what the team uses. Not the entire company wiki, which would drown them. The architecture diagrams for our domain, the board where the work lives, the environment docs, the place where our real work actually happens. A new person needs to win the team context first. The company context can come later, once they have ground to stand on.
This is also a cognitive load decision, the kind Team Topologies talks about. Handing someone everything is not generosity, it is noise. The right small set of resources is a gift. The whole company at once is a burden.
The math, with my entrepreneur hat on
So is this expensive? Let me count honestly. The fixed part of my time is small, a handful of structured sessions across the two weeks, maybe a dozen hours in total. The pair programming blocks on top of that are optional, reserved but only spent when the new person needs them, so most weeks they cost me far less than the calendar makes it look. That is the whole cost.
Against that, put the default. A new hire lost for two to four weeks, producing little, learning the wrong lesson about how we treat people, and ramping up slowly for months after. I ran my own company for eleven years and signed the checks, so I read this like an owner. A few hours of my time, front loaded, against weeks of a salary producing almost nothing. It is not a close call.
Over the years I have seen the benefits stack up. The knowledge transfer is solid, because it is structured instead of accidental. The new person gains confidence fast, especially after that first production deploy. The onboarding cost drops, because the ramp is short and intentional. The team gets a contributing member in weeks instead of months. The person learns, on day one, that this is a place that invests in them, which is the cheapest retention move I know. And the documents I create live on, so the next new hire starts from an even better place.
The one real cost is my time as the lead. And honestly, with my entrepreneur hat on, I do not even see that as a cost. It is the highest return investment available to me that week. I am turning an expensive, idle new salary into a productive teammate, and I am doing it with hours, not dollars.
The cheapest onboarding is not the one where you leave people alone to save your own time. It is the one where you spend a little of your time early, so the company stops spending a lot of its money slowly.
Pax et bonum.