Engineering Team Performance: A Non-Technical Founder’s Guide

You are spending $20,000 a month on engineers. Maybe more. The Jira board shows tickets moving. The weekly standup runs smoothly. Your lead developer says everything is “on track.”

And yet the feature your sales team promised a client three months ago is still not live.

This is the black box problem. You cannot read the code or assess architecture quality. Instead, you trust the process, trust the people, and wait.

Most non-technical founders I work with are in this situation. They are not asking questions because they don’t know which ones will help.

This article gives you those questions. No coding required.

The Black Box Problem

I have walked into many engineering teams that looked fine from the outside. The developers seemed busy, but six months later, the team still had not shipped the feature the CEO promised at the last board meeting.

Surface signals lie. A busy-looking team can be completely stuck, and a calm team can be shipping clean work every single week. Ticket counts tell you nothing about code quality. Sprint velocity tells you nothing about whether your architecture holds when you hit 500 paying users.

What actually tells you something is behavior. The things your team does and says when no one prepared the narrative in advance.

A Team That Looked Fine

The CEO had numbers. Client satisfaction is at 7.7 out of 10. Developers are busy every sprint. A team lead who answered every question with confidence.

What he lacked was delivery. Every single development request that quarter came in late. 

When I went inside, the picture was different. Bug correction lead times ranged from 2 days to 194 days on the same team, for the same type of defect. Only 2 out of 10 fixes were done right the first time. The other 8 went back into the cycle, retested, reassigned, reexplained. The analysis documents were sitting in the team lead’s inbox for up to 11 days before anyone touched them.

There was a third problem, quieter than the other two. The engineers who flagged issues during testing were ignored. It was not deliberate. The process simply had no place for their input. By the time a defect reached a developer, the context was gone. The requirements were misread, and the fix was wrong before anyone wrote a line of code.

The team was not slow; the system was broken. Nobody had told the CEO because nobody inside could see it clearly enough to name it.

That is the black box problem.

The Warning Signs

1. Every estimate is wrong in the same direction

Estimates being off is normal. Software is sometimes uncertain. But if your team consistently underestimates by 2x or 3x, in every sprint, for months, there is a system problem. Either the team does not understand the codebase well enough to estimate, or there is a hidden technical debt, quietly eating up 40% of every sprint. 

Ask your lead one question: how much of last quarter’s capacity went to unplanned work? If the answer takes time, you already have your answer.

2. Bug fixes take longer than new features

This one is counterintuitive because new features are complex. Everyone assumes fixes are fast, but they are not when the codebase is fragile. When fixing one thing routinely breaks two others, your architecture is already compromised. Engineers call this “tight coupling.” You will experience it as an endless cycle of regressions, hotfixes, and “we thought we fixed that” conversations.

3. Your team avoids talking about the past

Pay attention in meetings. Healthy teams reference past work freely. They say, “We built this six months ago; we can extend it.” Struggling teams avoid the past. They talk in circles about what to build next, never grounding the conversation in what already exists. That avoidance is often shame, or fear, or both.

4. New engineers take months to become productive

A well-structured codebase with decent documentation gets a new developer shipping within two to four weeks. If your team tells you it takes three months to onboard someone, your codebase is a labyrinth. No one wrote anything down. The knowledge resides in the heads of one or two people. That is a fragility risk, not just a speed problem.

5. The answer to “why is this taking so long?” is always technical

Technical reasons for delays may be true. But if you never hear scope misjudgments or shifting priorities, you aren’t getting the full story. Encourage business-focused translations from your team.

Noise, Pattern, Problem

Generally, one incident means nothing. Software development can be messy. For example, estimates slip, and a sprint goes sideways. These things happen in every team, including the good ones.

Watch for repetition. If the same signal shows up three weeks in a row, something is wrong with the system. Two signals at the same time means you have a real conversation to initiate, deliberately, not in a corridor between two meetings. If there are three or more issues simultaneously, you are looking at a structural problem, and it is already costing you more than you think. They will not resolve on their own. I have been in that room.

You do not need certainty before acting. Stop explaining away what you are seeing.

What Good Actually Looks Like

1. They push back on your feature requests

This is the one that surprises founders most. A healthy engineering team says no, or “not like that.” They ask why before they ask how. They raise concerns about scope, about dependencies, about things you did not think to think about. A team that says yes to everything is not agreeable. They are disengaged, or afraid, or both.

2. They can explain what they built last month in one sentence

Ask your lead developer, “What did the team ship in the last four weeks? One sentence.” A healthy team provides clear and precise business-oriented answers. Otherwise, vague responses mean the team lacks direction.

3. Production incidents are rare, and post-mortems happen

Every team ships bugs. What matters is the response. Healthy teams hold post-mortems to learn, not blame. Treating incidents as exceptions leads to repeats.

4. They talk about users

I have worked with dozens of engineering teams. The ones that move fast and build the right things talk about users constantly. “What does the user actually need here?” “Have we tested this with a real user?” When engineers are disconnected from the people using the product, they optimize for the wrong things. Clever architecture. Interesting technical problems. Not user outcomes.

5. They say “I don’t know” without panic

Healthy engineers are comfortable with uncertainty. When you ask a question they cannot answer, they say so, and they tell you how they will find out. A team that always has an immediate answer to every question is either performing with confidence or not thinking hard enough about the problem.

The One Conversation to Have This Week

Pick one metric your engineering team tracks. Velocity, cycle time, deployment frequency, whatever is available for you. Ask your lead two questions.

First: “What does this number mean for the business?” Not for the team. For the business.

Second: “What would make this number worse next quarter?”

The quality of those answers will tell you more about your team’s health than six months of standup notes. A team that can connect its technical metrics to business outcomes understands what it is building. A team that answers with technical jargon and shrugs at the business question has a communication problem at minimum, and possibly an alignment problem.

You do not need to understand the metric to evaluate the answer.

When the System Evaluates Itself

The conversation in the section above assumes something important: the person you are asking can give you a straight answer.

That is not always true. If your lead developer is the one managing estimates badly, asking him to self-assess produces theater. I have sat in those conversations, and I walked out feeling reassured. Nothing changed.

A CTO does not solve this automatically. He is a translation layer between you and the team. When that layer is honest and sharp, it is worth every euro. When it is not, you have the most expensive blind spot in your company. 

Most technical leads are not lying. They manage up, they protect their team, and because of that, they genuinely cannot see what is right in front of them. People inside a broken system rarely see it clearly. That is not a character flaw. It is just how systems work.

There is a point where the internal conversation stops producing useful information. You are asking the system to evaluate itself.

When You Need Outside Eyes

Three situations make this urgent. You are about to raise a Series A, and investors will run technical due diligence.

Your CTO just resigned, and you need to understand what they left behind. You have been scaling the team for six months, and delivery has gotten slower, not faster.

In those situations, you need someone who can go inside the codebase, not just observe behavior from the outside. Someone who speaks both languages: technical enough to see what is actually there, and business-minded enough to tell you what it means for your roadmap, your team, and your investors.

That is when you need an outside diagnostic. Someone who comes in, observes the team, measures the delivery data, and gives you a clear picture in language you can act on.

In practice, that means looking at how your team actually works. It is not how it reports. How long does a fix take from the moment it is identified to the moment it is live? Where does work pile up? Who holds knowledge that no one else has? The output is not a list of technical recommendations. It is a business picture: what is slowing you down, what it is costing you, and what to address first.

The team from earlier in this article is a good example. Ninety-two defects per month, zero on-time deliveries, 80% of fixes done wrong the first time. Three months after the diagnostic, defect volume was falling, the NRFT rate had dropped significantly, and the team had its first on-time deliveries. No new engineers. No new tools. The same people, working inside a system they could finally see clearly.

Not every team needs one. But if you have been running on gut feel for more than six months, and you cannot confidently answer “is my team performing?”, the cost of not knowing is probably higher than the cost of finding out.

Frequently Asked Questions

Can I run this assessment myself?

Partly. Every signal in this article is visible without technical knowledge. To notice that estimates are always wrong in the same direction, you do not need to read code. Same, to see that your team goes quiet when you ask about the past six months.

But there is a ceiling. You can see that features are slow. But you cannot see why. Is it one fragile module? Two years of accumulated debt? An architecture that will hold for now but crack the moment you hit 2,000 users? Those distinctions change every decision you make for the next two quarters. From the outside, they are invisible.

I have worked with founders who spent six months convinced their team had a motivation problem. The real issue was an architecture decision made two years earlier by a developer who had since left. No behavioral signal points clearly at that. You see the symptoms. The cause stays hidden.

My team is offshore. Does any of this still apply?

Yes, and the gap between what you are told and the reality tends to be wider.

Offshore teams add distance, making behavioral signals harder to detect. Time zones compress communications. In some team cultures, engineers simply do not surface problems to their supervisors. It is not because they are hiding something. It is not how they were trained to work. I have seen founders spend eight months reassured by weekly status updates while the codebase was quietly becoming unmaintainable.

The warning signs are the same. They are just easier to miss.

How do I know if things are really that bad?

Founders who are confident in their team do not usually read articles like this one.

If you finished this article and nodded at two or three warning signs, that is already your answer. You have enough to stop waiting and start looking.

I have a CTO. Does this article still apply to me?

Yes. And the question is worth asking clearly.

A CTO gives you a translator. He does not give you independent visibility. If your CTO is the one setting estimates, making hiring calls, and choosing the architecture, you have no outside reference point to assess whether those decisions are sound. Most founders with a CTO feel more reassured. That is not the same as being better informed.

The signals in this article apply whether you have a CTO or not. What you are looking for is the gap between what you are told and what is actually happening. A CTO can close that gap, or widen it.

What actually happens during a diagnostic?

I come in and look at how work actually moves through your team, from the moment a feature is requested to the moment it is live. I observe the team at work. I measure delivery data: cycle times, handoffs, rework rates, where work piles up, where context gets lost between people.

I am not collecting your team’s self-assessment. I am watching what really happens. The output is a live dashboard with baseline metrics, a clear picture of what is slowing delivery down, and why. Then, I create a tailored workshop plan so your team can design the fix themselves.

There is no slide deck. Only a dashboard you keep, and a team that understands its own system for the first time.

My team is early. Is it too soon for a diagnostic?

It depends on one thing: are you already spending more than €15,000 a month on development?

If yes, you are past the point where gut feel is free. Every month you run without visibility, decisions accumulate on top of each other. By the time delivery slows down or investors start asking hard questions, those decisions are already baked in. A diagnostic at this stage is cheap compared to six months of compounding problems you cannot see.

If you are pre-product or have fewer than five developers, the behavioral signals in this article are enough for now. Start with the conversation I described above: one metric, two questions. Then come back when you are scaling and the answers stop making sense.