Practical Blog

Knowledge Platform

Practical Blog

Knowledge Platform


Ten ways surgeons and software developers should be alike

When I was a child I had an operation on my shoulder. It was a scheduled operation, nothing urgent. And it left me with an ugly scar on my back. Today, it’s still very notable after all those years. Also still painful during season changes.

Roll the clock forward some 40 years, my youngest son had an operation right after birth. He was in a critical condition, and, in order to save his life, the main artery and vein in his neck were bypassed to connect him to an infant life support machine (ECMO). Despite the urgency and complexity, his scar is hardly noticeable. Despite his slim chances of survival, doctors treated him in both operations – connecting and disconnecting from ECMO – such that everything, cosmetic side effects included, will be as professional as they possibly can.

What makes the difference between a top notch surgical unit to a mediocre to a poor one?

What makes the difference between a top notch software team to a mediocre to a poor one?

The books “Better” and “The Checklist Manifesto” by Atul Gawande give us a peek into the characteristics that differentiate a mediocre surgeon practice from a better-and-always-improving one.

The resemblance between a medical team and a software team is so strikingly similar, that I collected ten practices from the Operation Room (OR) that software teams would be wise to adopt.


Software Team

Operating Room Surgical Unit


A great software team invests time and effort to improve their teamwork skills. They practice to become better in working with one another: socially, professionally, procedurally, whatever-ally.

If it’s a new OR team (as is many times the case), the teammates introduce one another by name, profession and role in the OR


A great software team can deliver a feature end to end – from the moment the first test is envisioned, until the feature is successfully deployed. They host programmers of multiple technologies as required, test experts as required, UX experts as required, and so on.

The team is a cross-functional and feature team: It hosts a surgeon, sometimes more than one, nurses, an anesthetist – all skills and professions to successfully complete the operation


A great software team invests time and effort to improve knowledge and skill sharing among its members. At any point, a master of one skill will guide a journey-person to improve their craft, who will, in turn, guide a novice of that practice. They will increase their Bus Factor in each and every required skill.

The team hosts attending physicians – who completed a specific specialty, residents – graduates who are acquiring a specific specialty, and interns – graduates of medical school who are not yet licensed to practice independently


A great software team defines the desired outcome of a feature they are working on. Typically they practice Acceptance Criteria to specify the successful end result. They plan their work frequently and in reaction to unfolding reality.

The specifications they produce are automated so their equipment (test frameworks) will become greener as they progress in the feature development.

Before an operation, the OR team prepares itself: what is the required procedure, where is the initial incision, what is the current condition of the patient, known allergies and other relevant information


Before starting to work on an feature, a great software team create a “sterile” work environment: The CI is clear of any red tests, the IDE is clean of old items, required tools for the feature are ready (e.g JMeter, DB profiler, …), the desks are tidy, and so on.

Before an operation, the OR is prepared: sterilized, required tools prepared and organized, emergency equipment checked and ready, and so on.


Before starting to work on a feature, a great software team specifies and automates negative and edge-case tests to verify that unintended side effects do not occur – or are immediately fixed.

Before an operation, the team prepares for typical complications: how many sponges to prepare, how many blood transfusions to order, what extra equipment should be available and ready.


A great software team designates a teammate to attend to all interruptions and escalations while they are working on a feature: pushing back on non urgent interruptions, answering questions that don’t require interrupting the rest of the team, fixing the CI/CD if broken (or calling an expert in), and so on. 

Note that this “circulating programmer” is not synonymous with the Scrum Master. It can be a SM’s job, but not necessarily.

During the operation, the circulating nurse is acting outside the sterile area: getting additional equipment ready, answering the phone, calling in additional experts in unexpected situations, updating the family


The team automatically runs all the relevant tests – unit, integration, functional, business-flow, deployment and migration – to validate that they didn’t unintentionally deteriorate other parts of their product. They immediately react and either fix such mishaps or roll their changes back. Tests are run as frequently as possible, implying that tests runtime is fast.

They use modern tools to identify which tests should be run, and they improve their test creation skills, so their CI/CD cycle is as short as necessary and not more.

During the operation, the patient’s vital signs are continually monitored, using visual and auditory queues. If something happens, the team reacts immediately.


Before marking a feature as Done, a great team goes back to the Definition of Done, and validates that they didn’t skip anything that must be completed. Done really means Done for the team.

A great team grows their DoD with time, so they get better at remembering and actioning the important things to check.

Before finishing, a nurse counts all sponges, surgical tools and so on, to make sure nothing is left inside the patient’s body. 


 A great team dedicates time for professional development, both individually and as a team, on multifaceted range of topics: programming, testing, team development, DevOps, architecture, retrospection, leadership – whatever helps them improve their outcomes and well being.

Professional practitioners of the OR – surgeons, nurses, anesthetist – regularly attend continuing professional development to further their knowledge and skills

Ultimately, both OR teams and software teams want to improve the lives and experiences of their clients. I am reminded of a story by Bruce Irvine, following an organizational analysis at a large UK hospital. A team of consultants interviewed 100s of staff at the hospital, and asked about their job. Only one person said something that relates to the primary task of the hospital. It was the cleaning lady, who said: “I am cleaning so patients feel better”.

Not all surgeons and surgical clinics are great, in the same way that not all software developers and software development teams are great.

The important questions to answer are ones that drive teams to greatness. With that in mind, what questions are you asking in your team/s?

What do you do in your own team/s today that makes you a great team?

What would you improve to become one?

What would you add to the list to help other teams become great?


Image by Sasint on pixabay