How founders can evaluate an engineering team

Most non-technical founders assume they cannot evaluate their engineering team, so they do not try. They rely on whether the team seems busy, whether the tech lead seems confident, and whether the last demo went well. Then a release slips by a quarter and they realise they have no idea whether they have a team problem or a bad quarter.

I have spent 22 years working with engineering teams, and a lot of that time explaining to founders what they were looking at. The useful news is that most of what determines whether a team performs is observable without a technical background. This is what to look at, what to ask, and how to do it without the team feeling put on trial.

Evaluate the system before the people

Start with a rule. Before you form an opinion about any individual, form one about the system they work in.

The reason is practical. A strong engineer in a team with undefined ownership and no automated tests will look slow and error-prone. A mediocre one in a well-run system will look fine. If you evaluate individuals first, you will mostly be measuring the system and attributing it to people, and you will act on that.

So the first pass is about flow, ownership, and process. I described how to trace that in why is my dev team so slow. Do that first. Only then look at people.

What you can observe without reading code

Whether work ships when promised

Take the last three months. For each thing the team committed to, note when it was promised and when it reached users. You are not looking for perfection. Software estimates are hard everywhere. You are looking for two things: whether the misses are consistent, and whether the explanation is the same each time or different each time.

Consistent misses with a stable reason point at a specific fixable cause. Consistent misses with a new reason every time mean the team cannot see its own work, which is structural.

Whether shipped work stays shipped

Count how often something that was declared done comes back. Bugs in the first week after release. Features that had to be reworked because they did not do what was asked. A team that ships fast and then spends the next sprint fixing what it shipped is not fast.

This one is a direct read on two things: whether there are automated tests, and whether work was defined clearly enough before it started.

Whether ownership is clear

Ask each engineer, separately, what they own. Then ask what done means for the thing they are working on this week. Compare the answers.

If the answers overlap, contradict, or come with hesitation, ownership is undefined and delivery is leaking at the edges. This is the most common structural problem I find and it is invisible from a status meeting, because in a status meeting everyone sounds like they own everything.

Whether the team can explain itself

Pick a recent technical decision, a library choice, an architecture change, a delay. Ask the engineer responsible to explain it to you in plain language, including what the alternative was and why they did not take it.

A strong engineer can do this. It might take them a minute to find the right level, but the explanation will have a reason in it and a tradeoff. If what you get is jargon, or "it is complicated", or a justification that shifts when you push, that is a signal. Either they do not fully understand the decision themselves, or they do not think you deserve an explanation. Both matter.

Whether the team knows why

Ask engineers why this week's work is the priority. Not what, why. If they know, the connection between the product and the team is working. If they do not, the problem may be you, and I mean that kindly: it usually means priorities are reaching the team as instructions without context.

The signs of underperformance

Any of these occasionally is normal. Several of them, for months, is a pattern.

• Small changes take weeks. A trivial task taking as long as a hard one means the path is slow, not the work.
• Releases are rare, large, and stressful. The team is batching because releasing hurts.
• The same person is the one every delayed piece of work is waiting on.
• Estimates never improve, sprint after sprint, even when the same kind of work repeats.
• Engineers cannot describe what done means for their current task.
• Nobody can tell you how a change gets from a laptop to production without asking someone else.
• The tech lead is the biggest individual contributor and has no time to unblock anyone.

Notice that almost none of these is about an individual's ability. That is the point.

Evaluating individuals, once the system is clear

If the system is reasonably healthy and delivery still lags in one area, you can look at people. Here is what you can judge without reading code.

Reliability. Does this person's work ship when they say it will, and stay shipped. Compare them to the team's baseline, not to an imaginary ideal.

Communication. Can they explain their work and their decisions. Do they raise risks early or announce them the day of the deadline.

Ownership. When something in their area breaks, do they pick it up or wait to be asked.

Growth. Are they doing the work the seat requires, or the work they did in their previous job. A senior doing junior work is often a role problem rather than a person problem, and worth checking before concluding anything.

What you cannot judge is the quality of the code itself: whether it is maintainable, whether it will scale, whether the architecture is sound. That requires someone technical who is not inside the team. Your tech lead can tell you, and their view is useful, but they are part of what is being evaluated and they have relationships to protect. Treat it as data rather than verdict.

How to do it without hurting morale

Engineers can tell when they are being evaluated, and a team that thinks it is on trial gets quieter, not better. A few things make the difference.

Say what you are doing. "I am trying to understand how work flows through the team and where it gets stuck" is an honest description, and it is a different sentence from "I am working out who is underperforming". Use the first one, and mean it.

Ask everyone the same questions. Consistency reads as fairness. Singling one person out for questions reads as a decision already made.

Look for waiting, not for blame. When you trace a delayed piece of work, you are looking for where it sat and what it was waiting on. Frame it that way with the team. Most of what you find will be structural, and a team that watches you fix structure trusts you more, not less.

Act on what you find. An evaluation that produces no change teaches the team that the questions were theatre. If you find undefined ownership, define it. If you find no automated tests, make that the priority. Visible follow-through is what makes the next round of questions welcome.

Decide about individuals last, and be sure. If the evidence points at a person, get a second read before acting. Replacing someone on a wrong diagnosis costs you the person, the time to rehire, and the trust of everyone who watched it happen.

What you should know at the end

After a week of this you should be able to say, in plain language, whether your team's problems are in the people, the roles, the process, or how work reaches them, and roughly where. If you can say that, you can brief anyone you bring in, and you can make the next hiring decision on evidence rather than on a feeling that something is off.

If you have done the work and still cannot tell, that is not a failure. It is the point where an outside read is worth the cost, and you will get far more out of it for having done the observation first.