The Ideal Team SDET

The SDET role comes with a built-in awkwardness most people never name out loud.

A developer writes code. You find what’s wrong with it. You write that down somewhere — a bug report, a Slack thread, a code review comment — and now it exists, in writing, that the thing they spent two days building has a problem. You did your job. They did theirs. And yet, somehow, the relationship is the one carrying the weight of that exchange.

Multiply this by a few dozen times a sprint, across years of a career, and you start to understand why so many SDETs end up either burned out, resented, or both. It is genuinely hard to be the person whose work output is, structurally, “things you missed.” It is harder still when the org around you has quietly cast you as the bottleneck — the gate the release has to pass through, the team that makes Friday afternoons inconvenient.

I’m not going to pretend this part of the job is easy. It isn’t. But it is workable, and how you work it is most of what separates a senior SDET who’s a respected partner to engineering from a senior SDET who is, by year five, mysteriously not getting invited to as many design meetings.

The best framework I’ve found for thinking about this comes from a Patrick Lencioni book called The Ideal Team Player — required reading for every new hire at my company, and one of the few “required reading” picks I’ve actually come around to defending. Lencioni argues that the people you actually want on a team share three virtues: they’re hungry, humble, and smart. Not technically smart — people-smart. Emotionally aware. Reads the room.

The thing I love about the framework is that it’s not a leadership model or a personality test. It’s a posture. And in a role where your daily work is structurally adversarial, posture is most of the game.

Hungry

Hungry, in Lencioni’s sense, is about drive. It’s the quiet self-motivation that picks up loose threads, follows up without being asked, and treats the team’s success — not just your own task list — as the unit of work.

For an SDET, hungry shows up in the small things. You notice the test that’s been quarantined for six weeks and finally fix it. You volunteer to investigate the flaky deploy that nobody’s claimed. You sit with a junior dev for thirty minutes on their first integration test, not because it’s your job, but because the team is better off if their tests are good. You stay curious about the parts of the codebase you haven’t been assigned to.

Hungry is what keeps you from hardening into “the person who runs the test suite.” It’s the difference between an SDET who closes their tickets and an SDET who is quietly making the entire engineering org better, in ways that are hard to put on a performance review but everyone notices.

Humble

Humble is the one this role lives or dies by, so I’m going to spend the most time here.

A bug report is, fundamentally, a description of someone else’s mistake. You can frame it well or frame it badly, but you cannot frame it neutrally — every bug you file is, on some level, a comment on someone’s work.

Which means: you are calling their baby ugly. All day. Every day. That’s the gig.

The single most important thing you can internalize is this: a bug in their code is not a failure of theirs. It is a failure of ours. The test should have caught it. The design should have surfaced the risk. The code review should have flagged the assumption. The pairing should have happened earlier. There are a dozen places, most of them upstream of the developer, where the bug could have been prevented — and several of those places are yours.

Once you genuinely believe this, the way you write bug reports changes. The way you talk in code reviews changes. The way you walk into a postmortem changes. You stop using the word “you” in places where “we” is more honest. You stop framing problems as something a developer did wrong. You start framing them as something the system — including you — let through.

This is not about being soft. The bug is still real. The fix is still needed. The conversation might still be uncomfortable. But there is a vast difference between “this is broken because you didn’t handle the empty case” and “we missed the empty case — I should have caught it in the test plan, and I didn’t.” Both surface the bug. Only one of them is going to make the developer want to keep working with you.

Compassion, in this job, is not a soft skill. It is load-bearing. The SDETs who don’t develop it spend their careers wondering why the devs are short with them.

Smart

Smart, in Lencioni’s framework, is people-smart. It’s the ability to read a room. To know when a developer needs a thorough bug report and when they need a five-minute conversation. To sense when a code review comment is going to land as helpful versus condescending. To notice that the team is exhausted on a Thursday afternoon and choose your battles accordingly.

For an SDET, smart is what calibrates the other two virtues into something useful. Hungry without smart is exhausting to be around — yes, you found another edge case, but did you notice the team is shipping a release in three hours? Humble without smart can read as performative — saying “we” when you don’t actually mean it fools nobody.

The practical version: pay attention to your audience. A senior dev who’s been around the block can hear a direct critique. A junior on their first ticket needs more scaffolding. The product manager wants to know what this means for the release date, not how the race condition works. The same bug, written for three different audiences, should look like three different bug reports.

This is a learnable skill. It’s also the one most often missing in technically excellent SDETs who can’t figure out why they aren’t getting promoted.

What it looks like when one is missing

Lencioni’s most useful trick is what happens with two of the three. The combinations are clarifying, and they map almost too well onto SDETs I’ve watched over the years.

Hungry and humble, but not smart — the well-meaning bull in the china shop. Works hard. Doesn’t grandstand. Files thorough, accurate bug reports that are also tone-deaf. Says “your test is wrong” in a code review without realizing how that lands. The intent is good. The effect is people quietly avoiding them. This SDET is fixable; usually with feedback they didn’t know they needed.

Humble and smart, but not hungry — the universally liked underperformer. Reads the room beautifully. Never causes a problem. Also doesn’t push back on bad design decisions, doesn’t surface the bug that would make Friday inconvenient, doesn’t go looking for the things that nobody asked them to look for. Pleasant to work with, and slowly making the org worse without anyone being able to point at why. The hardest archetype to coach, because nobody wants to be the one to tell them.

Hungry and smart, but not humble — the dangerous one. Drives hard. Reads the room. Wins. Also takes credit for catches that weren’t theirs, throws devs under the bus when something slips through, builds influence at the expense of relationships. This is the SDET who can do real damage, because the surface presentation is “high performer” and the underlying behavior is corrosive. Most orgs only catch it on the way out, in exit interviews from the developers who burned out working with them.

The point of the framework isn’t to label people. It’s to give you a checklist for yourself. Most of us are strong in two and developing in one. The work is figuring out which one is yours, and going at it on purpose.

We failed

If I had to compress this whole post into one sentence: when a bug ships, the answer is never you failed. It’s always we failed.

Mean it when you say it. Trace it back to your own work. Find the test you didn’t write, the question you didn’t ask in the design review, the assumption you let slide because surfacing it felt awkward. There’s almost always something there.

Devs notice. Not the first time. Not the tenth time. But somewhere around the fiftieth time you walk into a postmortem with “here’s what I should have caught,” the relationship shifts. You stop being the gatekeeper and start being a partner. The same bug, from the same person, in the same channel, lands completely differently — because by then, they know whose side you’re on.

That’s the relationship worth building. It takes years. It is worth every year.