The Speed Paradox: Why Pushing Harder Often Slows You Down

Insights from the MassMEDIC Webinar with Bryan Gilpin and Terri Kapur

Every medtech leader I talk to is under pressure to move faster. That pressure is real, and it is not going away. But across the industry, we keep seeing the same thing play out: the harder organizations push for speed, the more they can unintentionally slow themselves down.

That was the starting point for the recent MassMedic webinar I hosted with Terri Kapur, a global R&D executive, medtech industry patent holder, and inventor whose career has taken her through J&J, Boston Scientific, Covidien, Smith & Nephew, Baxter, and Laboratory Paris. She has led R&D teams across therapeutic areas, geographies, and company sizes. She has lived this paradox in more forms than most, and her perspective on how to actually build sustainable development speed is one of the most practical I have encountered.

What follows are the most important ideas from that conversation. If you want the full session, the recording is available in our Knowledge Center.

Speed Is a Symptom, Not a Strategy

When leaders say they need to move faster, they usually mean they need results sooner. What they often misunderstand is what actually creates development speed in the first place.

Terri frames it around a pre-COVID/post-COVID lens that is instructive. Before COVID, engineering teams were generally co-located, supply chains were reliable, and the regulatory environment was predictable enough to plan around. Teams knew where their next components were coming from. Mentorship happened in the hallway. Issues surfaced early because people were solving problems in the same room.

Then COVID hit. Teams dispersed. Trust eroded. The chip crisis arrived. MDR compliance demands exploded. And all of this converged on organizations that were already being asked to do more with the same headcount.

The result: people were busy, but not necessarily working on the right things. Projects slowed, not because teams lacked effort, but because the conditions that enable speed, shared context, psychological safety, prioritization clarity, and real-time problem solving, had been quietly stripped away.

What Separates Teams That Actually Move Fast

When I asked Terri what separated the teams that actually moved quickly from those that only felt urgent, her answer was immediate: agile, co-located teams with a culture of surfacing issues early.

At Boston Scientific’s endoscopy division, she co-located R&D teams with manufacturing sites. The result was design for manufacturability happening in real time, problems surfacing before they became schedule crises, and regulatory documentation that reflected what engineers actually understood rather than what they hoped was true.

At Smith & Nephew, she used what the team called Tiger Teams: cross-functional groups co-located around a shared goal. Same principle, different context. Same outcome.

She also pointed out something I think we underestimate: engineers and marketing people and manufacturing teams do not naturally just get together. It is not organic. It requires deliberate structure, leadership commitment, and years of cultural investment before it takes hold. Fast teams are built, not found.

The 4 Ps: A Framework for Diagnosing Slowdowns

One of the most useful parts of our conversation was Terri walking through her 4 Ps framework, a diagnostic she has used across every organization she has led. The four elements are Planning, People, Process, and Projects (meaning execution).

Here is how she uses it:

•        Planning is strategy: Are you building the right things? Investing in the wrong program burns time and money before you even know you are pointed the wrong direction.

•        People: Do the decision-makers have the right skill sets and judgment? Skill sets are democratized now. Judgment is not.

•        Process: Do your processes enable engineers to do the work, or do they hold people back? Pedantic processes are a speed killer.

•        Projects (execution): Is everyone actually building toward the same goal? Once you know what house you are building, everyone has to be working together to build it.

The framework works because it surfaces root causes rather than symptoms. When teams are slipping, the answer is almost never to add more meetings or more reporting. It is to diagnose which of these four elements is the actual constraint and address it directly.

Terri’s point about diagnosis is worth underscoring: the people who know what is going wrong are usually already in your organization. Engineers feel when prioritization is broken. They can sense when process is getting in the way. They just don’t always have the language, the safety, or the support to say it out loud. Asking the right questions and creating the right environment is the R&D leader’s job.

Predictability Is the Goal, Not Speed

This is the reframe that I think the industry needs most right now: the goal is not to go faster. The goal is to become predictable.

Predictability builds confidence. Confidence builds investment. Investment enables the next program. Speed is the output of an organization that has earned the trust of its leadership and investors by consistently doing what it says it will do.

The mechanism Terri has applied across multiple organizations: front-load the risk. Invest in what she calls technology development before formal product development begins. Identify the killer test methods early. Prototype and iterate in a space where you are not yet on the launch books. Get to a place where you can set confident intervals on your outcomes before you enter the phase-gate process.

When organizations skip this stage because of pressure to enter development quickly, they pay for it later. The rework, the missed milestones, and the extended timelines that frustrate leadership are almost always traceable back to questions that should have been answered before formal development started.

A wise leader once told me: going fast is great, but real success lies in predictability. That has stayed with me. The teams that consistently deliver are not the ones cutting corners to hit a date. They are the ones that invested early, surfaced risk honestly, and built programs on a foundation that did not collapse under scrutiny.

How to Talk to Leadership When the Data Says Slow Down

One of the most practical moments of the webinar came from a live Q&A question: how do you manage expectations with management when you know the team is moving too fast?

Terri’s answer: you almost never tell them you are moving too fast. What you say instead is: there are more risks that need to be mitigated.

Patient safety is always the clearest argument. If data is insufficient around a known safety risk, that is not a negotiation. You raise it immediately and you do not let it go. But for situations short of patient risk, the framing that actually moves the conversation is cost: fix it now, or fix it later at significantly greater expense, or hand a competitor the opening to displace you with a better-performing product.

Leadership responds to data. Bring the evidence. Quantify the risk. Make the investment conversation top of mind before they discover the gap on their own.

Where AI Fits (and Where It Does Not)

We spent some time on AI, both Terri’s experience using it operationally and our own at Suntra.

Terri has used AI-powered natural language search tools to mine historical R&D data at two companies, allowing engineers to query old test results, complaint data, and project archives in ways that previously took weeks. The time savings are real and the downstream value, catching recurring failure modes before they surface in manufacturing at scale, is significant.

At Suntra, AI tools for engineering, particularly on the software side, have changed meaningfully in the last twelve months. We are using them to accelerate development, identify hidden risks, and improve how we manage program complexity. The velocity gains are real.

But here is the thing both Terri and I kept coming back to: AI does not replace judgment. The critical transition from technology development to product development, the stage gate that sets the entire trajectory of a program, requires experienced people who have done this before and can read what the data is actually telling you. You can augment that with AI. You cannot substitute it.

The Shared KPI Problem

The last theme I want to pull from the Q&A: what do you do when there is no shared urgency across departments?

Terri’s answer was direct. Shared KPIs, driven from the top and translated meaningfully by each leader, are the only reliable mechanism for organizational alignment. If departments are compensated differently, they will prioritize differently. If leadership does not establish the common objective, no amount of project management will create it.

This is hard in larger organizations. Leaders may be in different states, running different P&Ls, operating inside different incentive structures. But if the outcome really matters to the business, the work of alignment is non-negotiable. It does not happen on its own.

What This Means in Practice

The organizations that consistently bring better products to market faster are not the ones pushing hardest. They are the ones that have done the upstream work: built psychologically safe teams, invested in technology development before product development, created the conditions for problems to surface early, and established the shared KPIs that align incentives across functions.

That is sustainable development speed. Everything else is just motion.

If this resonates with what you are navigating right now, the full webinar recording is available in the Suntra Knowledge Center. And if you want to talk through how these principles apply to a specific program, get in touch with us here.