Job Architecture for Data and AI Roles in Life Sciences

Why Job Architecture Breaks First in Data and AI

Job architecture is the structure underneath every people decision an organization makes: the job families it recognizes, the levels within each family, the criteria that separate one level from the next, and the pay ranges attached to them. Done well, it is invisible. Done badly, it produces a steady drip of arguments about titles, promotions, and offers that nobody can settle because there is no agreed basis for settling them.⁶

Data and AI roles break the architecture before other functions do, for three reasons that compound.

The first is speed of title invention. The vocabulary of this discipline changes faster than any compensation cycle. Analytics engineer was not a common job title before roughly 2018.¹⁷ AI engineer, prompt engineer, MLOps engineer, and machine learning platform engineer all arrived in the years after. Each new title enters the organization through a job posting, not through a design review. By the time compensation looks at it, three people hold it and one of them was hired at a different grade from the other two.

The second is market pressure. Demand for these skills is growing far faster than the workforce that supplies them. The U.S. Bureau of Labor Statistics projects employment of data scientists to grow 34 percent between 2024 and 2034, from about 245,900 to 328,300 positions, making it one of the fastest growing occupations in the economy.¹² The World Economic Forum’s employer survey put big data specialists at the top of its fastest growing roles list, with AI and machine learning specialists close behind.³ When a hiring manager cannot fill a role at the posted range, the fastest way out is a title bump, and a title bump inside a weak architecture is a permanent change to the structure made by one person under pressure.

The third is that life sciences competes for this talent against employers with better developed technical ladders. Technology companies have spent two decades formalizing individual contributor progression. A candidate who has worked inside one of those structures will ask, in a first conversation, what your senior levels look like and whether a principal engineer sits at the same table as a director. If the honest answer is that you have not thought about it, that candidate has already learned something about how the work will be valued.

The symptoms leaders usually notice first

Nobody calls a meeting about job architecture. They call a meeting about one of its symptoms:

• A promotion request nobody can decide. A strong senior data engineer asks what comes next. The only thing above her on the org chart is a manager role she does not want and would not be good at. The conversation ends with a vague promise.
• Two people doing the same work at different grades. One joined through an IT requisition and one through an R&D requisition. Their pay differs by twenty percent and neither knows why.
• An offer that breaks the range. The candidate everyone wants requires a number above the top of the band. Somebody suggests posting the role a level higher to make the math work.
• A resignation that surprises the leadership team. The person who understood how the clinical data actually flowed left for a competitor, and the exit interview says there was no path.
• A pay equity review that cannot be explained. Compensation cannot map the roles to survey benchmarks because the internal titles do not correspond to anything the survey recognizes.

Each of these is treated as an isolated problem and solved with an exception. Exceptions are how an accumulated architecture gets worse. Deloitte’s 2026 outlook survey found that 48 percent of life sciences and health care executives said their board lacked representation in areas such as AI and data science,¹⁵ which suggests the structural gap is not only at the practitioner level. The organization does not have a shared language for what this work is worth.

The Dual Ladder Is the Whole Design

If you fix only one thing, fix this. A dual ladder means two parallel progression paths of equal standing: one for people who lead through management, and one for people who lead through technical depth and scope. Both tracks continue upward past the point where they diverge, and both reach senior levels with comparable pay and comparable standing in the organization.

The reason to build one is not that it is fashionable. It is that the alternative produces two predictable failures at once.

Failure one: you convert your best practitioners into average managers

When management is the only route upward, the strongest technical performers apply for management roles because that is where the money and status are, not because they want to manage. Research on this pattern is unusually direct. Benson, Li, and Shue examined promotion decisions across sales workers at 214 firms and found that organizations weight current job performance heavily in promotion decisions, at the expense of characteristics that better predict performance in the new role. Their estimate of the effort involved in promoting people with lower managerial potential was substantial.⁴⁵

In a data and AI context the damage is doubled. You lose the technical output of a person who was very good at the work, and you gain a manager who is uncomfortable in the role. The organization then loses the person entirely, often within two years, when they realize the mistake and take a senior technical role somewhere that has one.

Failure two: your best technical people have nowhere to go

The practitioner who does not want to manage simply stops progressing. She keeps the same title for four years while her scope grows, watches peers with narrower contributions move up the management track, and eventually treats an external offer as the only available promotion. The market rewards her for leaving, which is exactly the dynamic that produces the external hire premium documented in Bidwell’s work.⁷ Your competitor gets a fully productive senior person who already understands your therapeutic area, your systems, and your inspection history.

What makes an individual contributor ladder credible

Credibility is structural, not rhetorical. Five things have to be true, and each one is verifiable by anyone in the organization who cares to check.

Requirement five deserves emphasis because it is the one organizations resist. Allowing a manager to step back to the technical track without a pay reduction feels like it rewards failure. It does the opposite. It removes the reason people cling to management roles they should never have taken, and it makes the initial move into management a lower-stakes decision, which means more people are willing to try it and the ones who are good at it self-select in.

Leveling Criteria That Actually Distinguish Levels

Most job architectures in life sciences define levels by years of experience. Five to eight years is a senior. Eight to twelve is a principal. This is convenient, auditable, and close to useless. It measures elapsed time rather than capability, it rewards tenure over contribution, and it fails immediately with a candidate who has done unusually broad work in four years or unusually narrow work in twelve.

It also creates a legal exposure that did not exist ten years ago. The EU Pay Transparency Directive requires member states to transpose its provisions by 7 June 2026, and it obliges employers to base pay structures on objective, gender-neutral criteria. Where a pay gap of five percent or more appears between comparable categories of workers and cannot be justified by those criteria, a joint pay assessment follows.⁹¹⁰ Years of experience is not a defense. It is a proxy that correlates with career interruption, which is precisely the kind of criterion the directive is aimed at. In the United States, Colorado’s pay transparency rules go further in a different direction, requiring that where a promotion is treated as an automatic career progression rather than a competitive job opportunity, the requirements for that progression be objective and disclosed to eligible employees.¹¹

The practical replacement is a small number of dimensions that describe the work rather than the worker. Four of them do almost all the useful separation.

Dimension one: scope of the problem

What size of problem is this person expected to take on and finish? A task, a component, a system, a platform used by several functions, or a capability that spans the organization. Scope is not measured by how much the person does. It is measured by the boundary of what they are accountable for. A person who writes excellent pipelines all day at high volume still has component scope. A person who defines how master data will be governed across clinical and manufacturing has capability scope, even if she writes far less code.

Dimension two: degree of ambiguity

How much of the problem arrives already defined? At junior levels, the requirement is written down and the approach is known. In the middle, the requirement is clear but the approach is not. At senior levels, neither the requirement nor the approach exists, and the person’s contribution includes deciding what the actual question is. At the top of the ladder, the person is working on problems the organization has not yet recognized it has.

This dimension is where life sciences differs most from a general technology setting, and it is worth naming why. In a regulated environment, resolving ambiguity is not only a technical act. Deciding whether a dataset is GxP relevant, whether a transformation needs to be validated, or whether a model’s output constitutes a regulatory record are judgment calls with consequences that reach outside the technology function. The ability to make those calls and defend them is a leveling signal, and a strong one.

Dimension three: blast radius of a mistake

If this person is wrong, what breaks, and who finds out? This is the dimension most job architectures omit entirely, and in a regulated industry it is the most discriminating one available.

At the low end, a mistake is caught in review before it reaches anything. In the middle, a mistake causes a rework cycle within the team. Higher up, a mistake reaches a validated system, corrupts data used for a batch disposition decision, or produces an analysis that informs a submission. At the top, a mistake sets an architectural direction the organization spends years living with, or produces a data integrity finding at inspection. Regulators expect the environment, systems, and culture to support accurate, reliable, secure GxP data, and hold senior management accountable for it.¹² Blast radius is how you connect that expectation to individual roles.

Dimension four: reach of influence

Whose work changes because of this person? A junior person’s influence reaches their own output. A senior person’s reaches their team. Above that, influence reaches other teams and other functions: quality accepts a different validation approach because a principal engineer made the case for it, or clinical operations changes how it captures a field because someone showed what the downstream effect was. At the highest levels, influence reaches outside the organization through standards bodies, industry working groups, and published work.

Influence is the dimension people try to fake, so define it by evidence rather than assertion. The test is whether a decision would have gone differently without this person, and whether someone outside their reporting line would confirm it.

Worked Level Descriptors for a Life Sciences Data and AI Family

What follows is a worked six-level individual contributor ladder with its paired management track. Use it as a starting structure rather than a finished document. The level labels matter less than the criteria attached to them, and the pairings matter more than either.

The management pairing

The pairing is the part people skip, and it is the part that makes the ladder real. Publish it. A version that works for most mid-size pharma and biotech organizations:

Two practical notes. First, the tracks should not split below D3. Everyone starts on the technical track and the management option opens at the senior level, which is roughly where people have enough judgment to know whether they want it. Second, resist the pressure to create a D7. Organizations under fifteen hundred people rarely have work at that scope, and creating a level you cannot fill undermines every level below it.

Valuing Regulated Domain Knowledge Without Building a Wall

Here is the question a job architecture copied from a technology company will get wrong. A data engineer who understands GxP, who knows why an audit trail matters, who can look at a transformation and tell you whether it needs validation, is materially more valuable in this industry than one who cannot. She is also considerably harder to hire, because that combination is scarce and the people who have it know it.

The regulatory basis for this is not soft. Under 21 CFR 211.25, personnel engaged in manufacture, processing, packing, or holding of a drug product must have the education, training, and experience, or some combination, to perform their assigned functions.¹³ The FDA’s data integrity guidance addresses training personnel to prevent and detect data integrity issues directly, tying it back to those personnel requirements.¹⁴ The second edition of GAMP 5 leans further into this, putting critical thinking by knowledgeable subject matter experts at the center of how validation effort is scaled.¹⁶ Critical thinking is not something you can procure. It is a property of a person who understands both the technology and the regulatory purpose it serves. And the draft revision of Annex 11, published for consultation in July 2025 and expected to be finalized during 2026, raises the specificity of what organizations must be able to demonstrate about their computerized systems.¹⁸¹⁹

So the value is real. The design problem is that the two obvious ways to reflect it both fail.

The two failure modes

Failure mode one: put GxP years in the level criteria. “Five years of experience in a GxP environment” as a requirement for D4 does reflect that domain knowledge matters. It also guarantees you can only hire people already inside the industry, from a pool that is smaller than your need and getting smaller. You will spend eighteen months trying to fill roles, and you will systematically exclude the strongest engineering talent in the market because they came from somewhere else. It is also exactly the kind of proxy criterion that a pay transparency review will struggle with, since years-in-industry correlates with things that have nothing to do with capability.

Failure mode two: ignore it entirely. Level people purely on technical dimensions, hire from anywhere, and treat regulatory context as onboarding. This fills roles quickly and then produces the outcome everyone in quality has seen: a technically excellent build that has to be substantially reworked because nobody asked the validation question early enough, and a senior engineer who cannot understand why the organization is so slow.

The design that works: a competency strand, not a gate

Treat regulated domain depth as a fifth strand that runs alongside the four leveling dimensions, with its own stages, and map required stages to levels. Do not make it a hiring requirement. Make it a promotion requirement with a defined ramp.

The mechanism that makes this work is the separation between hiring and promotion. You can hire an outstanding engineer from outside the industry into D4 on the strength of scope, ambiguity, blast radius, and influence, and record on day one that her domain strand sits at Aware with a written expectation of reaching Decides within a defined period, along with the support to get there: a named quality partner, exposure to real deviation and change control work rather than a slide deck, and a review point. What she cannot do is get promoted to D5 without reaching Sets policy, and she should be told that at offer stage rather than discovering it at her second review.

This construction does three things at once. It keeps the door open to outside talent, which you need. It makes the value of domain depth explicit and rewarded rather than assumed and invisible. And it gives your existing regulated-industry people, who often feel their hardest-won knowledge is treated as background, a place where that knowledge counts toward advancement.

Drawing the Boundaries That Cause the Most Argument

Three boundary questions generate more internal argument than the rest of the architecture combined. Surveys of practice are not useful here, because the range of what organizations do is wide and most of it is accidental. What follows is a position on each, with the reasoning.

Where a data scientist ends and a machine learning engineer begins

Position: split on production accountability, not on tools, and keep both in one family on one ladder.

The common answer is that data scientists build models and machine learning engineers deploy them. This describes a workflow, not a job boundary, and it collapses the moment a data scientist writes production code, which they do constantly. It also produces an unpleasant status hierarchy where one group is seen as having the ideas and the other as implementing them.

The durable split is accountability. A data scientist is accountable for whether an inference is valid: whether the question was framed correctly, the data supports the conclusion, the uncertainty is characterized honestly, and the result means what it appears to mean. A machine learning engineer is accountable for whether a system behaves correctly in production over time: latency, reproducibility, drift detection, rollback, and, in a regulated setting, whether the deployed model remains in a validated state and whether the change control record is complete.

Those are genuinely different accountabilities and they justify different specializations. They do not justify different job families or different ladders. The four leveling dimensions apply identically to both. Split them as specializations inside one family, and let people move between them without a level change, which many will over a career.

Where analytics engineering sits

Position: analytics engineering is data engineering. Make it a specialization, not a separate family.

The analytics engineer role emerged around 2018 as cloud warehouses and transformation tooling split what had been one overloaded job into two: getting data into the warehouse, and modeling it into something the business can use.¹⁷ The distinction is real work. It is not a separate job family.

The argument for separating them usually rests on the idea that analytics engineering is closer to the business and requires less engineering depth. Both halves of that are wrong in a life sciences setting. The transformation layer sitting between source systems and a regulated report is precisely where lineage, reproducibility, and data integrity are won or lost, and the blast radius of a mistake there is high. Treating it as the lighter role produces a lower pay band, which produces a hiring pool that does not include people who understand what they are handling.

Keep one data engineering family. Recognize analytics engineering, platform engineering, and integration engineering as specializations within it, all leveled by the same four dimensions. If your organization is large enough that the specializations need distinct job codes for market pricing, use job codes. Do not use separate ladders.

Whether AI roles are a distinct family

Position: mostly no, with one important exception.

The pressure to create an AI job family is intense right now, and most of it comes from recruiting rather than from the shape of the work. An AI engineer building applications on top of foundation models is doing software engineering with a new set of components. An AI researcher developing methods is doing data science at the deep end. Neither needs a family of its own, and creating one produces an immediate compensation problem when the AI family gets a premium band and the data engineering family, doing work of equal value, does not. Under the objective-criteria standard that pay transparency rules now impose, “we called it AI” is not a justification.⁹

The exception is AI governance and assurance: the people who evaluate models for regulatory acceptability, run independent validation of AI-enabled systems, and maintain the organization’s position on how AI is controlled. That is a genuinely distinct role, and in a regulated organization it belongs in quality or regulatory rather than in the data function, for the same reason quality assurance does not report to manufacturing. Independence is the point. Build it as a distinct family with its own ladder, deliberately placed outside the group whose work it assesses.

Compensation: Why These Roles Break Your Bands

An architecture that cannot survive contact with a competitive offer is not an architecture. Data and AI roles break existing pay structures in life sciences more reliably than any other group, and it is worth being precise about why, because the causes point to different fixes.

Three separate causes, often confused

Market movement outpacing structure movement. Compensation structures are typically reviewed annually against survey data that is itself six to twelve months old. In a role where market rates are moving quickly, the structure is chronically behind. This is the classic driver of pay compression: the market rate for a job outpaces the increases an organization gives to its tenured people, so new hires can only be attracted at or above what long-tenured staff earn.⁸

Job matching failure. Compensation prices your roles by matching them to survey benchmarks. When internal titles are inconsistent and invented, the match is wrong, and the range you produce is wrong before any market movement happens. This is not a market problem. It is an architecture problem showing up in the pay data, and it is fixed by fixing the architecture.

Genuine geographic and specialization variation. Pay for AI-related skills varies substantially by market, and a single global pay approach for this talent rarely holds together.²⁰ A structure built on one national reference point will break in specific locations for specific specializations, and that is not a failure of the structure so much as a limit on what one structure can do.

What to do instead of breaking the level

The most common response to an offer that exceeds the band is to post the role a level higher. Do not do this. It solves one requisition and corrupts the architecture permanently, because the level definitions now have an exception nobody documented, and the next person leveled correctly will be sitting next to someone leveled a step high with no explanation available.

Better instruments, in order of preference:

• Widen the ranges at senior levels. Individual contributor ranges should get wider as levels rise, because the variation in contribution genuinely widens. A narrow band at D4 and D5 is a structural guarantee of exceptions.
• Use a market reference premium tied to the job code, not the person. If machine learning engineering prices above the family average in your markets, attach a documented premium to that job code and apply it to everyone in it. That is defensible under an objective-criteria standard. A one-off adjustment for one candidate is not.
• Use variable pay for genuinely time-limited scarcity. Sign-on and retention awards do not permanently reset a base that you cannot walk back if the market shifts. Use them for what they are, and stop using them as a way to avoid a conversation about structure.
• Separate geographic differentials from level. Location adjustments belong on the pay range, not on the level assignment. Levels describe work. Geography describes markets.

The new hire who is paid more than the person already doing the job

This is the situation leaders most want to avoid discussing, and the one where avoidance does the most damage. It will happen. The market rate for a role moved fifteen percent while your team member received a three percent increase, and the only way to hire the person you need is to pay the current rate.

The instinct is to keep it quiet. That instinct is now unworkable on three counts. Pay transparency requirements in the EU give workers the right to information about pay levels for categories of workers doing the same work or work of equal value, and trigger a joint assessment where an unexplained gap of five percent or more exists.⁹¹⁰ A growing number of US states require ranges in postings, which means your existing team can read the range for their own job on your careers page. And people talk. The only real question is whether the affected employee hears it from you or from a colleague.

The honest handling has four parts, and it has to be built into the process rather than improvised each time.

1. Run a same-level equity check before the offer goes out, not after. When an offer exceeds the current pay of anyone at the same level doing comparable work, that surfaces automatically as part of offer approval. The hiring manager and HR see the exposure before it is created, not after.
2. Hold a correction budget outside the annual cycle. Compression created at hire cannot wait eleven months for the merit cycle. A ring-fenced off-cycle adjustment pool, with a documented basis, is the standard remedy and the one most often recommended.⁸²¹ If your finance partner resists funding it, price the alternative: the fully loaded expense of replacing a senior person who leaves plus the productivity gap of the external replacement.
3. Tell the affected person before they find out. Name the market movement, name the correction you are making and when, and do not pretend the situation is other than it is. This conversation is uncomfortable exactly once. Discovering it independently is a permanent change in the relationship.
4. Make within-level pay differences explainable in the same four dimensions. Two people at D4 can legitimately be paid differently based on demonstrated scope, ambiguity handled, blast radius carried, and influence exercised. If you cannot explain a difference in those terms, you do not have a pay variation. You have either a leveling error or an equity problem, and both need fixing rather than explaining.

That last point is the connective tissue of the whole design. The leveling dimensions are not only for promotion decisions. They are the vocabulary in which every pay decision gets justified, to the employee, to a works council, and to a regulator or auditor asking how the structure works.

Who Owns the Architecture and How It Stays Alive

Job architectures decay. They decay through title invention, through exceptions granted under hiring pressure, and through level criteria that were written once and never revisited while the work changed underneath them. Preventing that requires clear ownership and a small number of recurring commitments.

Split ownership between two accountable people

This is the pairing the article’s premise depends on. HR owns the architecture as a system: the job families, the job codes, the pay structure, the market pricing, and the equity and transparency obligations attached to it. Technology leadership owns the level criteria and their application: what D4 means in practice, whether a given person meets it, and whether the criteria still describe the work.

Neither can do the other’s job. HR writing technical level criteria produces generic descriptors that could apply to any function and therefore separate nothing. Technology leadership managing the pay structure produces a series of well-intentioned exceptions and a structure that cannot survive a pay equity review. The failure mode to watch for is one side quietly conceding to the other, usually under hiring pressure, which produces an architecture that exists on paper while the real decisions get made elsewhere.

Five commitments that keep it alive

That last commitment is where life sciences differs from every other industry, and it is worth being explicit. When an inspector asks how you know the person who built and maintains a GxP system is qualified to do so, the answer runs through the job description, the level criteria behind it, and the training record mapped to both. An architecture where five people hold four different titles for the same work makes that answer hard to give. The regulatory expectation under 21 CFR 211.25 is straightforward, and the FDA’s data integrity guidance connects training on data integrity directly to it.¹³¹⁴ Job architecture in this industry is a quality system input, not only a talent tool. That framing tends to be the one that finally gets the work funded.

Sequencing the work

Organizations that try to do all of this at once produce a large document and no change. A workable sequence over one to two quarters:

Conclusion

Job architecture is unglamorous work that senior leaders tend to delegate and then inherit the consequences of. In data and AI roles, the consequences arrive faster and cost more than anywhere else in a life sciences organization, because the market is tight, the vocabulary changes yearly, and the people affected are the ones whose knowledge is hardest to replace. The organizations that handle this well are not the ones with the most elaborate framework. They are the ones that made a small number of structural decisions and then held them: a dual ladder with real levels and real pay parity, leveling criteria based on the shape of the work rather than years served, an honest way to value regulated domain depth that does not close the door to outside talent, and a compensation approach that surfaces awkward truths early rather than hoping nobody notices.

The specifically life sciences part of this is worth restating, because it is the part a framework borrowed from a technology company will always miss. In this industry, the blast radius of a technical mistake reaches into validated systems, submission data, and product quality decisions. The judgment required to work well inside that environment is scarce, it takes years to build, and it deserves to be recognized in the level criteria rather than assumed. And because job descriptions and training records are inspectable, the architecture is not only a talent instrument. It is part of how you demonstrate that the people running your regulated systems are qualified to run them.

Sakara Digital works with pharma and biotech organizations building the data and AI capability that regulated work now depends on, including the organizational structure underneath it. If you are looking at a set of inconsistent titles, a promotion path that runs only through management, and pay bands you would not want to defend in a review, and you want an independent perspective on where to start, we are happy to have that conversation.

For Further Reading