Putting the right engineer on the right project is one of the highest-leverage decisions a leader makes, and one of the easiest to make on gut feel and never revisit. I treat fit as an ongoing, evidence-based judgment: set people up well, watch a small set of honest signals over time, and be willing to act, in either direction, when the signals are clear.

What signals to watch#

Two kinds of indicators matter, and you need both.

Team-level signals show how an engineer affects the system around them. Are they helping or hurting the team's lead time and cycle time? Are they maintaining or improving the test coverage baseline? Are they respecting work-in-progress limits, or piling up half-finished work? Is the user-reported defect rate of their work acceptable? These are not used to rank individuals against each other; they show whether someone is making the whole team's flow better or worse.

Individual, qualitative signals capture things the team metrics miss: the quality of their technical contribution, how well they collaborate and pair, whether they take initiative and ownership, and whether they are starting to lead and mentor others. Add a few fit-specific reads on top: how fast they are picking up the domain, how well they are integrating with the team's working style, and how genuinely they are adopting core practices like pairing and test-driven development.

No single number tells the story. The picture comes from watching these together, over a 3-to-6-month window rather than a single sprint, so you are reading trends instead of noise.

Set people up before you judge them#

It is unfair to evaluate fit before you have actually given someone a fair shot, and a lot of apparent "bad fit" is really bad onboarding. So the support comes first. Give a new engineer clear documentation of the project context, a dedicated pairing partner for the first couple of weeks, explicit expectations for what they are committing to, and success criteria defined up front so the target is not a moving one. Then keep supporting them: regular one-on-ones aimed at blockers and growth, rotating pair partners for diverse perspectives, clear escalation paths for technical problems, and some protected time to build skills. Only once someone has been genuinely set up to succeed does it make sense to read their fit signals as a real reflection of fit.

When a project change is the right move#

A change of project is not a punishment. Often it is the healthy, positive call. Consider moving an engineer when they have mastered the current domain and their growth is plateauing, when their skills better match an emerging need elsewhere, or when their development simply requires exposure to new technology or a new domain. Readiness to lead and mentor is itself a signal that someone may be ready for a different challenge.

There are also performance-driven reasons. If individual signals decline across two or more evaluation periods despite real support, if collaboration is consistently below what the team needs, or if someone's work is reliably dragging the team's cycle time or spiking its defect rate, a change of project may be the intervention. Treat these as triggers for a conversation and a deliberate move, not as a verdict.

When it is bigger than the project#

Sometimes the honest conclusion is that the issue is not the project. When individual signals do not improve even after focused support and a documented improvement plan, when someone is fundamentally misaligned with how the team works, or when multiple project changes have produced no improvement, the responsible call may be a transition out of the role entirely. This should be a high bar, reached on evidence accumulated over time, never an impulse. Doing it fairly means you can point to the support that was offered and the trend that did not move, not just a feeling.

Learn from both ends#

The discipline that ties this together is retrospective. When someone leaves, document it honestly: how the initial read compared to actual performance, where the friction really was, what support was tried, and the timeline of what you did. When someone thrives, document that too: what made them successful, which onboarding elements worked, which project characteristics enabled both delivery and growth, and which pairing dynamics clicked. Over time these write-ups turn fit from a series of one-off guesses into a system you actually understand and can repeat.

For the underlying language of what "growing" and "leading" look like across the dimensions referenced here, I lean on a shared growth framework; see the six-dimension framework for engineer growth. Fit decisions land much better when they are spoken in a vocabulary the engineer already shares with you.