Healthcare Performance Engineering Manager — Workflow Response Readiness

The mandate

A healthcare workflow can be technically available while staff remain unable to complete the next operational step. Slow retrieval, interrupted submission and delayed status updates create different forms of waiting, and a restart that restores the application may leave unfinished work in an ambiguous state. This manager will lead performance engineering for three selected scheduling, record-access and service-coordination workflows, building evidence that distinguishes responsive screens from usable, recoverable processes under realistic operating demand.

The five-engineer team needs a consistent route from operator expectations to a testable definition of readiness. Workflow owners will identify the relevant task sequence, interruption points and permitted recovery behaviour; the manager translates those inputs into workload and observation plans. Staff shift changes, bursts of concurrent access and repeated attempts after slow responses require explicit treatment. A response-time target will be assessed at the relevant workflow boundary rather than applied indiscriminately to every technical call.

Recovery is a material part of the remit. Tests must show what happens to an interrupted task, whether its state is discoverable and whether resumption duplicates work or silently abandons it. The manager will compare performance before, during and after constrained service, preserve evidence of queue recovery and distinguish an engineering defect from an unresolved operational expectation. Any claim that a workflow is safe or clinically suitable belongs to the authorised healthcare and product reviewers, not to the performance team.

Team authority covers work allocation, technical reviews, development conversations and the performance evidence submitted for release consideration. Engineering owners decide code and infrastructure changes; product and service leaders accept operational priorities; the authorised release forum determines whether remaining limitations are acceptable. The manager may recommend delay or a restricted operating envelope on performance grounds but cannot approve clinical protocols, determine patient treatment or sign healthcare compliance conclusions. Testing uses approved synthetic or appropriately controlled datasets and access routes.

The first twelve months concentrate on establishing workflow baselines, interruption tests and a predictable review service that operators and release teams can use. Thereafter, the manager continues to develop engineers, investigate changed workload patterns and keep readiness evidence current as the service evolves. Employment is permanent and open-ended. The initial programme is a delivery focus for a continuing five-person engineering function, not a twelve-month employment contract or an appointment to direct wider healthcare operations.

What you will own

• Translate workflow-owner expectations into task-level performance criteria, documenting the relevant waiting point, completion state and permitted recovery behaviour before selecting a measurement method.
• Allocate the five-engineer team's work around material workflow risks, balancing planned release tests with investigations and avoiding unexamined growth in low-value measurement activity.
• Design interruption and resumption tests that reveal duplicate submissions, ambiguous task status and delayed backlog recovery, using datasets and access conditions approved for engineering purposes.
• Review latency and completion evidence with operators and product owners, separating implementation constraints from missing workflow decisions and assigning unresolved questions to the correct authority.
• Recommend performance readiness or restricted operating conditions to release reviewers with the supporting test record, known limitations and an explicit account of what has not been demonstrated.
• Develop engineers through observed test design, analysis coaching and technical feedback, ensuring that another team member can explain a result rather than relying on its original author.
• Maintain the workflow performance service's priorities and evidence history, incorporating changed operational patterns while preserving the conditions against which earlier release recommendations were made.

Candidate qualifications

• Offer seven or more years in performance architecture or engineering, with practical work on healthcare technology or comparable operational workflows. Show how you established what a user needed to complete rather than measuring only a technical endpoint. Your account should identify a workflow assumption, the evidence you gathered and a recommendation that changed because task completion or recovery behaved differently from the service's apparent availability.
• Demonstrate the analytical ability to examine concurrency, response-time variation, queued work and recovery after interruption. Explain how you would distinguish a delayed but recoverable operation from a duplicated or lost task, including the observations needed to avoid a false conclusion. Specific languages, infrastructure vendors or monitoring products are not prescribed; credible reasoning, experiment control and an ability to work with the platform's existing measurement tools are essential.
• Show leadership suitable for a focused engineering team through mentoring, review ownership, task coordination or small-team management. You must be able to prioritise competing test requests, provide useful technical feedback and develop an engineer's judgement rather than rewriting every report yourself. Large-scale organisational leadership is unnecessary, but the role requires accountable day-to-day follow-through and willingness to surface a limitation before it becomes an unsupported release assurance.
• Understand the distinction between performance evidence, product usability and qualified healthcare decision-making. Demonstrate disciplined handling of test data and access, involving the relevant owner when a clinical or privacy interpretation is required. Be available for the onsite Hyderabad team cadence and joint workflow reviews. Bring an example of constructive disagreement with a product or delivery owner where a clearly stated engineering limitation helped establish an appropriate operating decision.

Application

Applications for this mandate are received in one way only: through the India Board Terminal's application process. It is automated end to end. Your Executive Passport travels to the mandate holder in its confidential form, your answers to the three questions below are read before anything else in your file, and every stage that follows is recorded on your applications page.

There is no address to write to and no intermediary to call. The mandate holder reads what the Terminal delivers and nothing else, which is what keeps the process the same for every applicant and keeps your name out of it until you release it. Applications close on 9 October 2026. Mandate reference CVU-PER-2026-IND-082.