---
title: Cross-Functional Teams in MedTech: Breaking Down Silos Between R&D, RA, and QA
description: R&D, Regulatory Affairs, and Quality Assurance must work together from day one. Here is how to structure cross-functional MedTech teams that actually ship.
authors: Tibor Zechmeister, Felix Lenhard
category: Team Building, Operations & Scaling
primary_keyword: cross-functional teams MedTech
canonical_url: https://zechmeister-solutions.com/en/blog/cross-functional-teams-medtech
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Cross-Functional Teams in MedTech: Breaking Down Silos Between R&D, RA, and QA

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Cross-functional teams in MedTech are not a culture nicety — they are a structural requirement of MDR. R&D owns the device architecture and the engineering reality. Regulatory Affairs owns the interpretation of the Regulation and how it maps to that architecture. Quality Assurance owns the system that keeps the work traceable and auditable. The three functions must make shared decisions from day one, because every design choice is simultaneously an engineering choice, a regulatory choice, and a quality-system choice. Companies that run the three as silos spend a year at the end of their development cycle trying to retrofit regulatory and quality on top of a device that was not built with either in mind. Companies that run the three together from the first week ship with less rework, fewer Notified Body findings, and a technical file that holds together.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- Cross-functional teams in MedTech mean R&D, Regulatory Affairs, and Quality Assurance making shared decisions from the first week of product development, not three departments working in sequence.
- The silo pattern is the most common failure mode in MedTech startups. It produces a device designed without regulatory constraints, then a regulatory strategy retrofitted to the finished device, then a quality system written to match the retrofit. The Notified Body sees through it.
- MDR Article 10(9) requires the QMS to cover design and development, risk management, clinical evaluation, and product realisation as integrated processes — not as separate departmental workflows.
- The three functions own different questions but share the same decisions. R&D asks "can we build it?" RA asks "is it allowed and under what route?" QA asks "is it traceable?" All three questions must be answered before the decision is made, not after.
- The cleanest meeting cadence for a small startup is a weekly cross-functional design review, a monthly regulatory risk review, and a quarterly management review — each with explicit decision rights and written outputs.
- R&D isolation is the specific failure mode to watch for. Engineering-heavy founding teams often treat regulatory and quality as downstream problems. By the time the technical file is written, the design is frozen in a shape that makes compliance expensive.
- Small teams do cross-functional work naturally when the founders sit in the same room. The discipline is keeping that natural coordination alive as the team grows past ten people.
- The Subtract to Ship move is not adding more meetings — it is removing the silos by making cross-functional ownership the default operating mode, then running the smallest meeting rhythm that keeps it honest.

---

## Why silos kill MedTech startups

A founder Felix coached had built an eight-person team that looked healthy on paper. Engineers in one room, a part-time regulatory consultant reviewing documents in the evenings, a quality manager writing procedures on the side. The product was not shipping. Each function was working hard inside its own lane. Nobody was working across the lanes. The regulatory consultant was reviewing a technical file for a device the engineers had already finished building. The quality manager was writing procedures for a development process that had already happened. The engineers were making design changes without knowing which ones would require a regulatory impact assessment or a risk-file update. The team was busy, the functions existed, and the company was stuck.

The silent rebuild we describe in [The MedTech Startup Operations Playbook](/blog/medtech-startup-operations-playbook-3-to-30) started with a diagnosis nobody in the company wanted to hear: the problem was not the people, it was the shape of the work. R&D, RA, and QA were running as three sequential departments when the device required them to run as one coordinated function. Rebuilding meant restructuring how the three worked together, not just replacing individuals.

This pattern is the most common failure mode we see in MedTech startups. The company does not lack competent people. It lacks a way for the competent people to make decisions together at the moment the decisions are made. Every silo adds weeks to every decision and makes the final technical file a patchwork of retrofits instead of a coherent argument. A Notified Body auditor reads a patchwork file in about an hour and knows exactly what happened.

## The three functions and what each owns

Cross-functional work only works when each function's ownership is clear. Collapsing roles together is as dangerous as siloing them apart.

**R&D (Research and Development) owns the device.** The engineering team — hardware, software, mechanical, electrical, whatever the device needs — owns the product architecture, the design history, the verification and validation, the design inputs and outputs, and the technical feasibility of every decision. In a startup, R&D is usually led by a CTO or a technical co-founder. R&D answers the question: *can we build it, and how?* Crucially, R&D also carries a defined piece of cross-functional QA scope — design controls, design verification, risk control implementation, and software lifecycle management under EN 62304 when applicable — because those are engineering activities with quality records, not a separate QA department's work. We covered this split in [Building a Quality Team in a Startup](/blog/building-qa-ra-quality-team-startup).

**RA (Regulatory Affairs) owns the interpretation.** RA reads the MDR, the harmonised standards, and the MDCG guidance, and translates them into decisions about intended purpose, classification, conformity assessment route, clinical evaluation strategy, and the shape of the technical file. RA owns the Notified Body relationship and the regulatory response to every design change. RA answers the question: *is it allowed, under what route, and with what evidence?* RA thinks in articles, not procedures. In a small startup RA is often carried by the same person as QA, but the body of work is distinct.

**QA (Quality Assurance) owns the system.** QA runs the QMS under EN ISO 13485:2016+A11:2021 — document control, training records, internal audits, CAPA, management review, supplier controls, complaint handling. QA owns the risk management file under EN ISO 14971:2019+A11:2021 as a system, even though the technical risk assessment work happens in R&D. QA answers the question: *is it traceable, documented, and auditable?* QA is the glue between R&D and RA — without QA, the engineering reality and the regulatory strategy drift apart and nobody notices until the audit.

Each function owns different questions. The mistake is thinking they make different decisions. They do not. They make the same decisions, from three perspectives, and the decision is only good when all three perspectives are in the room.

## Shared decisions that break without coordination

There is a short list of decisions that every MedTech startup has to make, and every one of them fails if it is made inside a single function.

**Intended purpose.** The single most leveraged sentence in the entire regulatory file. R&D thinks about what the device does technically. RA thinks about how the wording triggers or avoids specific classification rules under Annex VIII. QA thinks about how the intended purpose threads through every procedure, every training record, and every piece of labelling. An intended purpose written by R&D alone drifts into technical features. Written by RA alone, it drifts into defensive wording that R&D cannot actually deliver. Written by QA alone, it does not exist because QA will not write it without R&D and RA inputs. Intended purpose is the canonical cross-functional decision.

**Classification.** R&D describes what the device physically does. RA applies the Annex VIII rules. QA makes sure the classification decision is documented and that every downstream process scales to the right class. A classification made without all three in the room is either over-scoped (expensive) or under-scoped (non-compliant). Neither is shippable.

**Design changes.** Every meaningful design change is simultaneously an engineering change, a risk-file update, a potential regulatory impact, and a document control event. R&D cannot decide alone whether a change is "minor" or "significant" — those words have regulatory meaning that only RA can assign, and QA has to log the decision into the change control system for traceability. See [Change Control for MedTech Startups](/blog/change-control-medtech-startup) for the working pattern.

**Verification and validation.** R&D runs the tests. RA decides whether the tests satisfy the applicable harmonised standards and GSPR. QA maintains the protocols, results, and traceability matrices. A V&V plan written inside R&D without RA input is a plan that looks thorough and leaves gaps at the audit.

**Clinical evaluation strategy.** R&D describes the device's clinical performance claims. RA interprets Article 61 and Annex XIV. QA owns the clinical evaluation procedure in the QMS. Picking between literature, equivalence, and clinical investigation is a decision only the three together can make sensibly.

## Meeting cadence that works

For a small MedTech startup — three to thirty people — the cleanest cross-functional cadence we have seen work is three meetings, each with a defined purpose.

**Weekly cross-functional design review (60 minutes).** R&D, RA, and QA in the same room. R&D walks through every design decision made since the last meeting and every decision pending. RA flags anything that touches classification, GSPR, standards, or the Notified Body interface. QA captures the decisions, the owners, and the document control events. Output: a written decision log. This is the single meeting that prevents silos from forming. Skipping it for a week is survivable. Skipping it for a month is how the silent-rebuild pattern begins.

**Monthly regulatory and risk review (90 minutes).** Same three functions, deeper scope. Review the risk management file under EN ISO 14971:2019+A11:2021. Review any open Notified Body correspondence. Review any changes to the regulatory environment — new MDCG guidance, updated standards, amendments. Review CAPA status. The monthly review is where cross-functional patterns that the weekly review is too fast to catch get surfaced. Output: updated risk file, updated regulatory watch log.

**Quarterly management review (half-day).** This is the management review required by EN ISO 13485:2016+A11:2021, run as a real governance forum rather than a signature exercise. Leadership, plus R&D, RA, and QA leads. Covers QMS performance, audit findings, CAPA status, PMS data if post-CE, supplier performance, training status, and regulatory environment. Real decisions get made and documented. See [Management Review That Is Not Compliance Theatre](/blog/management-review-medtech-startup) for the working model.

Three meetings. That is the whole cadence. Anything more than that at small scale becomes ceremony. Anything less leaves silos room to form. The discipline is running the three rigorously, with written outputs, rather than adding a fourth or a fifth because something feels missing.

## Decision rights: who decides what, together with whom

Cross-functional does not mean everyone decides everything. It means the right people are in the room for each decision, with explicit decision rights so the meeting does not stall.

A simple rule that works for small teams. For each major decision category, name one function as the decision owner, and name the other two as mandatory inputs with veto rights on their own domain.

- **Intended purpose:** RA decides, R&D and QA have veto rights. R&D can veto if the wording describes something the device cannot actually do. QA can veto if the wording cannot be implemented across the QMS.
- **Classification:** RA decides, R&D has veto rights on technical claims, QA has veto rights on documentation consistency.
- **Design architecture:** R&D decides, RA has veto rights on regulatory impact, QA has veto rights on traceability.
- **V&V protocols:** R&D decides, RA has veto rights on standard coverage, QA has veto rights on record structure.
- **QMS procedures:** QA decides, R&D has veto rights on anything that describes engineering work, RA has veto rights on anything that interprets the Regulation.
- **Clinical evaluation strategy:** RA decides, R&D has veto rights on technical feasibility claims, QA has veto rights on procedural execution.

Veto rights only work when they are used sparingly and in writing. A function that vetoes every decision is not collaborating, it is blocking, and the other functions will route around it. A function that never vetoes anything is not engaged, and the decisions it is supposed to protect are drifting unwatched.

## The common mistake of R&D isolation

The specific failure pattern that kills engineering-heavy MedTech startups is R&D isolation. Technical founders build a product the way they would in any tech startup — sprint, iterate, ship features — and treat regulatory and quality as downstream problems that will be handled "before we certify." By the time the product is feature-complete, the design is frozen in a shape that was never reviewed against regulatory constraints. The regulatory consultant arrives, reads the design, and delivers the same sentence founders hate: *"You should have asked me six months ago."*

The damage is concrete. A design choice that would have cost nothing to make differently in week two costs a full redesign in month eighteen. A software architecture decision made without EN 62304 in mind requires reverse-engineering the lifecycle records after the fact. A material choice made without Annex I biocompatibility in mind produces a biological evaluation plan with gaps. A risk analysis done at the end instead of in parallel with design produces hazards that were never actually controlled by the design — only argued around in documentation.

The fix is cultural and structural. Structural: put RA and QA in the weekly design review from week one, even if the QMS is a folder and the RA person is a fractional consultant. Cultural: the CTO has to treat regulatory and quality as first-class design inputs, not as tax collectors. A CTO who rolls their eyes when the RA person speaks is a CTO whose company will pay for the eye-rolls in year three. The [silent rebuild pattern](/blog/medtech-startup-operations-playbook-3-to-30) is almost always downstream of R&D isolation allowed to run for too long.

## How small teams do this naturally

The quiet truth about cross-functional MedTech teams is that three people in a room do it automatically. At 3 people the CEO is the CTO is the RA person is the QA person, or some combination across two or three co-founders. The weekly design review is just the table. The regulatory risk review is a conversation at lunch. The management review is whatever the founders decide on a Friday afternoon. There are no silos because there are no walls.

This is why the Vienna QA manager pattern we describe in [Building a Quality Team in a Startup](/blog/building-qa-ra-quality-team-startup) worked — the quality manager built a QMS around a 3-person company where cross-functional coordination was already happening naturally. She did not have to break silos because the silos had not formed yet. She documented the natural coordination in a way that would survive as the team grew.

The discipline, then, is not building cross-functional coordination from scratch. It is preserving it through the 3-to-10 and 10-to-30 transitions we walked through in [The MedTech Startup Operations Playbook](/blog/medtech-startup-operations-playbook-3-to-30). At 10 people the natural coordination snaps because the founders are no longer in every conversation. At 30 people the functional separation that scaling requires can either preserve cross-functional decision-making in a structured meeting cadence, or it can harden into silos. Which one happens depends entirely on whether the founders recognised the transition and designed the cadence on purpose.

The test for whether your small team is still cross-functional is simple: when a design change happens on Tuesday, does the RA person know about it on Tuesday, or do they read about it in a document review three weeks later? If the answer is three weeks later, the silos are already forming.

## The Subtract to Ship angle

The [Subtract to Ship framework](/blog/subtract-to-ship-framework-mdr) applied to cross-functional teams means: do not add coordination processes until the silos force you to. Add the smallest meeting rhythm that keeps the three functions making decisions together, and refuse to scale it into a ceremony. The default move in struggling companies is to add a fourth weekly meeting, then a fifth, then a steering committee, then a regulatory sub-committee. Every addition feels like rigour and slows decisions further.

Subtraction in team coordination looks like this. Run three meetings — weekly design review, monthly regulatory and risk review, quarterly management review — with explicit decision rights, written outputs, and real attendance by R&D, RA, and QA. Do not add a fourth meeting until one of the three is failing. Do not split any of the three into sub-meetings until the attendance exceeds what a single room can hold. Do not promote an informal conversation into a formal meeting until the informal version has stopped working. Every additional layer is a candidate for removal before it is a candidate for elaboration.

The competence to do this comes from Tibor's and Felix's shared view across the book: more process is not more quality, and more meetings is not more coordination. Real cross-functional work is measured by whether the three functions are making the same decision together at the moment the decision is made — not by how many meetings the calendar shows.

## Reality Check — Where do you stand?

1. When R&D makes a design decision on Tuesday, does RA know about it on Tuesday? If the answer is "sometime next week," the weekly design review is either missing or broken.
2. Can you name, for each of intended purpose, classification, V&V protocols, and clinical evaluation strategy, who the decision owner is and who holds veto rights?
3. Is your quality manager or RA lead in the room when R&D makes architectural decisions, or are they handed the architecture afterwards to document?
4. Does your CTO treat regulatory and quality as first-class design inputs, or as downstream tax collectors?
5. When was the last time a design change was vetoed — or rerouted — by RA or QA in a weekly meeting? If "never," either the meeting is not running or RA and QA are not actually empowered.
6. Do you have three standing cross-functional meetings (weekly design, monthly reg/risk, quarterly management review), or more, or fewer? If more, which one can be cut? If fewer, which one is the first to add?
7. Are the decisions from each cross-functional meeting captured in writing, with owners and deadlines, or do they live in people's memories?
8. If your company grew from its current size to double tomorrow, would the cross-functional coordination survive the transition, or would it silently snap?

## Frequently Asked Questions

**What does "cross-functional" actually mean in a MedTech startup?**
It means R&D, Regulatory Affairs, and Quality Assurance making shared decisions at the moment the decisions are made, not three departments handing work to each other in sequence. In practice, it means RA and QA sitting in the weekly R&D design review from week one, with explicit decision rights so the meeting produces real outcomes. The opposite pattern — silos — is the most common failure mode in MedTech startups.

**Why can't R&D, RA, and QA just work in parallel and meet occasionally?**
Because the decisions they each own are actually the same decisions viewed from three angles. Intended purpose is simultaneously a technical claim, a regulatory trigger, and a QMS thread. Classification is simultaneously an engineering question, an Annex VIII question, and a documentation question. If the three functions work in parallel and synchronise monthly, the decisions get made unilaterally and then retrofitted, which is how technical files end up as patchworks that Notified Body auditors can see through in an hour.

**How many cross-functional meetings should a small MedTech startup have?**
Three standing meetings cover the full scope at small scale: a weekly cross-functional design review, a monthly regulatory and risk review, and a quarterly management review under EN ISO 13485:2016+A11:2021 clause 5.6. Each with explicit decision rights and written outputs. More than three becomes ceremony; fewer than three leaves silos room to form.

**Who owns intended purpose — R&D, RA, or QA?**
RA owns the decision, because intended purpose wording triggers specific classification rules under Annex VIII and has to be defensible to the Notified Body. R&D holds veto rights on anything the wording describes that the device cannot actually do. QA holds veto rights on anything that cannot be implemented consistently across the QMS. All three must be in the room when the intended purpose is finalised, and it must be documented as a cross-functional decision.

**What is R&D isolation and why is it dangerous?**
R&D isolation is the pattern where technical founders build a product the way they would in any tech startup — iterating on features without regulatory or quality input — and treat MDR as a downstream problem to be solved before certification. By the time the product is feature-complete, the design is frozen in a shape that is expensive or impossible to certify cleanly. The fix is putting RA and QA in the weekly design review from week one, even if the QMS is a folder and the RA function is a fractional consultant.

**Does EN ISO 13485 require cross-functional teams?**
Not by that name. But EN ISO 13485:2016+A11:2021 clause 5.5 requires defined responsibility, authority, and communication across the organisation, and clause 7.3 requires design and development to integrate risk management, verification, validation, and design transfer as coordinated activities. In practice, satisfying those clauses in a small company means running R&D, RA, and QA as a coordinated cross-functional unit rather than as separate departments. MDR Article 10(9) reinforces this by requiring the QMS to integrate regulatory strategy, risk management, clinical evaluation, and product realisation as connected processes.

**When do cross-functional teams need formal structure versus informal coordination?**
At 3 people, cross-functional coordination is automatic because the founders are in every conversation. At 10 people, informal coordination snaps and has to be replaced with a structured meeting cadence — this is the most fragile transition. At 30 people, the structure has to be robust enough to survive functional separation without hardening into silos. The discipline is preserving the natural coordination from the 3-person stage through each transition, not building coordination from scratch later.

## Related reading

- [The MedTech Startup Team: Key Roles You Need Before and After CE Marking](/blog/medtech-startup-team-key-roles) — the hub post with the seat map cross-functional work sits on top of.
- [Building a Quality Team in a Startup: QA/RA Roles That Actually Work at Small Scale](/blog/building-qa-ra-quality-team-startup) — the QA/RA split and the cross-functional QA scope inside engineering.
- [The MedTech Startup Operations Playbook: From 3 People to 30](/blog/medtech-startup-operations-playbook-3-to-30) — the scaling companion that describes when natural coordination snaps.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology behind the meeting cadence discipline.
- [Building a Lean QMS for MedTech Startups](/blog/lean-qms-startup) — the QMS build approach that supports cross-functional work.
- [Hiring Your First Quality Manager for MedTech](/blog/first-quality-manager-medtech) — timing for the first dedicated QA hire.
- [Hiring Your First Regulatory Affairs Person](/blog/hiring-regulatory-affairs-startup) — timing for the first dedicated RA hire.
- [Management Review That Is Not Compliance Theatre](/blog/management-review-medtech-startup) — the quarterly forum at the top of the cadence.
- [The No-BS MDR Guide for First-Time Founders](/blog/no-bullshit-mdr-guide-first-time-founders) — first-time-founder framing that pairs with this post.
- [DIY vs. Hiring a Regulatory Consultant](/blog/diy-vs-mdr-consultant) — how external help fits into a cross-functional team.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10 (general obligations of manufacturers), Article 10(9) (quality management system integrating regulatory strategy, risk management, clinical evaluation, and product realisation). Official Journal L 117, 5.5.2017.
2. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clause 5.5 (responsibility, authority, and communication), clause 5.6 (management review), clause 7.3 (design and development).
3. EN ISO 14971:2019 + A11:2021 — Medical devices — Application of risk management to medical devices. The risk management process as a cross-functional activity across design, regulatory, and quality.

---

*This post is part of the Team Building, Operations & Scaling category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. If the three functions in your company are still running as silos, this is the post to hand to your co-founders before the next design review — and then actually put RA and QA in the room.*

---

*This post is part of the [Team Building, Operations & Scaling](https://zechmeister-solutions.com/en/blog/category/team-operations) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*