Product Engineering Lead

Manifest Global empowers in building companies that connect the world towards growth, prosperity, and innovation. Our portfolio includes trailblazer brands such as Cialfo, BridgeU, Explore, Kaaiser, EduGo, and Flow AI and which are dedicated to expanding global student mobility by serving their respective stakeholders in the ecosystem. 

Our Mission 

To create a world where every student, regardless of their ethnicity, nationality, socio-economic status, and learning preference, gets equal access to higher education through our world-class network of portfolio brands; a network that globally connects community stakeholders that provide the finest resources and support material, anywhere in the world and at any time.

What This Role Is

Every year, millions of students make a decision that sets the direction of their lives: where to study, what to study, and which country they will build a career in. That decision runs through a counselor's office, a university's admissions funnel, a family's conversation with an advisor, and a visa timeline - and almost none of the signal from one step reaches the next. Manifest exists to connect that journey, and it does it through products that each serve one part of it exceptionally well.

This role owns one of those parts at a time. As a Product Engineering Lead, you take full technical ownership of a single business platform, accountable for one thing above all: making the user that platform serves successful at what they are trying to do. You go deep on that user - their workflow, their friction, what "success" actually means for them - and you build the product that delivers it.

This is a hands-on individual contributor seat. The engineers building on your platform report to you - none or a handful today, growing as the platform does. Your leverage comes from how completely you understand one stakeholder, how good the product you build for them becomes, and how well you bring the rest of the business along with you.

You report to the Engineering Ma nager. You are assessed on two things: the delivery of the platform you're leading and the product-outcome metrics aligned to it - the measures of whether the user you serve is genuinely more successful. Both move together, and both are how your performance is judged.

You do this inside a larger system. Manifest is several products becoming one connected whole, with a shared intelligence layer running underneath. You don't own that layer or the architecture that spans the platforms - but you understand the portfolio deeply, you know how your platform connects to the others, and you build in a way that draws on the shared layer and feeds signal back into it. Your focus is narrow by design. Your awareness of the whole is not.

One thing you do not do is build your own plumbing. Auth, notifications, reporting and integrations come from the shared layer. Infrastructure and quality come from their own lines. Your accountability is for using them rather than quietly working around them.

How the Role Grows

You own one platform, and you own it for as long as it is yours to build. Growth here is not a move sideways - it is the platform getting bigger underneath you. The seat starts at one engineer or none, and as the platform earns investment, engineers are added under you rather than beside you; the model is deliberately built so that going from one person to five needs the lead to have grown into it, not a new manager above it. Past that there is a real choice rather than a ladder. Some people go deeper on the IC track toward staff, where the scope stops being one platform and becomes the systems every platform is built on. Others find they want the wider org and move toward engineering management. We would rather you choose honestly than default. The one thing not on the table is drifting out of the code.

What Makes This Role Different

Most lead engineer roles ask you to work through a backlog. This one asks you to own an outcome for a specific user and build whatever it takes to get there - including the quality of it and what happens to it in production, and including the AI-native product that user has never had before.

The leverage is the Manifest ecosystem. You are not building for your user from scratch and in isolation. You have a shared intelligence layer to build on, signal from across the portfolio to draw on, and a company that is AI-native from first principles. That means you can build recommendations, workflows, and agentic experiences for your platform that a standalone product in that space could never see well enough to build.

The timing is the argument. Across Manifest's platforms, AI is at the point where it stops being a feature and becomes the way the product works. The person who defines that for a given user, now, sets the direction for years.

What's Hard - And Why It's Worth It

The best engineers we know are drawn to the hard version of a problem, not the safe one. So here's the honest shape of it.

You go deep on one platform - often as its only engineer - but you build on a shared layer with its own gravity and other platforms pulling on it. Getting what your user needs sometimes means making your case against someone else's, and not always winning. That friction isn't noise. It's what forces the sharpest thinking you'll do here, and the lead who learns to fight for their user while strengthening the whole becomes the rarest kind of operator this company has.

The business leader who runs your platform knows their market cold and has their own conviction about the roadmap. Sometimes your data will say they're wrong. The moment you tell them that - in the language of their own business - and come out with their trust intact is the moment you stop being an engineer who executes and become one leaders actually follow.

And depending on the platform, you may inherit it mid-stride: someone else's half-built roadmap, live commitments, a team already in motion. Deciding what to keep, what to kill, and what to reimagine - without burning the trust that came before you - is its own skill, and one most engineers reach this level without ever having had to learn.

None of this is the easy version of a lead engineer job. That's exactly the point.

What You Own

What you decide alone

These calls are yours. No review, no approval step, no committee.

• The stack and the design inside your platform's boundary. Libraries, patterns, schema, internal structure - anything that does not cross the edge of your platform is your call to make and your call to live with.
• What ships and what gets cut, technically. Inside an agreed commitment, you decide what goes in, what slips and what is not worth building. You are not asked to justify a technical trade-off that stays inside your boundary.
• Who joins your platform. You run the loop and you make the hire. The Engineering Manager and the SVP of Engineering advise; they do not approve.
• Where your platform is agent-native, the agent's boundaries. What it can reach, what it must not, what tools it holds and what it does when it is wrong. Within the written standards, not by asking permission each time.

What goes to review

So the line is clear in both directions.

• Anything that crosses your platform's edge - a shared data model, an integration contract, an auth approach that other platforms inherit - goes through the architecture review path. That is a decision record, not an approval queue.
• A commitment date moving is a conversation with the Engineering Manager and the business owner, not a unilateral call.
• Building your own version of something the shared layer already provides. If the shared layer genuinely does not fit, make that case openly - what is not available to you is routing around it quietly.

The platform, technically

• Architecture within your platform, the codebase, the quality of what ships, and the technical debt you take on or pay down deliberately
• The design calls that sit inside your boundary - and knowing which ones are bigger than you and belong in architecture review
• Where your platform is agent-native: the agent design. What the agent does, what tools it holds, where it must not go, and how you know when it is wrong

Delivery

• What goes out, when, and what gets cut - agreed with the Engineering Manager and the business owner, decided by you technically
• A rhythm the business can plan against: commitments met, or renegotiated early rather than missed late

The people on it

• The engineers building on your platform report to you, and that grows as the platform does
• Their technical direction and the standard of what they ship

The relationship with the craft lines

• Pulling auth, notifications, reporting and integrations from Manifest Intelligence rather than building your own
• Working with infrastructure on how your platform runs, and with QE on how it is tested
• Being accountable for using the shared layer, and for saying clearly when it genuinely does not fit

Production

• Your platform's incidents, performance and customer-facing defects, with support from infrastructure
• Being the first responder for your platform rather than escalating by default

Writing it down

• Decisions of system-wide consequence go through the architecture review path, not into your head
• Enough documentation that the next person to hold this platform can see why each call was made

What Success Looks Like

The markers below are directional - we will calibrate specifics once you are in the seat.

In your first month you produce a written account of the platform as it actually is: what it does, what it depends on, where it is fragile, and what is being worked around. Where there is no codebase yet, the equivalent is a build plan agreed with the business owner that someone could actually execute.

By sixty days you have made one commitment and met it end to end, and your dependencies on the shared layer and infrastructure are named and agreed rather than assumed.

By ninety days there is a roadmap the business owner recognises as theirs, a working relationship with the architecture review path, and at least one thing your platform used to do privately now coming from Manifest Intelligence.

Over a year, technical questions about your platform stop being routed to engineering leadership, incidents have a first responder who is not the SVP, and the platform ships on a rhythm the business can plan against. And the decisions behind it are written down, so the next engineer on the platform can see why it looks the way it does.

What You Bring

You have spent six years or more building production systems, with real depth in at least one of our stacks - Rails, services, or agent and LLM systems.

You have owned a product or service end to end, including what broke in production at two in the morning. You know what it costs to be the person who gets called, and you do not confuse shipping with being done.

You are comfortable being the only engineer on something, and comfortable not staying that way. The first is about self-direction; the second is about actually wanting to grow other people rather than remaining the hero.

You make a call and write down why. Most of what goes wrong on a one-person platform is an undocumented decision that nobody can reconstruct six months later.

You work well with people who do not report to you. The craft lines are how this role gets leverage, and they respond to the engineer who comes with a clear problem rather than a demand.

You can hold your own with a business leader. You can tell them the roadmap should change, say why in the terms of their business rather than yours, and come out with their trust intact.

You are AI-native, or visibly becoming it. You have built agentic or AI-powered product into a real user workflow - something people came to rely on, not something they tried once - and you know where AI does not belong as clearly as where it does. And you are comfortable starting a codebase from nothing, or picking one up mid-flight.

You are comfortable in a distributed team across time zones - ours sits across Delhi, Pakistan, Singapore

Most importantly: you read this and your first reaction was not "this is a solid lead engineer job." It was "I want one thing that is mine, end to end, and I want to be the reason it is good."

Why Manifest

Manifest Global is building the infrastructure for global human capital mobility, connecting students, schools, universities, and employers across 150+ countries. Our portfolio spans Cialfo (AI-powered college counseling, 2,000+ schools), BridgeU (university guidance for international schools globally), Kaaiser (trusted study abroad counseling since 1997 across India and Southeast Asia), Explore (AI-powered university outreach, 1,000+ university partners), and EduGo (study abroad counseling and student placement). Together, we move talent across borders at scale. $700B flows annually in remittances from migrant workers. 85M workers will be missing from developed economies by 2030. We're building the operating system that changes that. $76M raised. Still early.

Every platform here serves one part of a student's journey. This seat is where one of those parts either works or does not.