Shipping Defects in a QA Manager Job Description

📍 Industrial-Organizational Psychology 📅 July 6, 2026 · 11 min read

Writing a job description in my very first I/O-psychology course taught me that a JD and a software requirement fail for the same reason — my own spec shipped with defects I'd have flagged in anyone else's, and the posting that hired me couldn't pass the same audit either.

For a graduate I/O-psychology assignment I had to write a full job description — role summary, tasks, competencies, a task-importance rating for every line. I chose the role I then thought would be a progression of my role: Quality Assurance Manager. Years later I re-read my submission the way I’d read someone else’s spec, and found the defects — then the 2020 posting I was actually hired against resurfaced, and it failed the same audit. My defects are all still visible in the artifact at the bottom of this post.

Everyone has written a requirement badly. A job posting that reads like a wish list. A ticket that says “make it faster.” A definition of done nobody could actually check. We do it because specifying what “good” means is genuinely hard, and it is easy to mistake describing a thing for defining it.

I learned that in a course that had nothing to do with software. The assignment was to write a job description — the foundational document of I/O psychology, the one every downstream decision leans on — and instead of inventing a role, I wrote the one I’ve lived. Almost the one I’ve lived: my actual title is QA Lead, and the spec I wrote was for a QA Manager — I gave myself a promotion in the requirements. Hold that thought.

The spec I wrote for myself

The role summary came out fluent, because I was describing my own working life. This is the actual opening, unedited:

“An experienced agile team is looking for a seasoned IT generalist with proven expertise managing testing resources in an onshore-nearshore-offshore model and acting as a bridge between business and technical stakeholders. […] An inspired storyteller who is fluent in creating dashboards and using monitoring systems to construct narratives and support continuity. The expert is expected to keep the light on for various projects from inception to completion.”

I still like “keep the light on.” I’m still proud of “inspired storyteller.” And both lines are exactly the problem, because the assignment didn’t want an inspiring paragraph. It wanted ten observable tasks, each rated for importance, each traceable to the knowledge, skills, abilities, and other characteristics — the KSAOs — underneath it. Acceptance criteria for a human being.

So I converted the poetry into tasks you could watch someone do. “Examine configuration files, logs, codes, and legacy documentation to identify breakdown source, out-of-specification errors, corrective measures, deviation reports, and perform trend analyses.” “Conduct elicitation and demo sessions with business stakeholders to assess priorities, protocols, and regulatory requirements, and write and revise the quality control and the risk mitigation plan.” Eleven of those — one more than the template asked for, a detail I’ll return to. The moment I did it, the document changed character: “inspired storyteller” is a vibe, but “builds the dashboard that lets a stakeholder see release risk without asking” is a requirement — demonstrable, checkable, passable, failable.

I didn’t convert it alone, and the reference list at the bottom of the artifact tells you who helped: O*NET — the U.S. Department of Labor’s occupational database, which hands you observable task statements and the KSAOs behind real occupations — and a live QA Manager opening at Epic Games that I used as a benchmark. That’s the honest accounting of where the testable lines came from: I borrowed them from people with a process. The untestable lines were the ones I wrote from the heart.

That’s the entire discipline of a testable requirement, and it’s where most job descriptions and most software tickets fall apart. “Detail-oriented” and “the page should load fast” are the same mistake wearing different clothes. Neither can be passed or failed, so neither is really a spec.

The audit — what I found re-reading my own spec

Here’s where I stop being proud, because a spec is a test object like any other, and mine has defects on the record.

Defect 1: my importance ratings confessed something. The assignment made me rate all eleven tasks from “not important at all” to “crucial/showstopper.” I rated the monthly PowerPoint to C-level executives crucial/showstopper. I rated elicitation sessions with business stakeholders — the task where you actually listen to the people the quality plan is for — somewhat important, the lowest rating I gave anything. Read that back: I speced a job where impressing executives outranks listening to stakeholders. In fairness to the table, it isn’t all vanity — training my teams and mentoring the near-shore (Mexico) and off-shore (India) folks also rated crucial/showstopper. What I discounted was one specific kind of listening: the kind that happens before the plan exists. That’s not a description of QA work. That’s a confession about the organization I was picturing when I wrote it — and nobody flagged it, including me, until this audit.

Defect 2: the QA Manager spec shipped with typos in its own quality gates. My required qualifications ask for certificates from “ITSQB” and “CME.” The bodies I meant are ISTQB (the International Software Testing Qualifications Board) and ASQ’s CMQ/OE (Certified Manager of Quality/Organizational Excellence) — I cited both correctly in my own reference list, then misspelled them in the requirement itself. A quality manager’s job description, requiring credentials from organizations that don’t exist as written. If a candidate can’t be hired against a requirement, the requirement is a defect — and this one is mine, in writing. The comparison that stings: the posting that hired me is recruiter boilerplate, not written by a quality professional, and it still asks for “Testing Certification ISTQB Advanced Level preferred” with every letter in the right place. The generic spec passed the spelling gate. The specialist’s didn’t.

Defect 3: I was too close to the test object. Writing the spec for a job you actually do is the hardest kind, because you keep reaching for how the work feels instead of what it looks like from the outside. That’s the identical trap of writing requirements for a system you built and can no longer see freshly. The unobservable lines survived my own review precisely because they flattered me.

Defect 4: my spec grew while I wasn’t looking. The instruction line still visible under my ratings table says “evaluate your 10 job tasks.” Count mine: eleven. And the competencies section of my submission opens by declaring the role “a hybrid of Data Manager, Communications Manager, Change Manager, and Test Manager” — four managers folded into one imaginary candidate. In my trade this has a name, scope creep, and I catch it weekly in backlogs. It is apparently much harder to catch in a mirror: every place the template gave me a boundary, I wrote past it, because somewhere along the way the document had stopped being a spec and started being a wish.

The control sample: the spec that hired me

The audit turned out to have a second test object. This summer my mid-year review resurfaced the original posting I answered in 2020 — the one that made me a QA Lead — and I read it the way I’d just read my own submission. Its required qualifications include, verbatim:

“Keen attention to detail.”

“Self starter, self motivated, driven individual.”

“Display professional, positive, and approachable attitude/demeanor and discretion.”

Earlier I called “detail-oriented” the classic untestable requirement. It turns out I’m living proof you can be hired against it: nobody has ever observed me passing keen attention to detail — including whoever decided I had. The posting carries no importance ratings, no trace from any qualification to the ability underneath it, and a summary that promises “projects of high complexity” with no way to measure the complexity. By my coursework’s rubric, the spec that hired me would not have passed the assignment.

I want to be precise about that sentence, because it isn’t a complaint about whoever wrote the posting. It’s the thesis with better evidence: the classroom standard was stricter than the industry artifact, and the trap catches everyone — the recruiter who speced my job, and the quality professional who, given a graduate course and unlimited time, wrote his own unpassable spec anyway.

And about that promotion I gave myself: the posting says Lead, my spec says Manager. I didn’t describe the job I had — I speced the job I wanted and labeled it the role I know best. File it with the scope creep of Defect 4: a spec quietly optimizing for what its author wanted to be, instead of what the work is.

What transfers

If you can’t observe it, you can’t hire for it — and you can’t test for it. Every unobservable line in a JD becomes a bias magnet later, because the evaluator fills the vacuum with gut feel; every untestable requirement gets filled with someone’s assumption. This spring, three years after the submission, a different course handed me the vocabulary for what went wrong. In a classic paper comparing traditional job analysis with competency modeling, Sanchez and Levine draw the exact boundary my spec kept crossing: job analysis exists to describe behavior; competency modeling exists to influence it. “Inspired storyteller” was me influencing when the form asked me to describe. With the boundary named, the fix compresses into a checklist that works on JDs and tickets alike:

1. Decide what each line is doing — describing or influencing. Both are legitimate. Unlabeled mixtures are how vibes get into requirements.
2. Write the task, not the trait: something a stranger could watch someone pass or fail.
3. Trace every line to a KSAO — or, in software, to a verifiable behavior. No orphan adjectives.
4. Read your importance ratings back as testimony. They record what you actually optimized for, not what you meant to.
5. Audit the document as if someone you don’t trust wrote it. Someone did: a version of you who wanted to look good.

And re-run the audit on a schedule, because specs rot quietly: that course’s textbook still points readers to www.jobdescription.com as a resource for writing job descriptions — type it in today and you’re redirected to an HR vendor’s sales page. Even the canon needs regression testing.

My throughline is negotiating for clarity, and I have personal stakes here beyond craft. The first required skill on the posting that hired me — listed before a single word about testing — is “Strong communicator (written and verbal): ability to read, write, speak and understand English.” By my own standard, that line is fine: a stranger could watch me pass or fail it. What the spec couldn’t say is that I’d be passing it in a second language, renegotiating it sentence by sentence in every meeting since. And before you credit me with any moral high ground: my own spec demanded of its imaginary candidate “Speech Clarity” and communication “in simple English with clear, concise, and easily comprehensible statements.” I put a stranger under the exact requirement I renegotiate daily. Specs are mirrors all the way down. A job description is clarity under the most pressure — one document that a candidate, a hiring manager, and possibly a court will all read differently. I came into the assignment thinking I’d describe my job. I left having learned to define it, task by observable task. The defects I shipped anyway are the part I’m choosing to publish, because a test report that only shows passes isn’t a test report.

Thanks for reading. For anyone who writes specs, JDs, or tickets: pick your favorite line in one of them and ask whether a stranger could watch someone pass or fail it. Then check your importance ratings — mine knew something about me before I did. And if you can still find the posting you were hired against, audit that one too; tell me what it confessed.

← All articles