No SDETs and No QA Engineers.

One of the best decisions I’ve made across multiple startups is never hiring QA engineers or SDETs (Software Development Engineers in Test).

A hard rule, but always the right one.

Before the Pushback: Two Important Notes

1. I’m not saying SDETs are never valuable. Some of the SDETs I’ve worked with are excellent. But for most startups and companies, they are unnecessary. And sometimes harmful.

2. The need for lean engineering teams is more evident than ever, thanks to:

• Proper engineering practices (DevOps, TDD, Automated CI/CD, UI testing, etc.).

• AI tools that enhance software quality (though not necessarily the best code quality—whatever “best” means for a company).

With that out of the way, let’s dig in.

Who’s Responsible When Something Breaks in Production?

If a bug appears in production and you have both engineers and QA testers, who’s responsible?

• With engineers only, the answer is simple: engineers.

• With engineers and testers, responsibility becomes shared—which means no one is fully accountable.

If we trust engineers to build quality software, why do we need SDETs? Hiring SDETs suggests a lack of trust in our engineers.

Ultimately, writing, testing, and ensuring code quality is the engineer’s job — not the QA engineer’s, not the SDET’s.

Sure, in highly regulated industries or complex release workflows, extra testing is necessary. But for most startups, this isn’t the case.

The 2nd Order Effect of Having SDETs & QA Engineers

Bringing in SDETs fundamentally alters the entire software development lifecycle (SDLC) and team dynamics across engineering, product, design, and even sales. Take the following problems, viewed from the engineers perspective:

1. “It’s Not My Problem” Mentality

Without SDETs: If a bug hits production, it’s the engineer’s responsibility—no excuses.

With SDETs: “Not my problem. The SDET didn’t catch it either.“

2. No End-to-End Ownership

Without SDETs: Engineers own the full cycle—from ideation to deployment.

With SDETs: “I don’t need to think about the feature end to end. Someone else will check my work later.“

This mindset kills innovation, accountability, and attention to detail (aka, craftsmanship.)

3. No Involvement in Releases

Without SDETs: Engineers care about how and when things go live.

With SDETs: “My work will be released by someone else—SDET, DevOps, or whoever. I just write code.“

This breaks the connection between engineers and the impact of their work.

4. Recurring Rollout Problems

Without SDETs: Engineers take ownership of feature rollouts.

With SDETs: “We keep running into deployment issues, but that’s not my concern. Someone else handles it.“

Firefighting never ends, and engineers never truly understand why things fail.

5. Best Practices Get Ignored

Without SDETs: Engineers rely on TDD, automation, and best practices.

With SDETs: “TDD slows us down. We don’t have proper tests anyway. Manual QA is faster!“

The result? A fragile, unstable codebase.

6. No Dogfooding or Feature Flagging

Without SDETs: Engineers test their own features in real-world conditions.

With SDETs: “Dogfooding is for product managers. Feature flags are complicated and expensive.“

(This is one of the worst arguments I’ve heard from engineers and managers—fire them immediately.)

A Simple Change. A Big Impact.

At one startup, I eliminated all SDETs within two months. The result? Software quality improved. And Product and cross-functional collaboration (XFN) became stronger.

With SDETs gone, engineers owned their work from start to finish. Now, they had to communicate with sales, product, and design to understand why, how, and when features were built.

What Changed?

• TDD became a no-brainer. Engineers now saw its value in protecting their own code.

• Feature flags became essential—allowing engineers to test safely in any environment, including prod.

• Engineers could test on production with product managers, enabling faster and safer releases.

• Dogfooding and gradual rollouts became the norm—ensuring the right user experience before launch.

Final Thoughts

By removing SDETs and QA engineers, we fix ownership, accountability, and software quality. Our engineers become product-driven, responsible, and independent.

And most importantly, they care. They own.

Salam, peace.

Summary of the differences in a table format

Below is a concise table summarizing the key differences and consequences when SDETs/QA engineers are present vs. when they are removed, based on the scenarios described:

Problem	Without SDETs	With SDETs	Impact / 2nd Order Effect
1. “It’s Not My Problem” Mentality	Engineers must handle bugs in production—full accountability.	“Not my problem; the SDET didn’t catch it.”	Shifts blame away from engineers, eroding ownership and accountability.
2. No End-to-End Ownership	Engineers own the entire lifecycle (ideation → deployment).	“I don’t need to think end-to-end; someone else will test later.”	Kills innovation and craftsmanship, as engineers become less invested in overall product quality.
3. No Involvement in Releases	Engineers care about release timing and quality.	“I just write code; SDET/DevOps will handle release.”	Disconnects engineers from the real-world impact of their work, reducing urgency and commitment.
4. Recurring Rollout Problems	Engineers take responsibility for deployment and rollout success.	“Deployment issues? Not my concern; QA or DevOps handles it.”	Continuous firefighting with no lessons learned; engineers don’t gain crucial deployment knowledge.
5. Best Practices Get Ignored	TDD, automation, and strong practices are necessary for stability.	“TDD slows us down; we’ll rely on manual QA instead.”	Leads to a fragile, unstable codebase as testing and automation rigor declines.
6. No Dogfooding or Feature Flagging	Engineers test features in real-world conditions (dogfooding).	“Dogfooding is for PMs; feature flags are too complex/expensive.”	Real-world testing is skipped; features are riskier at launch, and user experience feedback loops weaken.