"Am I crazy or does my engineering team not know what they’re doing?"
5 red flags 🚩every non-technical founder should know before & after hiring their dev team.
A non-technical founder friend asked me to audit his engineering org because he wasn’t sure if his team actually knew what they were doing or if he was being lied to. Within a day of digging through the codebase and the org chart, I could see why he asked.
What followed was a few weeks of hard, eye-opening conversations that got the core team back on track and reduced his burn. I went into it happy to do a favor for a friend. But he ended up paying me a consulting fee for my services! And that’s the first time I realized this accidental knowledge I’ve built up over seven startups in ten years could be useful to others.
So if one founder found it useful enough to pay me, I figured other founders might need it too. So here are five red flags to keep on your radar.
🚩 Red Flag #1: Big titles that don’t build
Looks good on LinkedIn. Useless in the trenches.
Early-stage startups need leaders in the codebase, not managers of managers. A VP “ready to become CTO” who hasn’t touched code in years might be useful later, but it’s not useful now, especially if you are pre-product. You need someone who can help you make the thing, not just manage the thing.
🚩 Red Flag #2: The wrong specialty in the top seat
QA leadership ≠ Engineering leadership.
QA (quality assurance) is critical, but QA doesn’t design systems or ship features. If your VP of Engineering comes from QA, you don’t have engineering leadership; you have a tester in charge of builders. It’s the wrong tool for the job.
During the audit, I realized the VP of Engineering was from QA, the PM was from QA, and a third of the offshore team were QA too! The result? Nobody was building any product. Just testing and re-testing!
🚩 Red Flag #3: The small signs of not caring
They won’t tell you they’re bad engineers, but there will be signs.
The best engineers (aka the ones that care) sweat the details. They add thoughtful UI/UX touches you never asked for but take for granted. Things like:
Auto-fill for 2FA codes
Auto-fill your name and address
Clean error states
Bad engineers, on the other hand, do the bare minimum. You’ll be forced to micromanage them every step of the way.
Case in point: my friend’s engineering team was stacked with QA, yet the bugs were nonstop! And the worst part was that the founders had to report every issue themselves because no one on the engineering team was checking their own work. Absolute micromanagement hell.
Another example: one developer I worked with introduced a bug into production1. I flagged it to him directly and stressed we needed an urgent hotfix. Two hours later, I came back to check on his progress. But instead of nearing a solution, he was scrolling through bikini models on Instagram2.
So once more for the people in the back:
They won’t tell you they’re bad engineers, but there will be signs.
🚩 Red Flag #4: Over-architected on purpose
Because the more they build, the more you owe.
Some offshore teams aren’t incentivized to move fast or keep things simple. They’re incentivized to build more. More services. More moving parts. More reasons you’ll need them forever.
I’ve seen dev groups spin up a custom authentication service instead of plugging in Auth0 or Okta. A SaaS vendor is cheap and predictable. But building it custom means more code to maintain, more hours to bill, and more engineers to justify.
It looks like progress, but it’s just technical debt dressed up as “innovation.”
🚩 Red Flag #5: Don’t play company dress-up
Skip the VP/Director alphabet soup until you’ve earned it.
A lot of founders copy what they see at big companies: Hierarchy. Titles. Layers.
But without product-market fit, that org chart is just cosplay.
The “Director of Product” I reviewed had never talked to a single user. He brought no ideas of his own to meetings, and he started every sentence with “No, we can’t do that”. His only role was acting as a go-between for the founders and the engineers. And because he was part of the offshore team, his incentives were to slow things down. Just overhead with a fancy email signature.
And speaking of email signatures. At one startup I was at, we were pre-launch and under ten employees, but someone spent time crafting a style guide for email signatures. That was the moment I knew this was just a cosplay startup.
The takeaway
Unfortunately, these problems creep up slowly. They start quietly but end up being fairly expensive. But if you’re paying attention, you can catch the red flags before it’s too late.
And if you’re a non-technical founder looking for a second opinion on your engineering org, book a call with me on GrowthMentor. It’s free!
We’ve all done this (especially me), so this is not about the bug. This is about the response. If you fire a developer over introducing a bug, you don’t belong in tech.
That’s a true f-ing story, and I still get livid thinking about it.