How regulatory affairs teams are structured

Two people with the same title — Regulatory Affairs Specialist, say — can have almost nothing in common day to day, and the reason is usually structural, not personal. One sits on a team organized around a single therapeutic area and owns a submission end to end. The other sits in a centralized function serving half a dozen business units and never sees the same product twice in a quarter. Neither structure is wrong. Not knowing which one you’re walking into is how people end up surprised by a job that matches the title but nothing else.

Centralized, decentralized, and the tradeoff between them

A centralized regulatory affairs function sits as one group serving the whole company, and the case for it is consistency: one submission process, one set of templates, one place institutional knowledge accumulates instead of scattering across business units that don’t talk to each other. The tradeoff is distance — a centralized RA generalist might touch a dozen products a year without owning any of them for long, which makes it harder to build the kind of deep, product-specific expertise covered in building expertise in one product area. A decentralized structure, with RA staff embedded inside a therapeutic area or business unit, trades that consistency for depth: you may work the same product family for years, know its regulatory history cold, and rarely need to coordinate with an RA counterpart on an unrelated product line because there effectively isn’t one.

What a matrixed team changes about your actual job

Larger companies often land somewhere between the two: a central RA function owns process, templates, and relationships with center-level FDA contacts, while individual RA staff sit embedded with product or therapeutic-area teams and report up through both lines. That split can work well, but it also means your actual manager and your functional lead may want different things from the same week — a product team pushing a timeline, and a central RA function insisting a step in the process not be skipped. Knowing which reporting line has authority over what, before a conflict surfaces, is worth asking about directly in an interview rather than inferring from an org chart you’ll never actually see.

None of this is something you can diagnose from a job posting. How to read a regulatory affairs job posting covers how to work backward from the listing itself, but structure is worth asking about directly and early — in a screening call, not after an offer. The honest version of the question is simple: who do I report to, who else touches my work, and how many other products is this team covering at the same time I’d be covering mine.