Staffing is not just filling seats until the headcount math works. The order you make decisions in matters as much as who you pick. I start every team the same way: identify the tech lead first, then build the rest of the team around that person and the shape of the work.

When to use this play#

Use it whenever a project needs more than one engineer. Once there is a team rather than a single contributor, someone has to own technical direction and the team has to cover a full set of responsibilities, not just write code. This play is about getting that composition right at the start, when it is cheap to change, rather than discovering the gaps three sprints in.

How to run it#

Name the tech lead before anyone else. On any multi-engineer project, the tech lead is the first person you identify, and the rest of the team is assembled partly with their input. The tech lead does not have to be the person with the most experience in the project's stack. In fact, a good tech lead is comfortable joining a project without prior experience in the stack, because their job is direction, standards, and unblocking, not being the resident expert on every API. What you are screening for is whether they can lead, not whether they have memorized the framework. Evaluate the candidate against questions like these:

• Are they actually interested in being the tech lead? Reluctant leads make weak teams.
• Have they led technically on a project before, in any form?
• Can they set and hold the technical direction for the work?
• Can they facilitate communication between the engineers and the business, design, and other stakeholders?
• Are they willing to guide and mentor the other engineers on the team?
• Can they relate technical work back to business value so it can be prioritized sensibly?

Bring the tech lead into staffing the rest of the team. Once you have your lead, tell them they are joining in that role and pull them lightly into choosing who else comes along. They will be living with these people daily, so their read on the available engineers is signal worth weighing. It does not have to be a veto; it should be a genuine input.

Balance stack experience against eagerness to stretch. When you evaluate each available engineer, you are trading off two things that rarely both maximize at once. Some of the team should know the stack so the project has velocity from day one. Some of the team should be people who are eager to take on a project in a stack they have not used, because that is how engineers grow and how you avoid a brittle team of narrow specialists. For each candidate engineer, weigh:

• If the stack is known, do they have experience with it?
• Are they eager to take on work in a stack they do not yet know?
• Do they have any prior context with this client or domain that would shorten ramp?

A healthy team usually mixes a couple of people who can hit the ground running with a couple who are stretching, all anchored by a tech lead who can hold direction regardless.

Cover the roles, not just the headcount. Engineers are only part of a delivery team. Before you call staffing done, walk the full set of responsibilities the engagement needs and make sure each is owned by someone, even if one person wears two hats early on. That typically includes product ownership, delivery leadership, technical leadership, the engineers themselves, and experience or design coverage. I keep the detailed breakdown of who owns what in a companion note, delivery team roles; use it as your checklist so a critical responsibility does not silently go uncovered.

Plan the ramp explicitly. Whoever is stretching into a new stack, and whoever is new to the client, will be slower for the first couple of weeks. Build that in. Pair them deliberately, set realistic expectations for early velocity, and protect a little learning time. A team that pretends everyone is at full speed on day one just converts the ramp cost into hidden schedule slip.

Common traps#

• Staffing engineers before naming the lead. If you pick the engineers first and then look around for who will lead them, you often end up with a reluctant or default lead. Reverse the order.
• Confusing the tech lead with the stack expert. Leadership, communication, and the ability to set direction matter more than framework familiarity. A strong lead can come up to speed on the stack.
• An all-veteran or all-rookie team. All veterans in the stack gives you speed with no growth and a fragile bus factor. All rookies gives you growth with no momentum. Mix deliberately.
• Counting heads instead of responsibilities. A team can be fully staffed with engineers and still have no one owning delivery cadence or the user experience. Walk the roles checklist.

Signals it's working#

• The tech lead is set and bought in before the rest of the team is assembled, and they had real input into who joined.
• Every core responsibility on the engagement has a clear owner, even where one person covers two.
• The team has both people who know the stack and people growing into it, and nobody is pretending the ramp is free.
• A few weeks in, the team is finding its rhythm rather than discovering a structural gap that staffing should have caught.