How to Tell If Your Developers Are Good When You're Not Technical

The team is slow. You have tried to be patient about it. Then a worse thought arrives, usually at night: maybe they are just not good.

You cannot tell. You are not technical. You cannot read the code, so you cannot judge the people who write it. You are trusting them on faith and hoping the faith is earned.

I'll start where my last post stopped. In why your dev team is slow, I said most slowness is not a people problem, and I meant it. But sometimes it is. And "I cannot read code" should not leave you trusting blind.

I've run more than a thousand technical interviews. For years my job was to decide whether an engineer was good, often in under an hour, often in a language I do not write myself. You learn fast that competence shows up in places a non-technical founder can see too. You just have to know where to look.

Here is what I look for.

How They Handle "I Don't Know"

Good engineers say it cleanly. "I don't know, but here's how I'd find out." Then they tell you the steps.

Weak ones bluff. They reach for words instead of answers, and the words get vaguer the longer they talk.

This is the single most reliable signal I've found, and it needs zero technical knowledge to read.

The move: ask about something slightly outside their area. Watch whether they admit the edge of what they know or paper over it. The honest answer is the better hire, every time.

Whether They Explain Trade-Offs in Plain Language

Ask why they chose this database, this framework, this approach. A strong engineer can walk you through it in words you understand. They will tell you what they gave up to get it.

Jargon used to explain is fine. Jargon used as a wall is a flag. If every answer leaves you more confused and a little embarrassed for asking, that is not your gap. It is theirs.

The move: next technical decision, ask them to explain it like you will have to defend it to an investor. Good engineers can. It is a skill, and it tracks with the rest of their judgment.

Whether Estimates Come With Conditions

"Three days if the API behaves, a week if it doesn't, and I'll know which by Wednesday." That is a good developer. They have thought about what could go wrong and when they would see it.

A flat, confident number every single time is the worry. It usually means they have not looked hard enough to know what they do not know.

The move: when you get an estimate, ask what would make it wrong. The quality of that answer tells you more than the number did.

How They Treat the Unglamorous Work

Tests. Documentation. The boring fix that nobody will ever thank them for. Good engineers respect this work because they have been burned by skipping it.

You do not need to read the tests. You can hear it in how they talk about them. Contempt for the boring parts is a tell.

How They React to Being Wrong

Everyone is wrong sometimes. The good ones get curious about it. The wrong call becomes a thing to understand, not a thing to defend.

Defensiveness, blame, a story about why it was not their fault: watch for the pattern, not the single instance.

Two Traps That Catch Founders

Confident is not the same as competent. The most fluent talker in the room is not always the strongest engineer. Charisma reads as skill, and it fools smart founders constantly.

The reverse trap costs more. A brilliant developer who is quiet and bad at explaining can look worse than they are. Communication and ability sit on different axes. Do not promote the loud one and lose the quiet one by mistake. I've interviewed plenty of excellent engineers who interviewed badly, and plenty of weak ones who interviewed beautifully.

Speed is not quality either. Fast code that breaks in three months is not fast.

Before You Blame the Person, Rule Out the System

Here is the part that matters most, and the reason I led with my other post.

A good engineer in a broken system looks slow and sloppy. Unclear scope, decisions nobody owns, no delivery rhythm: that environment makes strong people look weak. Move the same person into a team that has its act together and they transform.

So before you conclude it is the person, rule out the system. Most of the time, it is the system. That is not me being kind. It is what I see when I walk into these teams.

The move: ask whether your best developer would look good somewhere else. If the honest answer is "probably," fix the room before you touch the roster.

When It Really Is the Person

Sometimes you rule out the system and the problem is still there. A hire who cannot do the work, or will not. It happens, and pretending otherwise helps no one, least of all the rest of the team carrying them.

Be honest about it when it is true. But know the floor: judging deep technical ability has a point you cannot reach from outside the code. At some level you need someone technical you trust to look properly. That can be a one-time review or a fractional CTO for a while, not a permanent dependence on hope.

Start With the System

I built a short diagnostic for the system side of this. Fifteen questions, about three minutes. It scores where your team sits across scope, decisions, rhythm, alignment, and risk, the five things that make good developers look slow when they are missing.

It will not tell you who to keep and who to let go. That is a judgment call, and it should be. What it will do is tell you whether the people are the problem, or the room they are working in.