The QA Career Path Nobody Draws on the Org Chart

A career transition that exposed a bigger question

I recently made a less linear choice in my QA career, the kind of choice that does not sit neatly on the org chart version of career progression. I chose to leave one role, and I am about to start another. It is a normal professional transition, but it has made me think more carefully about how we describe progression in QA, especially when that progression does not follow the familiar shape of a single technical or managerial ladder.

Career transitions have a way of forcing clarity. You do not only update a CV or prepare for interviews. You also end up explaining your own professional logic back to yourself. You look at the roles you have held, the decisions you have made, the problems you have been trusted to solve, and the kind of work that repeatedly seems to find you. If the path is not obvious on paper, you have to understand the pattern well enough to describe it without sounding defensive.

That is where many mid-career QA professionals can get uncomfortable.

The two paths QA usually recognises

In software testing, we often talk about career growth as if there are two serious directions. One is the technical route: automation, SDET work, test architecture, performance, security, accessibility, CI/CD, tooling, frameworks, and now increasingly AI-assisted testing. The other is the leadership route: Test Lead, Test Manager, Head of QA, QA Director, or some other form of QA management.

Both paths are legitimate. More than that, they are necessary. Teams need deep specialists. Good automation engineers matter. Performance testers matter. Security and accessibility specialists matter. Test architects matter. Strong QA managers matter. People who understand testability, build sustainable automation, design meaningful test strategies, coach teams, and manage delivery constraints are doing work that requires depth, not just job-title ambition.

So this is not an argument against specialisation. It is also not a quiet attempt to turn versatility into a superior moral category. That would be lazy, and it would be wrong.

A strong specialist can solve problems that a broadly experienced QA professional cannot solve at the same level. If your automation framework is brittle, the answer is not simply better stakeholder communication. If your performance testing is immature, delivery awareness will not replace someone who understands load modelling, bottleneck analysis, capacity assumptions, and production-like constraints. If your accessibility testing is superficial, a broad quality mindset will not compensate for missing technical and legal understanding. Depth matters because some problems are deep.

But depth is not the only form of value in QA.

The work that sits between lanes

There is another kind of QA career that is harder to name, and therefore harder to defend in a market that likes tidy labels. It is the career built across test strategy, test planning, defect triage, delivery risk, release readiness, Agile delivery, governance, process improvement, incident learning, stakeholder alignment, and the constant translation work between product, engineering, support, and leadership.

This kind of work is not always glamorous, and it is not always cleanly titled. Sometimes it sits under QA Lead. Sometimes under Test Manager. Sometimes under Release Manager. Sometimes under Quality Engineering, Delivery, Governance, Programme, or some hybrid title that makes perfect sense inside one organisation and almost no sense outside it. The naming changes, but the underlying work is recognisable: helping teams make better quality decisions when the information is incomplete, the delivery pressure is real, and the process alone is not enough.

That work can look unfocused from the outside. It can look like someone moved sideways too often, or did not specialise early enough, or stayed too close to delivery to be considered a pure QA leader, while carrying too much QA judgement to be seen as a pure release or programme person. It can look like being adjacent to several clear paths without fully belonging to any of them.

This is where the confidence issue appears. It is not always a lack of capability. Sometimes it is a language problem. The market is often better at naming narrow expertise than cross-functional expertise.

Job descriptions tend to prefer clean categories because clean categories are easier to hire for. Automation QA. Manual QA. QA Lead. SDET. Test Manager. Release Manager. Engineering Manager. These labels are imperfect, but they are convenient. They allow organisations to describe a vacancy, map it to a budget, compare candidates, and move the process forward.

The actual work of quality is rarely that convenient.

When quality becomes a system problem

In a real delivery environment, especially in large or regulated organisations, quality problems do not stay inside one professional boundary. A production issue may begin with an unclear requirement, continue through weak acceptance criteria, survive because the test approach was based on assumptions rather than risk, remain invisible because the dashboard measured activity instead of exposure, and finally become a release decision made under time pressure. By the time the organisation sees the impact, the problem is no longer just a testing problem. It is a delivery system problem.

This is why cross-functional QA judgement matters.

The person who can follow that thread across the system is doing a different kind of work from the person who only executes the tests, only builds the framework, only owns the release checklist, or only chairs the governance forum. That does not make the work better. It makes it different. It sits in the connective tissue between decisions, incentives, evidence, risk, and accountability.

A QA professional with this kind of background may be able to look at a defect and understand not only its technical behaviour, but its release consequence. They may be able to see that a green test status is not the same thing as meaningful coverage. They may know when a test plan is helping the team think and when it has become documentation theatre. They may understand why a governance checkpoint exists, but still recognise when the checkpoint has become performative control rather than useful risk management.

This is not “doing a bit of everything.” That distinction matters.

Breadth only matters when it becomes judgement

A scattered career and a versatile career can look similar if you only list the job titles. The difference is the through-line. Breadth becomes meaningful only when it produces better judgement. Otherwise, it is just movement.

The through-line might be risk-based testing. It might be release confidence. It might be quality governance. It might be improving the test process across teams. It might be helping organisations understand the gap between what their dashboards say and what their delivery reality is telling them. Whatever the shape, the value is not in having touched many areas. The value is in understanding how those areas interact.

This is where mid-career QA professionals often face a difficult kind of pressure. Early in a QA career, breadth is encouraged. Learn the product. Learn exploratory testing. Learn automation basics. Learn APIs. Learn Agile delivery. Learn how defects move through a workflow. Learn how releases are planned. Learn how teams communicate. Learn enough technical detail to be useful and enough delivery context to avoid testing in isolation.

Then, somewhere in the middle, the expectation changes. The same breadth that made someone useful can start to look suspicious if it has not crystallised into a recognised title. The question becomes: are you technical, or are you management? Are you hands-on, or are you strategic? Are you a test specialist, or are you a delivery person? Are you on the automation path, or the leadership path?

For some people, choosing one of those lanes is the right decision. There is nothing lesser about that. Many QA professionals find depth in automation, performance, security, accessibility, architecture, people leadership, or test governance. A strong career does not need to be broad to be valuable.

The issue is not that lanes exist. The issue is treating them as the only legitimate forms of progression.

Some of the most important quality work happens between lanes. It happens when someone understands enough about testing to challenge weak evidence, enough about delivery to understand sequencing and dependency risk, enough about product to understand customer impact, enough about governance to know why controls exist, and enough about organisational behaviour to know why people sometimes follow a process and still make poor decisions.

The market wants flexibility, but still hires in categories

This is especially relevant in the current market, where QA professionals are being asked to adapt quickly while also proving that their skills remain modern. Companies want automation, AI-assisted testing, faster releases, better engineering ownership, fewer bottlenecks, stronger release confidence, and more efficient governance. They want quality to be embedded in delivery, but they do not always want to pay the coordination cost of making that happen properly.

That creates a strange tension. On one side, the market rewards visible technical signals: automation frameworks, programming languages, CI/CD integration, cloud tooling, AI testing tools, and anything that appears to reduce manual effort. On the other side, the same organisations still need people who can interpret risk, question weak signals, understand organisational constraints, and help teams make decisions that are not obvious from a dashboard.

The tool conversation is real, and QA should not be precious about it. Automation matters. AI will change parts of testing work. Technical literacy is no longer optional for many QA roles. Pretending otherwise is not a serious position.

But tools do not remove the need for judgement. They often increase the need for it.

Automation still requires strategy. AI-generated tests still require review. Dashboards still require interpretation. Release criteria still require context. Defect trends still require someone to ask whether the pattern matters or whether the numbers simply look tidy. Governance still requires someone to understand when evidence reduces risk and when it only creates a paper trail after the relevant decisions have already been made.

A deep specialist may solve one part of this extremely well. A cross-functional QA professional may help the organisation understand how those parts connect. Mature delivery needs both.

Flexibility is not only a generational story

There is also a generational angle here, although I would be careful not to overstate it. As a millennial, I recognise the pressure to be flexible. Many of us built careers through changing delivery models, changing tools, changing organisational structures, changing expectations around Agile, changing ideas about what QA should own, and changing assumptions about where testing belongs in the software development life cycle.

There is a particular irony in being told for years to adapt, only to later find that adaptability can be read as a lack of linearity.

Still, I do not think this is only a millennial story. Plenty of Gen X professionals built non-linear careers before LinkedIn made every professional transition public and searchable. Plenty of Gen Z professionals are entering a market where role boundaries are already fluid, toolchains shift quickly, and “learn one thing forever” is not a credible career plan. The generational point is useful only if it supports the larger argument: some people build careers during periods where the work changes faster than the job titles.

When that happens, flexibility is not a personality trait. It is a professional response to changing conditions.

Sometimes that flexibility becomes a strength. Sometimes it becomes a communication problem. Often it becomes both.

Naming the professional centre

That communication problem is worth taking seriously. If you are a specialist, your title often does some of the explanation for you. Automation Engineer, Performance Tester, QA Manager, Release Manager - none of these labels are perfect, but they give people a rough understanding of the value you bring. If your work is cross-functional, the title may not carry the same explanatory weight. You have to describe the value more precisely.

That does not mean turning a career into a branding exercise. It means being able to say what kind of problems you solve.

For a versatile QA professional, the answer cannot simply be “I have broad experience.” Broad experience is an input, not an outcome. The more useful answer is about judgement: the ability to improve decisions, expose risks earlier, connect signals across teams, challenge false confidence, and understand where process, testing, and delivery pressure interact.

That is the difference between a broad background and cross-functional quality judgement.

One is a description of where you have been. The other is a description of what you can do because of it.

This distinction matters because versatility can be misunderstood from both sides. Organisations can under-value it because it does not fit a clean hiring label. Candidates can over-sell it because “I am adaptable” sounds good, but remains vague unless it is tied to outcomes. Neither version is useful.

A less straightforward QA career path is not automatically more strategic, more resilient, or more impressive than a conventional one. Breadth alone is not a virtue. It can become shallow if it never develops into a clear professional centre.

But breadth combined with judgement is valuable. Breadth combined with delivery experience is valuable. Breadth combined with the ability to translate between teams is valuable. Breadth combined with enough exposure to know when a process is helping and when it is creating performative confidence is very valuable.

What gets missed when this work goes unnamed

There is a form of QA expertise that does not sit entirely in test execution, automation, leadership, or release governance. It sits in understanding how quality actually moves through an organisation: through requirements, design decisions, architecture constraints, sprint pressure, defect triage, release deadlines, customer impact, support feedback, governance forums, and the uncomfortable gap between “the process was followed” and “the outcome was still poor.”

That expertise is harder to package than a toolset. It is also harder to measure, which is probably why organisations often recognise it only after it is missing.

When nobody connects the signals, teams can pass every checkpoint and still release with unresolved risk. When nobody understands how a defect becomes a delivery issue, triage becomes priority theatre. When nobody can challenge a green dashboard, leadership gets confidence instead of information. When nobody can translate between product, engineering, QA, support, and release, each group optimises its own view while the real risk moves between them.

This is the kind of work that often hides behind vague phrases like “good communication” or “stakeholder management.” Those phrases are not wrong, but they are insufficient. The real skill is not being pleasant in meetings. The real skill is knowing what needs to be made visible, to whom, at what point, and with enough context that the organisation can make a better decision.

That is not soft work. It is decision work.

And this is why I think QA needs better language for careers that develop across boundaries. Not because everyone should follow that route, and not because specialisation is too narrow, but because the existing career vocabulary leaves too much important work unnamed.

If the only recognised progression routes are technical depth and formal management, we risk missing the people whose main value is cross-functional quality judgement. These are the people who understand testing but are not only testers. They understand release pressure but are not only coordinators. They understand governance but are not satisfied with evidence for its own sake. They understand process, but they do not mistake process compliance for product confidence.

That is not a vague career. It is a career built around judgement, translation, and system-level understanding.

The practical question is not whether the path looks obvious

The practical responsibility, though, sits partly with the individual. If your path is less linear, you cannot assume other people will infer its value. You have to be more deliberate about naming it. Not defensively, and not with inflated language, but with enough precision that the pattern becomes visible.

What risks do you reduce? What decisions do you improve? What failure modes do you recognise early? What kinds of ambiguity can teams trust you to handle? What changes because you are in the room?

Those are not abstract personal branding questions. They are practical career questions, especially for QA professionals whose work has moved across testing, delivery, release, governance, and process improvement.

So no, I do not think every QA professional needs to become an automation specialist. I do not think every senior QA professional needs to become a people manager. I also do not think versatility should be used as a polite way to avoid depth.

But I do think a less linear QA career can be a legitimate and valuable career, provided it has a professional centre. For some of us, that centre is not a tool, a framework, or a title. It is the ability to understand how quality decisions are made across the delivery system, and where those decisions usually fail.

That is worth being able to explain clearly, especially before the next role, the next interview, or the next time someone asks what kind of QA professional you are.

Disclaimer: The perspectives expressed herein are personal interpretations intended to foster professional dialogue; they do not represent any official stance of current or former employers.