Jeffrey Carr

The Work Between the Work

Introduction

This book is not about discovery.

It is not about breakthrough science or elegant mechanisms. It is about what happens after an idea works—and before a patient ever knows it exists.

It is about the space where most biopharmaceutical programs succeed or fail.

I was raised in a middle-class Black family where work was not abstract—it was physical, daily, and necessary. My father was a self-employed HVAC technician. He worked with his hands, solved problems under pressure, and understood that if he didn’t get it right, someone else paid the price. My mother worked in retail, standing on her feet for long hours, navigating customers, schedules, and expectations with patience and resilience.

In our home, education was not treated as a badge or a talking point. It was a responsibility. My parents did everything they could to make sure I had opportunities they never had, not by shielding me from work, but by teaching me to respect it. Long before I ever stepped into a laboratory or a cleanroom, they taught me that work matters, preparation matters, and that people deserve to be taken seriously—especially when the consequences are real.

Those lessons followed me into science.

If you have ever watched a promising process struggle during scale-up, or felt the weight of approving readiness when certainty was impossible, then you already understand the space this book is about. It is the space between intention and execution, between optimism and reality.

Manufacturing Science and Technology—MSAT—lives in that space.

MSAT is rarely visible. It does not fit neatly into organizational charts or conference agendas. Yet it is MSAT that translates possibility into reliability, and innovation into something that can be made again tomorrow, and the day after that, and the day after that.

I have always lived a bivocational life, working as an engineer while serving in pastoral roles at the same time. Over the years, that dual calling taught me something essential: this work is never only technical—it is profoundly human. Long before I led MSAT teams, I spent years in pastoral work, planting a church and walking alongside people under pressure, uncertainty, and real consequence.

That experience shaped how I understand responsibility. Decisions are never abstract. They land on real people—operators working night shift with limited margin for error, teams carrying risks they did not create, and patients who will never know how close a process came to failing. MSAT sits at the intersection of those lives, where judgment, care, and technical rigor must coexist.

Most failures in biomanufacturing do not originate in discovery. They emerge later, when assumptions meet reality, when scale exposes sensitivity, and when urgency outruns preparation. They appear as deviations and delays, but their roots are almost always upstream—in decisions that felt reasonable at the time.

MSAT sits at the center of those decisions.

This book exists because too much of what MSAT knows is passed down quietly—through experience, post-mortems, and hard-earned instinct. It lives in slide decks that are never revisited and lessons that are relearned by each new team. There is little that captures the work as it is actually practiced: interdisciplinary, imperfect, and consequential.

What follows is not a how-to manual. It is not a collection of templates. It is a narrative about judgment, stewardship, and the cost of getting it wrong. It is about learning when to move fast, when to slow down, and when saying not yet is an act of care rather than resistance.

This book is written for those who work in the middle—MSAT professionals, manufacturing leaders, quality partners, engineers, and development scientists who have felt the gap between what is designed and what is executed. It is also written for leaders who want to understand why programs fail not because of incompetence, but because complexity was underestimated.

Most importantly, it is written with the patient in mind. Every decision described here ultimately traces back to them—to the obligation to deliver something that is not just innovative, but reliable. Not just fast, but worthy of trust.

This is the work between the work.

And it matters more than most people realize.

Chapter 1.0 – MSAT: The Discipline No One Discusses

I did not set out to work in Manufacturing Science and Technology.

Like many people in this field, I arrived here indirectly—through training, opportunity, and necessity. I was taught to value preparation, to respect the work done by others, and to understand that decisions made upstream eventually land on real people downstream. Those lessons did not come from a classroom. They came from watching work done carefully, from seeing what happens when it is not, and from being accountable for outcomes that matter.

There are no undergraduate degrees in MSAT. No formal training paths that prepare you for translating an idea into something that must work every time, under pressure, with no margin for improvisation. Most MSAT professionals are assembled, not trained—pulled together from development, manufacturing, quality, engineering, or operations, and expected to integrate disciplines that were never designed to speak fluently to one another.

And yet, once you step into this role, something becomes immediately clear: MSAT may be one of the most consequential disciplines in biopharmaceutical manufacturing, and almost no one is formally taught how to do it well.

MSAT exists in the space between discovery and delivery. Between the optimism of development and the reality of manufacturing. It is responsible for ensuring that what can work in theory will work reliably, repeatedly, and compliantly in the real world—not once, but every time it matters.

This work is often invisible.

When processes run smoothly, MSAT disappears into the background. The batch releases. The milestone is met. Credit flows outward. The system appears stable, and few ask why.

But stability is rarely accidental.

I have seen how easily that stability erodes when assumptions go unchallenged. A process that looked robust in development begins to drift at scale. A step that relied on experience becomes ambiguous in execution. A risk that felt theoretical becomes operational. None of these failures originate from negligence. They emerge from complexity—and from the gap between how work is imagined and how it is actually performed.

That gap is where MSAT lives.

It is also where MSAT is tested.

When something falters, the question comes quickly: Why didn’t we see this coming? It is an understandable question—and a revealing one. It assumes that failure is always obvious in advance, that risk announces itself clearly, and that foresight is simply a matter of paying closer attention.

In reality, MSAT is asked to anticipate failure without the benefit of hindsight, to recognize patterns before they fully form, and to act while certainty is still out of reach. This requires more than technical knowledge. It requires judgment, humility, and a deep respect for the people who will ultimately carry the consequences of every decision.

MSAT is not simply science. It is not simply engineering. It is not simply compliance.

It is integration.

And integration is not something most organizations teach. It is learned slowly, through exposure, through mistakes, and through the responsibility of standing between what is possible and what is dependable.

This chapter begins there.

Chapter 2.0 – Technology Transfer Is Not a Handoff

There is a moment in nearly every program when someone says it—often with relief:

“The process has been transferred.”

The documents are signed. The package is delivered. The meeting concludes. Responsibility shifts. On paper, the work is done.

In reality, the most fragile phase of the process has just begun.

Technology transfer is routinely treated as an event—a handoff from development to manufacturing, from one team to another, from one phase of the lifecycle to the next. The language reinforces this framing: transfer package, handover meeting, ownership shift. Each term implies closure.

But technology transfer is not a moment.
It is not a document.
And it is certainly not a clean break.

Technology transfer is a translation.

2.1 From “Is It Complete?” to “Is It Executable?”

Development and manufacturing ask fundamentally different questions.

Development asks: Can this work?
Manufacturing must ask: Will this work every time?

Those questions sound similar. They are not.

Development tolerates variability because it is searching for understanding. Manufacturing cannot. Development rewards flexibility. Manufacturing depends on constraint. Development optimizes for learning. Manufacturing optimizes for repeatability.

Early in my MSAT career, I remember sitting in an introduction meeting where the tech transfer knowledge package seemed technically sound. The data was there. The slides were polished. As the meeting wrapped up, someone said, “This should be straightforward.” At the time, it felt reassuring. In hindsight, it should have felt concerning.

The question that was never asked was the one that mattered most:

Can this be executed under real manufacturing conditions?

Not by experts. Not once. But by different people, on different shifts, under real pressure.

That question is where MSAT earns its role.

2.2 What Gets Lost in Translation

Every process carries two kinds of knowledge.

The first is explicit. It lives in documents—parameters, ranges, materials, equipment, and defined steps.

The second is tacit. It lives in people—judgment, timing, instinct, and context.

I am currently working on a project that, on paper, appears simple. The process flow is clean. The steps are logical. But the tumor fragmentation step tells a different story. Success depends on sensing resistance, recognizing subtle changes in tissue behavior, knowing when to pause or stop before damage is done. None of that fits neatly into a range or instruction.

In development, this worked because the same experienced hands performed the step every time. That consistency masked the risk. When we began preparing the process for manufacturing, it became clear that the process relied on knowledge that had never been named.

The process didn’t fail.
The assumption that judgment would transfer did.

That is what gets lost in translation.

2.3 Documents Are Necessary—but Not Sufficient

When tacit knowledge becomes visible, the instinct is often to document it away.

I have reviewed batch records where, in an effort to eliminate ambiguity, every nuance was described. Every possible scenario anticipated. The result was a document that was technically complete—but nearly impossible to follow. Operators weren’t confused about what to do. They were overwhelmed trying to see the process through the text.

I once watched an operator pause mid-execution—not because they didn’t understand the step, but because they were trying to reconcile paragraphs of instruction that all applied at once. The batch record had become a wall of words. The flow of the process was gone.

This is the second translation failure.

The first occurs when judgment is assumed and never written down.
The second occurs when documentation attempts to replace judgment entirely and overwhelms the reader.

Both failures come from the same misunderstanding: that transfer is about completeness rather than clarity.

2.4 Ownership Is Not Binary

Another illusion embedded in the idea of handoff is ownership.

Development owns the process—until manufacturing does. MSAT supports somewhere in between.

In practice, ownership during technology transfer is shared, overlapping, and uncomfortable. I have seen teams wait for ownership to be clarified while risks remained unaddressed. I have also seen MSAT succeed precisely because it refused to let organizational boundaries slow necessary conversations.

Technology transfer requires someone willing to stand in the overlap—to hold questions that do not yet belong to anyone else.

That work often falls to MSAT.

2.5 Resisting Premature Closure

One of the most dangerous phrases in technology transfer is “transfer complete.”

When closure arrives too early, learning stops. Engineering runs become confirmation exercises instead of opportunities for discovery. Variability is framed as execution error rather than design signal.

I have learned to be suspicious of anything that feels straightforward too soon.

The healthiest transfers I’ve seen treat completion as conditional. Documented before execution. Understood after first run. Proven only after variability has been observed and addressed.

MSAT adds value by keeping the door open just long enough for reality to speak.

2.6 MSAT as Translator, Not Courier

The most effective MSAT professionals I know do not see themselves as couriers of information. They see themselves as translators of intent.

They ask questions that feel inconvenient early and invaluable later:

2.6.1 What assumptions feel reasonable today?

2.6.2 Where has this process never been stressed?

2.6.3 What will change when this runs at scale, under pressure?

These questions slow things down.

They also prevent failure.

2.7 Why This Matters

Technology transfer matters because this is where most programs quietly decide their future—long before anyone realizes a decision has been made.

It is the moment when optimism hardens into assumption. When what worked becomes what is expected to work. When early flexibility is mistaken for robustness. By the time a process reaches technology transfer, many of its most important behaviors are already being locked in—not by formal approvals, but by what is left untranslated.

When technology transfer is treated as a handoff, responsibility appears to move forward. In reality, risk moves with it, carrying every unspoken assumption that came before. Tacit knowledge that was never named. Judgment that was never translated. Documentation that either said too little to guide execution or so much that it obscured intent. None of these feel dangerous in isolation. Together, they create the illusion of readiness.

This is why downstream failures so often feel unfair. Variability “comes out of nowhere.” Deviations seem disconnected from design. Execution is scrutinized when the process was never designed to be executed by anyone other than its authors. By the time these problems surface, the narrative has already shifted—from Are we ready? to Why did this fail?

Technology transfer is the last point in the lifecycle where these failures are still preventable rather than explainable. It is the last place where curiosity can slow momentum without being seen as resistance, in some cases. After this point, every correction costs more—time, trust, credibility, and often people.

This is also why MSAT is frequently misunderstood at this stage. MSAT is not protecting timelines. It is protecting reality. It is insisting that intent survive contact with execution. That operators are not asked to compensate for design gaps they did not create. That “complete” does not mean “ready.”

If Chapter 1 established that MSAT lives in the space between functions, then this chapter makes something more uncomfortable clear: technology transfer is where that space becomes dangerous if it is ignored.

Because once a process is called “transferred,” the pressure to move forward increases—and the tolerance for doubt disappears.

Which is exactly when someone usually says:

“This should be straightforward.”

Chapter 3 is where we confront what that phrase really means—and why it so often signals trouble ahead.