Head of Engineering Job Details Location Role type Work model Reports to Direct reports

Auckland Permanent, full-time Hybrid Chief Product and Technology Officer Yes

Last updated September 2026 SEVENTY PERCENT OF NEW ZEALAND'S GENERAL PRACTICES RUN ON CODE WE WROTE Medtech Global has spent 30 years building technology that supports clinicians across New Zealand and Australia. We have deep institutional knowledge of how healthcare actually works, and a clear-eyed view of where it needs to go. Our software sits at the centre of clinical workflows in hundreds of practices. When a GP opens a patient record, a nurse runs a recall or a lab result lands in an inbox, it is our code doing the work. When that code is fast, reliable and secure, care gets easier. When it freezes, fails or leaks, a clinician's day gets harder and a patient's care is put at risk. In this business, engineering quality is clinical quality. We are building what comes next, without stopping what works today - this is the key balance this role needs to keep in mind. This role owns the engineering organisation that keeps the established portfolio running and improving, and builds the new products and platforms that will define Medtech's future. It owns the people, the practices, the platform and the architecture that make both possible. WHY THIS ROLE EXISTS Medtech has products that clinicians have trusted for three decades, an integration platform that is among the most capable in Australasia, and engineers with irreplaceable knowledge of how healthcare software actually behaves in the real world. What we have not had is a single owner of how we engineer, someone accountable for the standard of the work, the health of the systems, the flow of delivery and the growth of the people doing it. Our engineering landscape is the product of 30 years of decisions: Delphi, .NET, Java and SQL Server, on-premise and hosted, built by in-house teams and external vendors. Some of it is excellent. Some of it has not been touched in years because nobody who understands it is still here. Engineering practices vary from team to team. Test automation, observability and deployment pipelines are uneven. Too much knowledge lives in too few heads. And we are in the middle of bringing development capability back onshore, forming new teams around products, with some leaders and engineers who have not worked this way before. At the same time, AI is changing how software is built. The teams that learn to engineer with AI, safely, measurably and at scale, will outbuild the teams that do not. We aspire to be one of them. So this role carries two mandates at once: Run and modernise the established estate. These products carry the revenue and the clinical trust. They need reliability, performance, security, a predictable release cadence, and a deliberate path from legacy to modern that never puts the installed base at risk. This is engineering under real operational constraint. Build the new. New products, new architecture, new platforms, often with AI at their core. Small teams, fast feedback, modern stacks, cloud-native from the first commit. Here the currency is speed of learning, clean foundations and the discipline to build only what is needed.

- 2 -

These require different engineering trade-offs, different risk appetites, different metrics and often different people, and the failure mode is running one playbook across both. Engineering a thirty-year-old clinical system like a startup breaks the business that depends on it. Engineering a new product like a thirty-year- old clinical system kills it before it ships. Holding both, without confusing them, is the core technical and leadership demand of this role. WHY THIS IS WORTH DOING This won't be easy. Healthcare is complex, regulated and high-stakes. The legacy is real, the transformation ahead is significant, and some of what needs fixing has been unaddressed for years. But there are very few engineering roles anywhere with this combination: software used by most of a country's general practices every single day, two markets, a stack spanning Delphi to cloud-native, a genuinely open field on AI in clinical workflow, an in-house engineering organisation being built largely from scratch, and a mandate broad enough that the answer is not already written down. The Head of Engineering will build the engineering organisation Medtech runs on for the next decade. It is a rare opportunity, and we are looking for someone who sees that clearly, wants their fingerprints on it, and intends to enjoy the process. WHAT THIS ROLE DOES Own engineering strategy and technical direction • Own the engineering strategy across the portfolio and the logic that connects it to the product and business strategy: what we build on, what we invest in, what we modernise, what we hold, and what we retire. • Own architecture and technical direction. Set the target architecture for the established estate and for new products, and make the path between them explicit and incremental. • Make the big technical decisions visible and reversible where possible. Distinguish the decisions that are cheap to change from the ones that are not, move fast on the first, and slow down deliberately on the second. • Own technical investment as a portfolio, not an afterthought: technical debt, modernisation, platform and reliability work planned, funded and traded off in the open with product - never absorbed quietly. • Lead engineers as the organisation grows, build an architecture capability within engineering. Design documents, architecture decision records and design reviews as normal practice, not ceremony. Run the established estate like the business it is • Own the reliability, performance and security of the products our customers use every day. Define service levels that reflect what clinicians actually experience, measure against them, and act when we miss. • Diagnose before fixing. Chronic performance and stability problems get root causes, evidence and a measured result, not a patch. • Eliminate single points of knowledge. Document, pair, rotate and automate until no system depends on one person or one vendor. • Own operational excellence: incident response, blameless post-incident reviews that actually change things, and a weekly operational review that looks at the numbers, not the anecdotes. Build the new • Own the engineering of new products and platforms: modern, cloud-native, API-first, secure and observable from day one. • Stand up small, autonomous teams with single-threaded ownership, tight feedback loops and real customers early - and give them paved roads so they spend their energy on the product, not the plumbing. • Build for the interface with the established estate. New products in this business do not get to ignore the systems already in every practice; integration and interoperability are first-class engineering concerns. • Know when to stop. Build the smallest thing that produces a real answer, and be as willing to delete code.

- 3 -

Design the delivery system • Co-design how work flows from idea to production and into customers' hands - team design, ways of working, branching and release strategy, environments and tooling. • Co-design teams around products and value streams, with clear ownership of what each team builds and runs. • Move us towards continuous delivery: small batches, automated testing, feature flags and progressive rollout, so that releasing is routine and rollback is boring. • Own the engineering side of release credibility. Committed dates and regulatory deadlines matter more to our customers than any single feature. • Instrument delivery - deployment frequency, lead time, change failure rate, time to restore, escaped defects and predictability, and use the data to improve the system • Partner with product as a peer. Shared ownership of scope, sequencing, the quality bar and technical investment, with the trade-offs made transparently Own quality engineering • Define and own the quality engineering strategy across every team: test automation, coverage standards and quality gates built into the pipeline. • Shift quality left. Quality engineers work alongside developers from the first conversation, and every engineer owns the quality of what they ship. Testing is a discipline, not a phase. • Design in the non-functional qualities - performance, reliability, resilience, accessibility - rather than discovering them in production. Test for failure deliberately, before a customer finds it for us. • In healthcare software, quality is patient safety. Build the culture and the evidence that treat it with that seriousness, including the clinical safety and regulatory obligations that apply to what we build. Build and own the developer platform and DevOps practice • Own the internal developer platform every team builds on: CI/CD pipelines, infrastructure as code, environments, observability and release tooling. Standardise it, automate it and make the right way the easy way. • Grow and lead the platform and DevOps engineering capability. Treat product teams as the platform's customers and measure the platform by how much faster and safer they ship. • Automate toil relentlessly. If a human does the same operational task twice, ask why a machine is not doing it. • Partner closely with the Head of Security and Infrastructure, who owns the hosting and production estate, disaster recovery, and security and privacy. You own how software is built, tested and delivered onto that estate; together you own a clean handshake between the two and a shared incident model. Embed security and privacy into engineering practice • Own the engineering side of security: secure coding standards, dependency and supply-chain hygiene, secrets management, code review practice and automated security testing in the pipeline. • Make secure development the path of least resistance. Security and privacy are designed in from the first sketch, not reviewed at the end. • Work with the Head of Security and Infrastructure to turn findings into fixed code, with owners, dates and verification, and to evidence our controls for customers, auditors and regulators. • Make sure every engineer understands their role in protecting patient data. Lead engineering in the age of AI • Make AI-assisted engineering standard practice across every team: coding assistants and agents, AI code review, test generation, documentation, incident analysis and, critically, understanding and modernising legacy code nobody has touched in years. • Govern it properly. Clear guidance on what tools can see which code and data, how AI-generated code is reviewed and tested, and where human judgment is non-negotiable. • Measure the value and the cost. Know whether AI is making us faster and better or just producing more code. • Partner with product on AI in our products: the architecture, evaluation, guardrails, evals, cost and operational reliability of AI capabilities running inside clinical workflow.

- 4 -

Lead, build and grow the engineering organisation • Lead the engineering chapter - software engineering, quality engineering, platform and DevOps engineering, and architecture. Engineers work day-to-day in cross-functional product teams and report through engineering leadership to you. • Own the full people cycle: hiring, onboarding, performance reviews, career frameworks, promotion, training and development. • Every hire should make the team better than it was. • Build engineering leaders, not just engineers. Develop the engineering leads and managers who run teams, and build a bench that outlasts you. • Own the continued build-out of in-house engineering capability: structured knowledge transfer, the right mix of permanent staff and partners, and a deliberate plan to own the knowledge needed to build, run and evolve our products independently. • Manage engineering partners and vendors to the same standard as our own teams: clear outcomes, visible quality, and no work we cannot see. • Set clear expectations and hold people to them. Feedback early, specific and kind. Lead situationally, recognise great work, and deal with underperformance. HOW YOU WILL WORK Work backwards from the customer and the business outcome. Every engineering standard, platform investment and architectural decision should trace to something a clinician, a practice or the business will feel. The key operating beliefs we borrow from the best-run engineering organisations, and expect fluency in: • Context, not control. Give teams the context - the problem, the constraints, the outcome - and let them decide how. Highly aligned, loosely coupled. Leaders set direction and remove obstacles; teams make the calls closest to the work. • Freedom and responsibility. Trust people by default, give them real ownership, and hold them to the outcomes that come with it. Add process only where it prevents a real, repeated failure - and remove it when it stops earning its place. • You build it, you run it. The team that writes the software owns it in production. Nothing is thrown over a wall - not to QA, not to operations, not to support. • Security and privacy are engineering concerns. Patient data flows through everything we build. Every engineer owns the security of their code, and secure development is a baseline expectation in every team, not a gate at the end of a release. • Mechanisms, not good intentions. Good intentions do not scale; mechanisms do. When something goes wrong, build the tool, the check or the process that stops it happening again. • Reliability is a feature, and it has a budget. Define service level objectives from the customer's point of view. When reliability is healthy, ship faster; when the budget is spent, stabilise first. • Blameless learning. Incidents are system failures, not personal ones. Review them without blame, share what was learned widely, and make sure the fix actually lands. • Small batches, fast feedback. Small changes, deployed often, behind flags, observed in production. Speed and stability are not a trade-off - high-performing teams get both. • Write it down. Significant decisions start as a written document that others can read, challenge and improve. Clear writing is clear thinking, and it outlives the meeting. • One-way and two-way doors. Most decisions are reversible - make them quickly and close to the work. Reserve deep deliberation for the few that are not. • Paved roads, not gates. Build golden paths that make the secure, reliable, observable way the easiest way. Teams can leave the road when they have a reason; most will not need to. • Break things on purpose. Test resilience deliberately, in controlled conditions, so production failures are rehearsed rather than discovered. • Talent density. A small team of excellent, well-supported engineers outperforms a large average one. Hire for it, grow for it, and protect it. • Psychological safety with high standards. Engineers raise problems early, challenge each other and admit mistakes because it is safe to - and do it inside a culture of clear expectations, honest feedback and real accountability. • Be a player-coach, and go deep. You will not be shipping features every day, but you will be in the work when needed: reading the code, reviewing the design, sitting in the incident, running the query, pairing on the pipeline. The credibility of this role is built in the work, not the title. Be fluent in modern AI - in how you work, and in how we build.

- 5 -

• In your own practice. You use AI tooling daily in the actual work of engineering leadership - reading unfamiliar code, reviewing designs, analysing incidents, drafting standards, and pressure-testing your own decisions. • In how the organisation works. Raise the AI capability of every engineer - the tooling, the habits, and the judgment about where AI accelerates good work and where it produces confident nonsense at speed. AI-generated code is still our code, and we own its quality, security and maintainability. • In the product. You understand what current AI systems can and cannot reliably do, how they fail, what they cost to run, and how their quality is evaluated. You know what it takes to run an AI capability in production - evaluation, monitoring, guardrails and fallbacks - not just to demo one. • Responsibly, because this is healthcare. Patient data, clinical safety, data sovereignty, privacy and a clean audit trail are engineering requirements from the first line, not a compliance review at the end. You should be able to tell us where you would refuse to let AI near the code or the data, and why. Hold the tension, don't resolve it. Everything above is capability. The three that close this section are about balance, where each asks you to carry two opposing things at once rather than pick a side. • Be visionary when needed, pragmatic always. Set the long-term technical direction clearly, then make the small, deliberate improvements that compound. Progress is made in well-designed iterative steps. • Diagnose before you solve. Our engineering landscape has complexity built up over decades. Understand the system before reaching for solutions. Root causes matter more than symptoms. First principles matter more than inherited practice. • Take the work seriously and yourself lightly. This is hard, consequential, and often genuinely fun. WHAT SUCCESS LOOKS LIKE AT 12 MONTHS Working backwards from where we aspire to be: • An engineering strategy and target architecture exist, are written down, are understood by the teams and the executive, and name what we are modernising, holding and retiring. • Every product and service has a clear owning team, and every team can build, test, deploy and run what it owns. • The established estate is more reliable: service levels defined from the customer's point of view, measured and trending the right way, and chronic performance problems diagnosed to root cause and fixed. • Delivery predictable and measured: deployment frequency, lead time, change failure rate and time to restore baselined, reported honestly and improving, and a published release cadence being met. • A standard developer platform in place: every team shipping through consistent, automated pipelines with infrastructure as code, observability and security checks built in. • Quality engineering embedded: automated test coverage growing on the products that matter most, quality gates in every pipeline, and escaped defects falling. • Security built into how we build: secure development standards adopted, supply-chain and dependency risk managed, and security findings closed with owners, dates and evidence. • At least one new product or platform built on the modern foundations and in customers' hands, proving the paved road works. • AI-assisted engineering standard practice across every team, with clear governance and honest measures of value and cost - and engineering ready to run AI capabilities in the product safely. • Critical knowledge owned by Medtech: no system dependent on a single person or vendor, and the onshore engineering teams operating with their own rhythm and leadership. • Engineering capability materially stronger: assessed honestly, roles corrected, gaps hired, career framework and performance cycle running, and engineering leads being actively coached. • Engineering is a trusted partner to product and the executive. The person in this role is someone the CEO and CPTO take into a board room, a customer meeting and an incident bridge with equal confidence. OUR TECHNOLOGY Our established portfolio runs on Delphi, .NET, Java and SQL Server across on-premise and hosted deployment models, with Microsoft Azure as our cloud platform and Azure DevOps as our engineering

- 6 -

toolchain. Our integration platform exposes modern FHIR APIs to a growing partner ecosystem and connects practices to the wider health system in both countries. New products will be built on modern, cloud-native stacks with AI-enabled tooling at their core. The Head of Engineering is responsible for making the whole landscape coherent - raising the bar on the legacy portfolio and the new platform at the same time, and building the bridge between them. WHAT WE'RE LOOKING FOR Essential • 12+ years in software engineering, with at least 5 years leading engineering teams, including leading through other leaders (teams of teams) • Proven ownership of both sides of the mandate - you have kept a mature, revenue-critical system reliable and moving forward, and built something new on modern foundations, and can articulate why you engineered them differently • In-depth experience with at least one cloud platform: Azure, AWC, GCP. • Real architectural depth - you can set a target architecture, evaluate trade-offs, review a design and hold a credible technical conversation with any engineer in the organisation • Delivery system design - you have designed team structures, ways of working and release practices that measurably improved flow, predictability and quality, and used delivery data to diagnose and improve the system • Strong DevOps and platform engineering background - you have built or significantly improved CI/CD, infrastructure as code, observability and developer platforms • Quality engineering leadership - you have defined test strategies, built test automation and quality gates, and got the best from quality engineers in a cross-functional model • Secure development practice - you have embedded security into engineering standards and worked alongside a security function to shift it left • Strong people leader - you have run performance reviews, built career frameworks, hired well, dealt with underperformance, and developed engineers into leaders, with the ability to lead with empathy • Strong with AI in engineering - you use it daily yourself, and you have led its adoption across a team with measurable results and sensible governance • Evidence-first temperament. You will not accept a metric without knowing how it was measured, or a technical claim without seeing the data behind it • Excellent communicator - you can explain an architectural trade-off to a board, write a clear standard, run an incident calmly, and give direct feedback at every level Strong advantage • Experience building AI capabilities into products - evaluation, guardrails, cost management and running AI in production, ideally in a regulated setting • Legacy modernisation done well. You have moved a large installed base from older technology towards a modern architecture incrementally, without breaking the business that depended on it • Health sector experience - PMS, EMR, clinical systems, health-tech - or another regulated, high- consequence domain • Healthcare interoperability - FHIR, HL7 or integration platform and partner API experience • Experience with Delphi, .NET or SQL Server-based systems at scale, or leading teams that own them • Experience bringing outsourced or vendor-delivered engineering in-house, or building an engineering organisation largely from scratch • Microsoft Azure and Azure DevOps at depth • On-premise or hosted to SaaS transition experience - multi-tenancy, cloud migration, and the operating model changes that come with them • Multi-market experience across New Zealand and Australia, or comparable two-market complexity, including data sovereignty obligations • Site reliability engineering practice - service level objectives, error budgets and resilience testing OUR PRINCIPLES Here are the operating beliefs that shape every decision we make: • Diagnose before you solve - understand the situation fully before reaching for a solution; root cause over symptoms

- 7 -

• The treasure is worth finding - hard problems are worth pursuing with conviction; believe the answer exists, even when it is not yet visible • Meaningful work and meaningful relationships - the work matters, and so do the people doing it; we optimise for both • Build great businesses by building great people - the quality of our people and their interactions is the engine of everything we produce • First principles over analogy - break problems to fundamentals rather than reasoning from how others have solved it At Medtech, we value adaptability and recognise that business needs may evolve over time. As such, this position description is subject to change.