We Almost Lost Our Best Hire on Day Nine
I need to tell you about Rami. He was the most talented frontend developer we'd interviewed in six months. Great portfolio, sharp in the technical interview, enthusiastic about the work. We made him an offer on a Friday, he accepted on Monday, and he started two weeks later.
Nine days after his first day, he almost quit.
Not because the pay was wrong. Not because the team was toxic. He almost quit because we had absolutely no idea how to onboard someone. His first day, his manager was on a client call until 2 PM. Nobody had set up his accounts. The laptop we ordered hadn't arrived yet, so he used a spare one that still had the previous employee's wallpaper and bookmarks. Nobody introduced him to the team formally. He sat at a desk and read our website for three hours.
Day two was marginally better. His manager walked him through one project for about 45 minutes, said "just ask if you need anything," and went back to his own deadlines. Rami didn't want to bother anyone because everyone looked busy. So he sat there. For days.
By day nine, he told a colleague he was thinking about going back to his old job. That colleague told me. I bought Rami a coffee, apologized, and spent two hours personally walking him through everything. He stayed. He's now one of our team leads. But we got lucky, and I knew we couldn't keep getting lucky.
The Problem Is That Nobody Owns Onboarding
Here's what I've learned after onboarding 30+ people over four years: the reason onboarding fails at growing agencies isn't a lack of good intentions. Everyone wants the new person to succeed. The problem is that nobody has specifically been given the job of making sure onboarding actually happens.
At a five-person company, onboarding is natural. You sit next to the founder, you absorb context through proximity, and within a week you know everything because there isn't that much to know. At 15 people, that breaks down completely. There's too much institutional knowledge scattered across too many heads, and the assumption that "they'll figure it out" stops working.
I've seen this at other agencies too. You hire someone, you're excited, and then the reality of your existing workload hits. The new hire's first week collides with a client deadline, a proposal due date, or just the regular chaos of running a service business. Onboarding gets pushed to "when things calm down." Things never calm down.
What a Good First Week Actually Looks Like
After the Rami incident, I built a first-week structure. It's not fancy. It fits on one page. But having it written down changed everything.
Day one is about logistics and comfort, not productivity. I don't expect any real work on day one. The goals are simple: the new hire has a working laptop, access to all the tools they need, a clean desk or workspace, and has met every person on the team face to face. We do a team lunch. Nothing long, just enough so the new person has had a real conversation with at least a few people.
I also assign a "buddy" on day one. Not their manager. A peer. Someone who's been here about six months to a year, long enough to know the ropes but recent enough to remember what it's like being new. The buddy's job is to be the person you can ask stupid questions to without feeling embarrassed. "Where's the bathroom?" "What time do people actually leave?" "Is it okay to message the CEO directly?" Those questions matter more than people think.
Days two and three are about context. This is where you explain the business. Not just "here's what we do" but "here's how we do it." I walk new hires through three or four recent projects, start to finish. I show them the proposal, the project plan, the communication with the client, the invoices. I want them to see a complete lifecycle so they understand how their work fits into the bigger picture.
I'll be honest, I resisted doing this at first. It felt like a waste of time. Why spend two days explaining things when they could be writing code or designing screens? Because a developer who understands why the client wanted something builds better solutions than one who just follows a spec. Every single time.
Days four and five are about meaningful work. Not busy work. Not "read the documentation" (we'll get to documentation in a minute). Actual work on an actual project, but with training wheels. I pair them with a senior team member on a task that matters but isn't urgent. Something where there's room to ask questions, make small mistakes, and learn without the pressure of a looming client deadline.
The Shadowing vs. Drowning Spectrum
Most agencies I've talked to fall into one of two traps. They either over-train or under-train, and both are bad.
Under-training looks like what happened to Rami. You throw someone in and hope they swim. It feels efficient because you're not "wasting" senior people's time on training. But the hidden cost is enormous. The new hire makes avoidable mistakes. They develop bad habits because nobody corrected them early. They feel disconnected from the team. And in the worst case, they leave, and you've lost all the time and money you spent recruiting them.
Over-training is the opposite problem, and it's sneakier. I worked with an agency that had new hires shadow senior team members for their entire first month. Four weeks of watching. Sitting in on calls. Reviewing documents. No real contribution. By week three, the new hire was bored, restless, and starting to wonder if the company actually needed them. Over-training signals a lack of trust. It says, "We don't think you're capable yet." For experienced hires, that's insulting. For junior hires, it kills their motivation.
The sweet spot, and this took me a while to figure out, is progressive responsibility. Short shadowing (two or three days), then supervised doing (one to two weeks), then independent work with check-ins. The timeline varies by role and seniority, but the principle is the same. Move people from watching to doing as quickly as you responsibly can.
Documentation That Actually Helps (and the Kind That Doesn't)
After the Rami situation, my first instinct was to create a massive onboarding document. I spent an entire weekend writing a 40-page guide. It covered our tech stack, our processes, our client communication standards, our code review guidelines, our project management methodology, our invoicing process, everything.
Nobody read it. Not once. Not a single new hire made it past page five.
Here's what I learned: comprehensive documentation is for reference, not for onboarding. When you're new, a 40-page document isn't helpful. It's overwhelming. You don't have the context to understand half of it, and you won't remember the half you do understand.
What actually works is short, specific documents tied to the moment they're needed. A one-page checklist for setting up your development environment, handed to the new hire when they sit down at their laptop. A two-page overview of how we structure projects, shared on day two before the project walkthrough. A half-page guide on our Git branching strategy, given when they're about to make their first commit.
We now have about 15 of these small docs. Each one is less than two pages. They get updated regularly because they're small enough that updating them isn't a big project. And new hires actually use them because they arrive at the right moment.
The Mistakes I Still See Agencies Making
Not introducing the new hire to clients. If someone is going to work on a client's project, introduce them. A quick email. A brief appearance on the next call. "This is Rami, he'll be joining the project." It takes two minutes and it makes the new hire feel like a real member of the team, not a ghost in the background.
Waiting too long for feedback. Don't save all your feedback for a "30-day review." By day 30, bad habits are already forming. Check in at the end of week one. Have a real conversation. "How are you finding things? What's confusing? What do you need that you don't have?" This isn't a performance review. It's a temperature check. Every new hire I've done this with has told me something useful that I wouldn't have known otherwise.
Assuming tools are intuitive. Just because your team has been using your project management tool for two years doesn't mean a new hire will figure it out in an afternoon. Walk them through it. Show them how your team actually uses it, not just the features. Where do we track hours? How do we update project status? Where do notes about client preferences live? The tool isn't the hard part. Your team's specific workflow inside the tool is the hard part.
Ignoring the social side. People don't quit jobs. They quit situations where they feel disconnected. For remote or hybrid teams, this is especially important. Make sure the new hire has actual human interactions in their first week. Not just Slack messages. Video calls, pair programming sessions, virtual coffee. The work stuff is important, but feeling like you belong somewhere is what makes people stay.
What Good Onboarding Actually Gets You
I tracked our numbers before and after implementing a real onboarding process. The results were clear enough that I stopped questioning whether the time investment was worth it.
Time to first meaningful contribution dropped from about three weeks to one week. That alone paid for everything. If you're paying someone a salary and they're not productive for three weeks instead of one, that's two weeks of salary you're essentially burning.
New hire retention at the six-month mark went from about 70% to over 90%. Recruiting is expensive. Every person who leaves in their first six months costs you somewhere between 50% and 150% of their annual salary in recruiting, lost productivity, and training for their replacement.
Our existing team got happier too. Before, every new hire created chaos. Senior people had to pick up slack, answer random questions, fix mistakes that could have been prevented. Now, onboarding is predictable. People know what to expect. The buddy system means the load is shared and no one person is overwhelmed.
It's not glamorous work. Building an onboarding checklist doesn't feel as exciting as landing a new client or shipping a feature. But it might be the highest-leverage thing I've done for the business. Every person who joins and stays and thrives is proof that the 20 hours I spent building this system was worth it. And every time I remember Rami almost walking out on day nine, I'm grateful I finally took it seriously.
