About Us:

Fluent Health is a dynamic healthcare startup revolutionizing how you manage your healthcare and that of your family. We provide customers with high-quality, personalized options, credible information through trustworthy content, and absolute privacy. To assist us in our growth journey, we are seeking a highly motivated and experienced Head of Engineering to play a pivotal role in our future success.

Company Website: https://fluentinhealth.com/

The Role:

Head of Engineering is a transformation mandate, not a maintenance hire.

This role closes a leadership and execution gap on the engineering team by focusing on how software gets built: team quality, delivery velocity, and developer growth. It is distinct from a pure VP hire or a layer of middle management - it is a high-leverage, hands-on engineering leader embedded with the team.

The clearest way to frame it: CTO and Principal Engineer apply system-design thinking to the technical system - the architecture, the data that feeds it. You apply that same system-design lens to the team - the people and processes that write the codebase, not primarily the architecture itself. Same rigor, different object. In the shorthand we've used in conversation: Principal Engineer sets the engineering bar, and your mandate is to train the team to reach it.

The core problem this role solves. The gap isn't tooling, architecture, or AI-adoption rate - those are in reasonably positive shape. The gap is quality: defect rate and delivery-on-target are both meaningfully off, and that costs the business in rework, delay, and dev motivation. It is the single largest bottleneck in the business today.

Root cause is structural more than personnel: accountability currently sits with a separate QA function, so developers treat quality as something to hand off rather than something they own end to end. The fix is dev-level ownership of code and tests (not necessarily full TDD, but the person who wrote the code owns its test suite), paired with legibility (code and tests readable by both engineers and AI) and transparency (team-wide visibility into quality, per developer, through to production). This directly reshapes what the release management and QA team does and how it's structured, so this transition gets designed with that team as an active stakeholder, not decided around them and handed down.

The role is built around two pillars:

Delivery transformation. Designing and running an engineering operating model where quality is built in, not inspected out - covering sprint design, squad formation, SDLC ownership, execution discipline in how tickets are picked up and delivered, and cross-functional orchestration between engineering, product, QA, and customer success.

GenAI adoption programme. Leading the team through the shift from traditional development to GenAI-first engineering practice, done hands-on rather than by mandate. Not just using AI tools - redesigning how engineers think about what they own when code is largely generated. AI-first adoption matters and should happen alongside the quality fix, but it is downstream of quality, not a substitute for it.

Hands-On Expectation: Player-Coach

This is explicitly a player-coach role, not a coach-only role.





- The bar is not "code like a traditional IC." Nobody at Fluent codes without AI anymore. The bar is: use GenAI to produce real, shipped, working code often enough that you are a living example of the exact shift you are asking the team to make, from "I write code" to "I orchestrate and validate it."
- We're looking for someone who has already proven they can do this in a recent role, and this position asks you to keep doing it here, visibly, as part of the job, not to hit a quota of production commits.
- This isn't about holding the technical bar, that's Principal Engineer's lane. It's about staying close enough to the work, via AI-assisted building, that your coaching comes from lived practice, not theory.

Responsibilities:

Delivery operating cadence:

- Sprint structure, squad formation, deploy unit methodology
- Delivery health metrics and feedback loops
- SDLC design: from requirements to shipped feature, inclusive of quality
- Execution discipline: how tickets are picked up, thought through, implemented, and delivered back to the team
- You own the policy layer for release and quality: what the cadence should be, the direction of the QA-to-dev-owned-testing transition, the metrics that prove it's working. The release management and QA function owns the operational layer within that model, running the actual calendar, the actual go/no-go call, the actual incident response. Partnership, not ownership of their day-to-day.

GenAI adoption programme:

- Phase-gated rollout of AI-assisted development across the engineering team, led hands-on
- Per-team adoption metrics and sprint-specific targeting
- Coaching engineers from "I use AI tools" to "I architect AI-first workflows"

Data and systems fluency:

- Raise team competence in how data is interpreted, queried, harmonized, and safely handled across applications and the core system
- Reduce quality issues that stem from fragmented thinking, inconsistent query logic, or weak system-level understanding of the data layer
- Improve how engineers understand the broader system, including architecture implications and the downstream effects of moving and transforming data

Engineering people leadership:

- Direct reports: the engineering team reports to you
- Hiring: you own the bar, the process, and the decision
- Performance and career development: 1:1s, feedback, growth plans are yours to run. Ivan contributes a technical read on each engineer's code quality and growth as one input among others, since he sees that up close, but he does not co-own the review, the decision, or the process.
- Real authority as the target state, see "Where You're Stretching" below for how the first 90-180 days will actually work

Cross-functional orchestration:

- Engineering ↔ product ↔ QA ↔ customer success alignment
- Operating model for how teams coordinate across a cycle

Leadership Team interface:

- Honest engineering voice to the leadership team




- Engineering reality translated for non-technical stakeholders - without softening it

Working with Principal Engineer:

Complementary, not overlapping, and explicitly peer-to-peer neither of you reports to the other, and both of you report to CTO:

- Principal Engineer's Lane: sets the engineering bar, models strong coding and system design, focuses on the system/architecture itself.
- Your Lane: improves how the team builds software - delivery accountability, coaching, people and process design, raising engineering maturity across the team.

You're both expected to operate hand in hand as part of a small engineering leadership group (with CTO, delivery, and QA) that regularly reviews team effectiveness, quality trends, and process changes - and both of you are expected to bring an independent, ongoing view on where the company's technology and process choices should evolve, not just execute within your own lane.

Leadership Expectations:

- Serve as a teacher, guide, and mentor to engineers - especially in systems thinking and data fluency.
- Help bridge communication and cultural gaps on the team where needed.
- Take accountability for improving engineering output in partnership with delivery and QA, with the long-term aim of shifting more quality responsibility left onto development.
- Support a flatter org design: a small set of strong technical leads rather than a layered management hierarchy.

Success Measures:

- Noticeable improvement in engineering velocity and quality, sprint over sprint, after onboarding.
- Better consistency in how engineers reason about data and system implications.
- Increased adoption of effective AI-assisted engineering workflows through role modeling and coaching, not mandate.
- Stronger day-to-day developer guidance without adding unnecessary hierarchy.

What This Role Is Not:

- Treating GenAI as a productivity tool rather than a platform shift
- A layer of middle management added for its own sake - the org design stays flat
- A pure coach who directs from the sidelines without writing code or doing the work personally

Where You're Stretching:

- Worth naming plainly: for most candidates who fit this profile, formal engineering people-management - hiring decisions, performance conversations, career development from the manager's chair - is a genuine stretch rather than an established track record. That's fine, and expected, as long as it's a stretch you genuinely want to grow into, not just a title you're technically capable of holding. It's a real reach, not a formality, and success depends on wanting to guide and elevate people, not just being technically capable of it.
- Given that, the first 90-180 days work like this rather than assuming day-one authority produces day-one results: Alex partners with you as a backstop on early hiring decisions and performance conversations, with an explicit checkpoint at 90 days to assess how the people-leadership side is landing. The destination - real authority, from day one in spirit if not in fully-proven practice - doesn't change. How we get there does.

Compensation:

- Competitive for senior engineering leadership in Mumbai. We'll finalize the specific number directly with you as part of closing this out.

📌 Head of Engineering (Mumbai)
🏢 Fluent Health
📍 Mumbai