Learning Faster Than the Problem: Building High-Performance Technical Teams Across Pharma's Operating Realities
Dr. Kishore Kumar Hotha, President, Dr. Hotha's Life Sciences LLC
Across innovator pharma, CDMOs, and contract testing labs, the operating realities differ, but the principles of high-performance technical teams do not. Dr. Kishore Kumar Hotha discusses what travels across sectors: learning velocity, surfacing problems early, reconciling experimentation with compliance, and building data integrity as a lived behavior, not just policy.
1. You have operated across innovator pharma, CDMOs, and now a GMP contract testing laboratory. Each sector runs on radically different economics and operating realities. Do the principles of building high-performance technical teams actually travel across these environments — or does every sector need its own playbook?
Every sector has its own playbook. The principles do not change.
Let me put it the way I see it on the ground. An innovative biotech team is building knowledge about a single molecule that may define the company's future. A CDMO team runs a portfolio of compounds simultaneously, each with different clients and timelines. A contract testing laboratory runs hundreds of methods across dozens of clients in a given month, and the work is almost never about “our” molecule. The realities and economics are genuinely different.
But teams that consistently outperform in these settings do almost the same things. They surface problems earlier. They treat feedback as information, not judgment. They run structured experiments even when the answer looks obvious. They keep their leaders fluent in the actual work. They invest in people beyond the role they are in right now.
The right way to think about it: the principles are sector-neutral, but the implementation is sector-specific. A leader who copies a CDMO playbook into a biotech will fail. A leader who ignores the underlying principles anywhere will fail more slowly but just as completely.
2. Let us take them one at a time. What is the team-building challenge unique to the CDMO environment, the thing outsiders consistently miss?
Context-switching.
A CDMO team simultaneously manages four, six, or eight programs — each at a different phase, each with a different client, each with different regulatory expectations. The scientist who spent yesterday troubleshooting an HPLC method for Client A is, this morning, reviewing a stability protocol for Client B and, this afternoon, supporting a pre-approval inspection walkthrough for Client C.
The real cost is not volume, it is cognitive load. Every switch has a tax. Teams that fail in CDMOs do not fail because they are not technically strong. They fail because nobody designed the rhythm around that context-switching reality. Scientists get pulled into too many client calls. Review queues get treated as first-in-first-out when they should be triaged by risk. Knowledge gets stuck in a single person's head because there is no time to write it down.
The principle I have learned the hard way: protect your best people from fragmentation. Not by shielding them from work, but by designing the system so the work arrives in coherent blocks.
3. What are the key challenges of maintaining quality and reliability in a contract testing laboratory or Contract Research Organisation (CRO), and how can they be effectively managed?
The challenge is almost the opposite.
In a contract testing environment, we execute defined methods against defined specifications, at scale, across a large client base. The work is repetitive in shape but never in detail. Every sample is someone else's regulatory risk.
The trap here is boredom and drift. When a lab runs the same assay a thousand times, the quality of the thousandth run is not automatic. Small deviations creep in. Analysts rely on pattern recognition instead of the method. Review becomes a rubber stamp. And in this business, one wrong result — one OOS that should have been caught, one atypical data point that should have triggered an investigation — can damage a client relationship and a regulatory file simultaneously.
The principle in a CRO or contract laboratory is active attention. You design the work so people stay engaged, rotations, cross-training, root-cause exercises, even on clean data, and technical reviews that actually review. You do not let the repetition become invisible.
4. What about innovator biotech and pharma, where the team is building a novel molecule from scratch?
Here, the pressure is different again.
In Innovator Biotech, the team often is the knowledge base. There is no precedent to fall back on for a genuinely novel modality. The analytical and CMC teams write the playbook as they go, under timelines determined by funding rounds or clinical milestones rather than by what the science wants to do.
The risk here is fragility. When knowledge lives in one or two brilliant scientists, the company is one departure away from a six-month delay. When decision-making outruns documentation, you arrive at BLA-enabling work and discover a decision made two years ago cannot be reconstructed.
The principle is deliberate knowledge-building. It means rotating people through the hard problems so expertise is distributed, forcing decisions onto paper at the moment they are made, and treating development reports as a scientific artifact, not an administrative one.
5. Given those very different environments, what core principles actually hold across all of them?
Five, and they are less glamorous than most frameworks make them sound.
One: Learning velocity matters more than talent density. The team that learns faster wins, in any sector.
Two: Problems must be cheap to surface. The earlier a problem arrives on the table, the less it costs to fix. Every cultural signal a leader sends should reduce the friction of bad news reaching them.
Three: Leaders have to stay close to the work, not just close to the people. Distance from the data is the single most common cause of slow, bad technical decisions.
Four: Feedback is information, not judgment. How feedback is framed is as important as its content.
Five: People development is a three-year bet, not a quarterly line item. If your team looks the same in three years as it does today, you have underinvested in it.
None are sector-specific. None are easy either. Everyone contradicts a default behavior most organisations drift into.
6. “Learning velocity” sounds good in a keynote but hard to operationalise. What does it actually look like in a technical team on a Monday morning?
It looks like a meeting design.
The single fastest diagnostic of a team's learning velocity is how they run their technical reviews. A low-learning team spends most of its review meeting on what has been done. Progress reports. Status updates. The conversation is retrospective.
A high-learning team spends most of its review meeting on what is not yet understood. Open questions. Decisions that are still soft. Assumptions the team has not yet tested. The conversation is prospective.
That sounds subtle. It is not. Over a year, the two teams accumulate radically different amounts of insight, one is treating the meeting as a ritual, the other as the place where uncertainty gets compressed.
On a practical level, I tell leaders to try this: at the next program review, reserve the first half for what the team is unsure about, and the second half for progress. Watch how the energy in the room changes. Watch how much faster real issues surface over the following month.
7. Pharma is a regulated industry. Experimentation and learning culture can sound threatening in a compliance context. How do you reconcile those two?
The reconciliation is clean once you separate the two meanings of “experiment.”
In a GMP context, when we execute a validated method against a registered specification, we are not conducting an experiment. That work has to be compliant, reproducible, and defensible, full stop.
But upstream of that, in method development, impurity characterisation, robustness studies, orthogonal technique selection experimentation is exactly what you should be doing. That is where assumptions get tested. That is where you find out what the molecule is going to do in your hands.
Teams that confuse the two fail in both directions. They either run development with a compliance mindset, over-specified, over-locked, unwilling to challenge an early assumption and end up with methods that do not hold up. Or they let experimental thinking leak into GMP execution shortcuts, undocumented variations, and create data integrity problems. The discipline is knowing exactly which mode you are in and behaving accordingly.
8. Data integrity is arguably the most important cultural attribute in a pharma laboratory — and also the hardest to measure. How do you build a team where data integrity is a lived behavior, not just a policy?
You build it by making it unnecessary to cut corners.
Most data integrity failures are not moral failures, they are system failures dressed up as moral ones. When an analyst fabricates a data point, the investigation almost always reveals pressure to deliver against an unachievable timeline, unreliable instrumentation, or a supervisor who punished bad news more harshly than bad data.
The first is simple: do not ask your team to do something they cannot honestly do. If a method is unreliable, fix the method. If the timeline is unrealistic, push back on the timeline. If an analyst says, “This is not ready for release,” reward them for saying it.
The second is visibility. Review your own data before you review anyone else's. Sit with chromatograms. Look at the electronic audit trails, not just the printed report. When a leader sees data themselves, the team knows integrity is not outsourced, it is embedded in how decisions get made.
The third, hardest to build and easiest to lose, is never to punish the messenger. When a scientist raises an OOS, when a reviewer flags a concern, when a junior analyst asks whether a result should be investigated, those are the moments that define your culture. If you respond with frustration or with “find a way to make this work,” you teach the team to stop telling you. Once they stop, the problem becomes invisible. That is when integrity incidents actually happen.
Author Bio
Dr. Kishore Kumar Hotha is President of Dr. Hotha's Life Sciences LLC, a consulting practice focused on complex modality analytical development (small molecules, ADCs, oligonucleotides, peptides, and GLP-1 analogs). He has twenty years of experience in CMC lab operations, regulatory submissions, and technical operations across innovator pharma, CDMOs, and contract testing, including prior senior roles at Veranova, Lupin, Johnson Matthey, and Dr. Reddy's Laboratories. He holds a PhD and an MBA, has contributed to more than ninety regulatory submissions, and has supported several FDA, EMA, and MHRA inspections with zero critical findings.
