San Oo - Abridge
Before you redesign the system, understand the room it serves
San Oo did not start his tenure as CTO of Abridge with a roadmap review. He went to a hospital.
He had joined Abridge, after years building products at Yahoo Mail, Slack, and Notion. Those companies taught him how software behaves when millions of people depend on it, but they also taught him something more specific: great enterprise products do not have to feel like punishment. People can actually want to use the tools they rely on at work.
Healthcare was different. San did not walk into the hospital with a hypothesis. He wanted to see the work before deciding what the product should become. He watched patient encounters. He watched post-op rounds. He watched doctors review notes from nurses and previous shifts, then return to the main terminal to enter more data. He paid attention to the moments where Abridge helped, the moments where it did not yet reach, and the parts of the workflow that still required a human to sit down and type.
Mostly, he noticed the room. Clinical environments do not behave like productivity software environments. Televisions are on. Air conditioning is running. Devices are beeping. Pagers are going off. Hallway conversations leak into the visit. Doctors are trying to listen, reason, document, decide, and connect with the patient in front of them while the environment keeps pulling at their attention. That was the first lesson: a clinical AI product does not get to perform in a clean demo. It has to work inside the noise.
For San, the difficulty clarified the opportunity. Abridge is a healthcare AI company building clinical documentation and workflow tools for health systems. Its product began with ambient clinical documentation, but the company is moving toward a broader platform across clinical notes, coding, orders, decision support, and downstream workflows. That expansion changes the technical problem and raises the bar for trust.
Healthcare Is Not a Productivity App
San’s career has been shaped by products people choose to use. Yahoo Mail, Slack, and Notion all lived in competitive categories where taste mattered. Slack helped redefine what enterprise communication could feel like. Notion did the same for documentation and knowledge work. Both were workplace tools, but their adoption was powered by something closer to consumer product instinct: craft, speed, integration, and the feeling that the product was helping rather than trapping the user.
Healthcare software often runs on the opposite dynamic. CIOs and IT teams buy the system. The organization rolls it out. Clinicians use it because they have to. During his hospital shadowing, San saw the familiar pattern: tools that are critical to the work, but not necessarily loved by the people doing it.
That is part of what he and Abridge CEO Shiv Rao talk about often. The goal is not simply to make healthcare software more powerful. It is to make it reliable enough for health systems, secure enough for sensitive patient data, compliant enough for a regulated industry, and good enough that clinicians actually want it in their workflow. The consumer-product lesson still applies. The difference is that elegance alone is not enough. In healthcare, it has to coexist with reliability, compliance, and clinical trust.
At Slack, San learned to think about software as utility-grade infrastructure. If Slack went down, entire companies could lose their working day. Healthcare raises that standard. If clinical software fails, the consequences can move beyond lost productivity. Lives can be at stake.
That changes the operating model. Abridge does not face a high-query-volume consumer problem. It faces a lower-volume, higher-accuracy problem where quality, latency, privacy, and reliability matter in every interaction. The product does not have to answer millions of casual prompts. It has to perform in high-stakes clinical moments where trust has to be earned again and again.
San came in knowing healthcare would be hard. What surprised him was how many kinds of complexity were stacked on top of each other: clinical, regulatory, technical, operational, and human. That complexity is exactly what makes the work defensible. You cannot model your way out of rebuilding healthcare workflows. You have to understand them. That is why his first move was not to look at the architecture from above. It was to stand inside the workflow and watch.
Healthcare Moves at the Speed of Trust
Inside Abridge, one phrase shows up constantly: healthcare moves at the speed of trust. Shiv repeats it at all-hands, and San heard it quickly enough to understand why it matters. Trust is not a marketing layer in healthcare AI. It is the product constraint underneath everything.
Clinicians need to trust the output. Health systems need to trust the reliability, privacy, and security. Patients need the encounter to feel more human, not less. Every workflow has to earn that trust before it earns a place in production.
The company builds that trust through a mix of clinical expertise, benchmarking, testing, and close partnerships with health systems. Abridge works with innovation lab partners to test, iterate, and gather feedback before broader releases. Internally, clinicians help define and evaluate the quality bar. AI can draft, detect, code, summarize, and route, but human verification remains central.
That boundary matters because in healthcare, the AI can do the work, but the clinician still owns the judgment. San is clear on that point. Automation is not an excuse to remove accountability from the people trained to practice medicine. The system can reduce burden, but it cannot treat verification as optional.
That is especially true because the promise of Abridge is not merely better documentation. San sees clinical documentation as the first step in a broader journey. The note is the foundation for everything downstream: coding, billing, orders, decision support, follow-up, and care coordination. If the initial clinical understanding is wrong, the rest of the workflow inherits the error. Trust has to be built at the beginning, not repaired at the end.
General Intelligence Meets Clinical Reality
Abridge uses frontier models. It also builds its own. San does not treat that as an ideological choice. The company benchmarks continuously across three dimensions: cost, quality, and latency. If a frontier model performs best for a task, Abridge can use it. If an in-house model performs better, the team uses that. The decision walks backward from the user problem.
In healthcare, that often means general intelligence is not enough. Frontier models can look impressive in controlled settings, but the clinic is not controlled. Speech recognition in a noisy clinical environment is a different problem from clean transcription. The model has to separate clinical signal from constant background noise while still understanding overlapping voices and specialized medical language. San said frontier models do not perform as well as people might hope in those conditions, so Abridge does its own in-house post-training with clinical data.
The same is true for tasks like ICD-10 coding based on patient-doctor conversations. Abridge benchmarks against frontier models and open-weight models, then invests vertically where its own models can outperform. That is one of the more important lessons in the article: the frontier model is not always the frontier product.
In healthcare, the best model is the one that works in the workflow. It has to meet the quality bar, operate at the right latency, fit the economics, and withstand the clinical context. Broad capability matters, but domain performance matters more.
San is also thinking seriously about local models. For latency-sensitive real-time tasks, local deployment could offer a better user experience. The question is whether the quality can meet Abridge’s standards. Cost is part of the equation, but it is not the only driver. In a clinical workflow, speed only matters if the answer is good enough to trust.
That calculus became more urgent after a recent model change from a major provider. San described it bluntly: when a company depends too heavily on outside foundation models, it is renting the intelligence. At the flip of a switch, that intelligence can change or disappear. Costs may rise as subsidies fade. Customer promises can become harder to keep. For a company operating in healthcare, that dependency is not just a margin issue. It is a trust issue. The product cannot be built on intelligence the company does not fully understand, control, or have a contingency plan for.
The Legacy System Problem
Strong models solve only part of the problem. They still have to live inside healthcare’s existing infrastructure.
Abridge operates inside a healthcare ecosystem shaped by incumbents, legacy systems, and difficult integration points. The systems it needs to work with were not designed to make third-party innovation easy. Some APIs are poorly documented. Some workflows are opaque. Some integration points are difficult by design, or at least difficult in practice.
San was surprised by how much of the problem lives there. It is an ecosystem where outside companies must operate inside systems they do not control, with limited visibility and limited testing access. That creates a different kind of engineering challenge. Abridge has to move quickly while integrating with infrastructure that often moves slowly.
One response is digital twin development. The company builds internal simulations of third-party systems so it can test against real-world complexity without depending entirely on production access. That gives Abridge more control over quality and helps the team understand how its software will behave inside the messy constraints of actual health systems.
This is the part of healthcare AI that does not fit neatly into a demo. A voice agent ordering an echocardiogram during a simulated visit is impressive. Matching a patient to a clinical trial in real time is impressive. But the work underneath is less glamorous and more important: testing, integration, latency, evaluation, workflow mapping, and making sure the product can survive contact with the systems hospitals already use. That is where a lot of the defensibility lives.
The Super IC and the Software Factory
San is not only rethinking the product. He is rethinking the engineering organization building it, because AI changes the cost of action.
For most of his career, San learned engineering management through familiar assumptions: planning cycles, team structures, manager ratios, code review processes, status meetings, and coordination layers. In the last two years, many of those assumptions have started to break. As implementation becomes dramatically faster, everything surrounding implementation starts to look like overhead.
San has been studying teams built in the last few years and talking with peers about what is changing. His focus has become the distance between decision and action. Can one person own both? If not, how short can the gap become?
That has led him toward a model built around what he calls super ICs: highly empowered, high-agency individual contributors who are self-managed and able to move with speed. The expectation is not just technical skill. It is autonomy, judgment, and the ability to work with agents as part of the build process. His line is simple: if you cannot manage yourself, you cannot manage agents.
That may become one of the defining engineering shifts of the AI era. Engineers are not only writing code anymore. They are directing systems that write, test, review, and repair code. That requires clarity of thought, strong judgment, and the ability to define the right work before the machine begins.
San is already running one project directly with a seven-person team under a clear constraint: 80 percent of the time should be spent building. Not in status meetings. Not in planning rituals. Building. When someone is blocked, they raise it immediately. When a pull request is ready, another person reviews it immediately. San said he did not even need to define a code review SLA. Once the expectation was clear, the team rose to it.
That experiment is informing how he thinks about managers too. Leaders cannot only read about AI-assisted development. They need to use it, build with it, and develop intuition from hands-on work. Otherwise, they will not understand what is changing fast enough to lead through it.
Abridge is also building its own version of a software factory. The human stays at the beginning and the end. At the beginning, people define the spec, architecture, taste, and judgment. Then agents write code, review code, resolve comments, run tests, fix failures, kick off CI, and address CI failures. By the time a human reviews the work, the quality should already be much higher.
San knows this will create new bottlenecks, and that is the point. Solve one bottleneck and another appears: code review, deployment, monitoring. To San, that is not a sign of failure. It is evidence the team is moving faster.
That is also why he cares about velocity as an engineering metric. Uptime, reliability, and security are non-negotiable. Everyone watches them. But velocity, time compression, and project delivery reveal whether the organization is actually learning how to build in the new environment.
The New Default: Try It Again
San is trying to keep his own assumptions from hardening too quickly. When asked what people underrate about AI, he pointed to the ceiling. He catches himself thinking AI cannot do something. Then he gives it a first pass and watches it work better than expected.
His advice is to build the intuition directly. Try the tool. Push the limit. If you tried something two months ago and it failed, try it again now.
That mindset fits the moment. San joined Abridge at a time when healthcare AI is expanding from ambient documentation into a broader clinical workflow platform. The product surface is widening. The engineering organization is changing. The models are improving. The dependency risks are becoming clearer. The industry is moving, but not at the speed of hype. It is moving at the speed of trust.
That makes San’s first day in the field feel less like a nice anecdote and more like a leadership principle. He started by watching the room, not the roadmap, the demo, or the architecture diagram. He watched the room where the product has to work.
The room is noisy, constrained, and unforgiving. It is full of legacy systems, human judgment, and clinicians who do not have time for software that gets in the way. For a CTO coming from Slack and Notion, that is the challenge: bringing consumer-grade product thinking into a world where trust matters more than delight.
Abridge does not just have to make AI useful. It has to make AI dependable enough to disappear into one of the hardest workflows in the economy. That is why San started his first week in a hospital instead of a conference room. Before he could redesign the product, he needed to understand the room it had to serve.