Tech Lead

Key Responsibilities

• Own the engineering of the whole platform — the Python and FastAPI backend, the React web application, the mobile application, the Artificial Intelligence (AI) plug-ins and the cloud they run on — and be the single person accountable for whether it ships
• Lead through senior engineers who each own a group of modules, with the quality, cloud and mobile engineers shared across both, so no module has one person who cannot go on leave
• Split the work by what a hospital does rather than by technology: one team on the clinical side — records, orders, laboratory, radiology, pharmacy — and one on everything a hospital runs on — reception, billing, insurance, canteen, administration
• Set the technical direction and record it as decisions a new engineer can still read a year later, including the ones that were wrong and why they were changed
• Stay hands-on: review every change that touches a clinical record, a price, a ledger or a claim, and write the parts nobody else should be left alone with — tenancy, the billing engine, the synchronisation layer
• Be accountable for the pilot hospital going live, and for the fact that a ward at two in the morning is not a place where software gets a second chance

Delivery You Can Commit To

• Sequence the work so two teams run in parallel without waiting on each other, and say in the week it becomes likely — not in the week it becomes certain — that a date will move
• Hold estimates that hold: break work down until the team can commit to it, and treat an estimate that keeps slipping as a specification problem rather than an effort problem
• Own the release path end to end — trunk-based development, migrations only through version control, a deploy anybody on the team can run, and a rollback that has actually been tested
• Own what happens when it breaks at three in the morning: who is called, what they can see, and how the hospital is told before it telephones us
• Keep the weekly picture honest — what shipped, what slipped, what is at risk and what you need from the business — in a pack somebody outside engineering can read

Correctness, Because This Is a Hospital

• Hold the line on the paths where being wrong is not a bug but a harm: allergy and interaction checks, dose limits by age and weight, critical results that must reach a human, and money that must reconcile to the rupee
• Make every write auditable and attributable — who did it, when, and what it replaced; corrections by reversal, never by silent overwrite
• Build multi-tenancy in from the first table: one platform, many hospitals, and no path by which one can see another's data
• Own the security posture — access control, audit, encryption, secrets, and a third-party Vulnerability Assessment and Penetration Test the platform passes before go-live rather than after
• Own the standards work that cannot be compressed at the end: Fast Healthcare Interoperability Resources (FHIR) R4, Health Level Seven (HL7) version 2 from analysers, Digital Imaging and Communications in Medicine (DICOM) worklists, and Ayushman Bharat Digital Mission (ABDM) with Ayushman Bharat Health Account (ABHA) linking

The People Part, Which Is Most of It

• Take a team that is already building and make it better at it — and own the hiring as it grows, being honest in the interview about what the job is: a hospital, a deadline and a real pilot, not a research project
• Grow the senior engineers into people whose review is trusted, so that within a year the hardest module is not yours to review
• Give feedback in the week it is useful, run the performance conversations, and make the growth path visible to a junior engineer who cannot yet see it
• Protect the team from thrash — take the interruption yourself, decide, and let them keep building
• Pair the engineers with the ward: every one of them should have sat beside a nurse or a billing counter before they design for one

Working With the Business

• Work with the Product Delivery Manager on scope and sequence, and with the Business Analyst on turning a hospital's actual documents — a tariff sheet, a rate contract, a scheme circular — into something the software can hold
• Say no with a reason and an alternative, in a sentence a hospital administrator can repeat to their own board
• Own the technical half of a customer conversation: what the platform does today, what it will do by go-live, and what it will not do at all
• Keep the demo honest — a screen shown to a hospital is a promise, and this team does not show what it cannot build

• Own the engineering of the whole platform — the Python and FastAPI backend, the React web application, the mobile application, the Artificial Intelligence (AI) plug-ins and the cloud they run on — and be the single person accountable for whether it ships
• Lead through senior engineers who each own a group of modules, with the quality, cloud and mobile engineers shared across both, so no module has one person who cannot go on leave
• Split the work by what a hospital does rather than by technology: one team on the clinical side — records, orders, laboratory, radiology, pharmacy — and one on everything a hospital runs on — reception, billing, insurance, canteen, administration
• Set the technical direction and record it as decisions a new engineer can still read a year later, including the ones that were wrong and why they were changed
• Stay hands-on: review every change that touches a clinical record, a price, a ledger or a claim, and write the parts nobody else should be left alone with — tenancy, the billing engine, the synchronisation layer
• Be accountable for the pilot hospital going live, and for the fact that a ward at two in the morning is not a place where software gets a second chance