Systems · Open role
Run the engagement until the client can run it.
You scope the operating model for a client, turn it into a phased plan the team can build and their governance can approve, and run the cadence that keeps the two in sync, until their own team runs it without you.
Mission
What the role does and why it matters here.
The Enterprise Delivery Lead owns delivery on an engagement the way the Context Architect owns structure and the AI Systems Engineer owns runtime: end to end, in writing, before it gets relitigated under pressure. You scope what the operating model looks like for a given client, turn that into a phased plan the engineering team can build against and the client's governance process can approve, and run the cadence that keeps the two in sync. You are the person a client-side executive calls for a straight read on where the engagement stands, and the person internally who turns a technical roadmap into a delivery plan a bank's or insurer's risk function can actually sign off on. The bar is not a shipped feature; it's an operating model the client's own team can run without Lucentive standing behind every decision. That means you sit close enough to the architecture to represent a tradeoff accurately in a compliance conversation, and close enough to the client to know when "not yet" is the right answer.
Responsibilities
What you would own.
Scope each engagement: turn a client's stated need into a phased plan the Context Architect and engineering team can build against, and the client's governance process can approve.
Own the delivery cadence: track what ships against the phasing plan, surface slippage early, and renegotiate scope in the open rather than let a deadline surprise anyone.
Run the client relationship day to day, including when the honest answer is "not yet" or "not like that."
Drive operating-model adoption: make sure the client's compliance, platform, and engineering owners can run the validators, approval boundaries, and audit trail without day-to-day help from Lucentive.
Translate between rooms: carry a technical tradeoff into a risk or compliance conversation, and carry a compliance constraint back into an architecture decision, without losing precision either way.
Escalate the right things early: know which risks are yours to absorb and which need the founder or the Context Architect in the room now, not at the retrospective.
Close the loop after each phase: what shipped, what the client's team can now run themselves, what the next phase depends on.
How you think and work
Six traits the work demands.
Pedigree isn't the filter. Disposition is. The six traits below are what the work actually asks of you.
Agentic intuition
You read agents the way a manager reads a direct report: when to trust the output, when to interrupt the run, when to take the wheel back.
You read a stalled engagement the way you'd read a stalled agent run: something upstream is wrong, and the fix is not a longer status meeting.
Critical thinking
Confident-sounding output gets the same scrutiny as anything else, your own work included.
You've told a client the scope they asked for was the wrong scope, and made the case for the one that was actually right.
Curiosity
You pull on threads. You read outside the lane. You follow a question past the first plausible answer.
You dig into why a client's governance process is shaped the way it is, instead of just working around it.
Agency
You move without being told. You decide, ship, own the call. No one has to write the playbook for you.
You've made the call to replan a phase before anyone asked you to, because waiting for permission would have cost the engagement more.
Systems thinking, long view
You see how the parts connect, and where this goes in three years.
You scope phase one knowing what the client's team will need in order to run phase three without you.
Leadership instinct
You orchestrate work across humans, agents, and stakeholders. You switch register between a workspace ticket, an architect call, and a senior bank room in the same day without losing what you came in to say.
You've kept a delivery plan on course while a client's stakeholders and your own engineers pulled in different directions, and walked out with both sides still aligned.
Useful background
- Senior experience leading delivery on a client-facing technical engagement (consulting, enterprise software implementation, or similar) inside a regulated or high-stakes industry.
- Technical fluency: you can sit in an architecture conversation, follow the tradeoff being made, and represent it accurately to a non-technical stakeholder without needing a translator.
- Experience running delivery against a phased plan with a governance or compliance process on the other side of the table.
- Practiced at running a scope conversation under pressure from a client who wants more and a team that has less time than the ask implies.
- Judgment about when to escalate and when to absorb: you don't surface every risk, and you don't sit on the one that matters.
- You've worked inside or delivered into a regulated industry (banking, insurance, healthcare, or similar) and can read a risk or compliance requirement without a translator.
- You've helped a client's internal team take over something you built for them, and know what that handoff actually requires.
- You've owned both the technical build and the client relationship on a multi-workstream engagement at the same time.
- You have engineering or architecture background yourself, even if delivery leadership is where you've landed.
Regulated-industry experience isn't required. Curiosity about it is.
Logistics
How the role is set up.
- Location
- Remote-first. EU-based team, with at least four hours of overlap with CET on a working day; Portugal hub. Travel for engagement kickoffs and client on-sites is more frequent here than in other Systems roles.
- Engagement
- Contract or full-time.
- Start
- Flexible, coordinated at offer stage.
- Language
- English, the working language for client and governance conversations.