What Happens When a Developer Isn’t Working Out

Over 95 percent of the people we hire work out fine. This post is about the rest.

Every year a few of our engineers end up on a performance plan, and a handful eventually leave over it. That is my honest estimate and I would rather write it down than let you assume it is zero, because no company staffing 300 plus engineers has a zero.

The part nobody talks about is the first question we ask when a client tells us somebody is struggling. We start by asking whether the person is on the right team, well before we ask whether they are good enough.

Most of the time it is a matching problem

We have had the same engineer struggle badly on one account and then move to another and be treated as the hero of the team within a month. Same person, same skills, same work ethic.

The difference was the work.

One client is effectively trying to send rockets to Mars. The next one needs a reliable internal application maintained and shipped without drama. Those two jobs demand different people, and being wrong for the first says almost nothing about being wrong for the second.

Not every team needs a rock star. Plenty of good engineering work is maintenance, steady feature delivery, keeping an internal tool healthy for the people who depend on it. Somebody who is genuinely excellent at that is worth keeping, and putting them on a research-grade greenfield project would be doing them harm.

I want to be careful here, because this argument can be used as a hiding place. It does not mean we want below-average people on our team, and it is not an excuse for weak engineers. We turn down more than 97 percent of applicants, which is the subject of how we interview developers. It means the matching part is real work, and when we skip it we get exactly what we deserve.

A note from our own system that says it better than I can

Every time a developer comes off an account, somebody records the reason. The categories are blunt by necessity, so one of them is just “Performance.”

Here is a note one of our managers attached to that category, word for word:

> “Reason = Performance is a little harsh. He was there for a year and received positive reviews. More of a speed thing than performance.”

That is the entire problem in three sentences. The label was the bluntest one available and it was not really true. The engineer had shipped for a year with good reviews. The mismatch was pace, on that team, on that codebase.

If we had read the category and stopped there, we would have drawn the wrong conclusion about a perfectly good engineer. We keep the notes for exactly this reason.

When somebody does need to improve, it is a written plan

The internal name is a PDP, a personal development plan. Most people assume a document like that is the paperwork you file on your way to firing somebody, and ours is built to do the opposite.

A PDP is a written document with a manager attached, a target start and end date, specific things that need to change, and a recorded result at the end. The person knows they are on it. They know what passing looks like. Nobody is being quietly graded.

Why the paperwork is not optional

Full Scale is incorporated in the Philippines, and the engineers we place are our employees under the Philippine Labor Code and the rules of the Department of Labor and Employment. They are not freelancers attached to a platform, and they do not work for the client either. They work for us, with the protections that carries.

Those protections are specific. Dismissing somebody for cause in the Philippines requires documented due process: a written notice setting out the exact grounds, at least five calendar days for the employee to answer in writing, a real opportunity to be heard, and a second written notice explaining the decision. An employer who skips the steps is liable for it even when the underlying reason was sound.

That rules out the vague, undocumented version of a performance conversation, and honestly I think everyone is better off for it. Nobody here gets managed out by mood. By the time any decision is made there is a written record of what was asked for, what changed, and what did not.

So far, four out of five people who have finished one have passed it. That number matches what I would have guessed, and it is the reason we bother: most people who are struggling turn out to be miscast, under-supported, or quietly dealing with something nobody thought to ask them about.

Some do not pass. A handful of people leave Full Scale each year over performance, and I am not going to dress that up. Somebody losing their job is a serious thing and we treat it that way, which is also why the plan comes first and why it is written down.

What is rare is discovering this early. We very seldom hire somebody and part ways inside their first six months, which is the clearest evidence I have that the interview process and the background checks are doing their job.

Sometimes the fix is a different team, not a different person

When the diagnosis is a mismatch, the answer is reassignment.

This is the part that surprises clients. An engineer who came off one of our accounts this spring for performance reasons is now, a few months later, one of the three most prolific instructors in our internal training program, with ten courses to their name that other engineers here learn from.

Nothing about them changed in April. They got put somewhere their strengths were the point rather than a liability.

Figuring out which of those two situations you are in is most of the skill, and it is why we score people against a written ladder rather than a general impression. A vague sense that somebody is underperforming tells you nothing about what to do next. A specific gap does.

We used to get this wrong

I should be honest about how we learned the difference, because for years we got it backwards.

Our old instinct when somebody was underperforming was to keep them and go hunting for a client who would take them. It felt like the humane choice. It was really the lazy one, and it did not work. They usually struggled at the next client too, that client did not refer anyone to us, and we had turned one hard conversation into two unhappy accounts.

The difference between reassigning somebody and shopping them around is whether you have actually diagnosed anything. A reassignment starts with knowing why the fit failed and where that person’s strengths would be the point instead. Shopping somebody around skips that part and hopes the next team notices less.

The rule we ended up with is blunter: train them up or train them out.

There is nobody to hide behind

All of this only makes sense given what we are actually trying to be, which is a long-term partner rather than a shop that delivers a project and moves on.

Plenty of outsourcing firms put a project manager between you and the engineers. You talk to the PM, the PM talks to the team, and you never really learn how good the developers are, because you are only ever seeing the filtered version of them.

Our engineers work directly with your team. That is what staff augmentation actually means: they are in your standups, your code reviews, your Slack. We cannot hide a weak developer behind a project manager, because there is no project manager to hide one behind.

That is a constraint we picked on purpose and it forces the issue. Everyone we place is visible, which means everyone we place has to be good. When we put strong people on a new account, the client is happy and the account grows. Nothing in that model rewards parking somebody who is struggling on a team that did not ask for them.

There is one more reason to move quickly, and it has nothing to do with clients. Good engineers do not want to carry somebody who is not pulling their weight. Leaving a performance problem alone quietly taxes the people you would least like to lose.

Why your interview cannot predict this either

Here is the uncomfortable part for both of us.

It is very hard for a client to interview a developer and know whether they will actually work out on their team. You get an hour, maybe two. You can assess whether somebody can think, whether they communicate, whether they have done the work before. You cannot assess whether they will thrive in your specific codebase, with your specific team, at your specific pace.

Nobody can. I have been hiring engineers for twenty years and I cannot do it reliably in an interview either.

Which is why we tell clients to treat the first couple of weeks as the real evaluation. The first two weeks come with a money-back guarantee. It exists because the only reliable test of fit is the work itself.

To be clear about what we do not offer, since the industry is full of it: we do not promise a replacement guarantee. We give you your money back in the first two weeks, and after that you can drop a developer with 30 days’ notice and no long-term contract. Those are the actual terms.

The mechanism that matters most is speed

Almost every performance situation that turns into a disaster was a small, fixable thing that nobody said out loud for two months.

Every client has a customer success manager whose job includes asking, on a monthly cadence, whether each person on the team is working out. Not a survey nobody reads. An actual person asking an actual question, with the ability to escalate.

You can also just email us, which people forget.

The reason we ask on a schedule is that most people will not volunteer bad news early. They wait until they are annoyed, and by then the developer has spent eight weeks doing the wrong thing while believing everything was fine. That is unfair to everybody in the story.

We also read the daily reports for the same signal, because the shape of somebody’s updates usually shows a problem before a human reports one.

The counter-story: sometimes people just need a shot

Let me end on the opposite case, because it comes up far more often than the failure one.

We hire entry-level engineers out of local colleges through a program we call Fast Track. Sometimes we offer one of them to a client at a substantially reduced rate, occasionally close to free, because we are trying to get somebody their first real opportunity.

Roughly 90 percent of the time, once a client has had one of those people on the team for a couple of months, they will not give them back.

They do not want the discount anymore. They want the person.

That has taught me more about performance than any rubric has. A lot of what looks like a performance gap is actually an opportunity gap plus a ramp period nobody budgeted for. Give somebody the shot and about eleven weeks, and you frequently get an engineer other people start asking for by name. The system behind that ramp is how we train.

Ask a vendor what happens when it goes wrong

Every staffing company will tell you their developers are great. The more useful question is what they do on the day one of them is not.

If the answer is a replacement guarantee and nothing else, that vendor is offering to swap a name on an invoice. What you actually want is somebody who will diagnose the problem, tell you honestly whether it is the person or the pairing, and fix whichever one it turns out to be.

If you want to talk through what that would look like for your team, schedule a call.