Software Delivery Lead Cape Town

📌 OPPORTUNITY OVERVIEW:-Confluent is actively recruiting for a Software Delivery Lead position in Cape Town. This is an excellent opportunity for professionals in the Information Technology sector looking to advance their careers.

🎯 IDEAL CANDIDATE PROFILE:-We are seeking talented individuals with the following profile:• Experience Level: 10 - 15 years • Educational Background: Others or equivalent• Industry Focus: Information Technology• Location Preference: in Cape Town

💼 WHY THIS ROLE MATTERS:-The Software Delivery Lead position is an important role within the Information Technology sector, offering meaningful career development and professional growth opportunities.

📈 CAREER DEVELOPMENT INSIGHTS:-Your extensive experience in Information Technology qualifies you for leadership positions. This role offers the chance to shape industry practices and organizational direction.

📋 APPLICATION GUIDANCE:-When applying for this Software Delivery Lead position, ensure your CV highlights:• Relevant experience matching the 10 - 15 years requirement• Educational qualifications in line with Others• Specific achievements in the Information Technology field• Any certifications or specialized training

🌍 SOUTH AFRICA JOB MARKET CONTEXT:-The Information Technology sector in South Africa continues to show strong demand for skilled professionals. This position represents a valuable opportunity in the current job market.

Salary: Market Related Job Type: Permanent Sectors: Investment Technology Reference: 206017 Job Type: Permanent Sectors: Investment Technology Reference: 206017 Sectors: Investment Technology Reference: 206017 Reference: 206017

Vacancy Details

Employer: Confluent

Software Delivery Lead

Role purpose

Own engineering craft standards across all development teams, while leading a team engineers. Drive the engineering function to success in line with the company’s technology strategy.

Organisational context • Development function comprises approximately nine delivery teams (two internal, 7 external) with Product Owners attached. • Technology leadership is split three ways across infrastructure, data, and software/product delivery, reporting into the COO. This role sits inside the software and product delivery function.

Accountabilities — Part 1: Team leadership (the line half)

1. Delivery

• Accountable for the team’s committed delivery: predictability of the sprint or cycle, and quality of what ships. • Owns technical breakdown, sequencing, and estimate integrity in partnership with the attached Product Owner. • Owns the team’s technical design decisions within agreed architecture guardrails; escalates where a decision sets precedent for other teams. • Protects the team from unplanned work; makes the cost of interruption visible rather than absorbing it silently.

2. People

• Line management: one-to-ones, performance conversations, development plans, progression cases, and underperformance handling. • Owns onboarding of new engineers into the team to a defined ramp standard. • Owns retention risk in the team — identifies and escalates flight risk before it becomes a resignation. • Recruits for their own team and participates in panels for others.

3. Financial services specifics

• Accountable for the team’s adherence to change control, auditability, and data protection obligations. Not a compliance officer — accountable for the engineering practices that make compliance verifiable. • Accountable for release safety in revenue-bearing hours: no unmanaged deployment risk against live sales channels.

Accountabilities — Part 2: Practice ownership (the influence half) Pillar 1 — Code quality and review discipline - Defines and maintains the code review standard: what gets reviewed, by whom, against what, within what turnaround. - Owns static analysis and quality gate configuration as a shared standard, not per-team preference. - Publishes a periodic read on review health across teams (turnaround time, review depth, bypass frequency) and works the outliers with the relevant leads. Pillar 2 — Testing strategy and defect prevention - Owns the definition of done and the test pyramid expectation across teams. Accountability for testing itself sits with the QA Team Leader Pillar 3 — Architecture guardrails and technical decision hygiene - Maintains the architecture decision record practice and the guardrails inside which teams decide autonomously. - Runs the technical design review forum for decisions that cross team boundaries. - Maintains the technology radar: what’s adopted, trial, hold, and retired. Owns the case for retirement. Pillar 4 — Engineering capability and career pathing - Owns the engineering competency framework and progression criteria — the technical mirror of the Product Owner capability work already running. - Designs and runs the engineering capability programme: internal clinics, pairing rotations, technical mentoring pairings. - Owns the engineering onboarding curriculum for the whole function. Pillar 5 — Hiring bar - Owns technical assessment design, interviewer calibration, and the consistency of the technical bar across all teams. - Audits hire quality after the fact — ramp time, first-year performance distribution — and adjusts the process. Pillar 6 — Tooling and developer experience - Owns the developer toolchain standard and the case for consolidation where nine teams have diverged. - Owns lead-time-to-change and build or pipeline health as cross-team measures. - Coordinates with the infrastructure function on anything touching environments, pipelines, or platform. Pillar 7 — Compliance and secure engineering by design - Owns the engineering standards that make regulatory obligations enforceable in code: PII handling, consent capture and propagation, audit logging, data retention, access control patterns. - Owns the secure development standard and the remediation SLA for findings.

Success measures Split deliberately, because a single blended scorecard will always be won or lost on the delivery half. Delivery half • Delivery predictability of the team over a rolling period (committed versus delivered). • Escaped defect rate from the team’s work, weighted toward revenue-bearing channels. • Team engagement and retention. Practice half • Percentage of teams demonstrably operating to each owned standard, measured by evidence in the toolchain rather than by self-report. • Defect leakage trend across the function on the pillars owned. • Lead time to change across the function. • Time-to-first-meaningful-contribution for new engineers. • Consistency of the technical hiring bar (pass rate variance across panels; new hire ramp variance). • Rework and incident cost attributable to the practice areas owned. Capability requirements

Essential • Has led a software team with line management accountability, including at least one genuine underperformance case carried to a conclusion. • Has changed engineering practice across teams they did not manage, and can describe how adoption was achieved rather than how the standard was written. • Credible enough technically to have their judgement accepted by senior engineers who don’t report to them. • Can hold a position against delivery pressure from a Product Owner or an executive without either capitulating or escalating every time. • Comfortable working through influence, with a high tolerance for slow adoption and repeated persuasion. • Working understanding of engineering in a regulated environment: change control, auditability, data protection, and secure development obligations. Desirable • Experience in financial services, credit, insurance, or another regulated consumer domain. • Experience of omnichannel or high-volume customer acquisition systems, where defect cost is measurable in conversion. • Experience running a capability or enablement programme for engineers. • Experience of a platform or cloud migration at scale. Explicitly not required • Deep expertise in every technology across all teams. The role sets standards and asks better questions; it does not out-engineer nine teams. • Formal architecture certification. • Contact centre or product management depth.