Lead Product Engineer - Pod Captain
A Little Bit About the Role
There is a version of this role that attracts the wrong person: a senior engineer who wants a title upgrade and a slightly bigger scope. That person will struggle here. The Lead PE is not a promotion for being a great individual engineer. It is a fundamentally different job.
Your success at this level is measured entirely by what your Island delivers — not by the quality of your own code. You will still write code, often the hardest and most risk-laden on the project: auth systems, payment integrations, data migrations, the things nobody else should touch. But that is a fraction of the role. The majority is managing delivery, owning the client relationship on the technical side, unblocking engineers before problems compound, and making scope calls under pressure with incomplete information.
You are also the technical and commercial bridge between your Island and the client. You own every piece of technical communication that goes to them — what is being built, what risks exist, what the honest timeline is. When a client pushes for something technically unsound, you push back directly and professionally, always with an alternative. When something breaks in production, you own the post-mortem process and the client receives it within 24 hours. You protect your team from unfiltered client pressure; you translate it into clear, actionable direction instead.
On top of delivery and client management, you are the AI operating standard for your Island. Every engineer on your pod uses Cursor and Claude within the rules you define. You set those rules before the first line of code is written, govern how they evolve, and you are accountable when AI-generated code ships without being understood.
If you are energised by all of that — by the accountability, by owning outcomes rather than tasks, by the combination of technical depth and people management — this role will suit you well. If you want to spend most of your time in code, this is not the right level.
AI Governance Expectation
You set the AI standard for your entire Island. If an engineer on your pod is shipping AI-generated code they do not understand, or underusing AI tools entirely, both are your problem to fix — not theirs alone.
At Lead level, AI governance means:
- Authoring the .cursorrules file before the first PR is opened. This defines how every engineer on the team writes code, uses Cursor, and structures prompts. You update it as the team learns, and you submit it to the Fountane Mainland at the close of every engagement.
- Evaluating new AI tools before they reach client code. You are the gate. A tool that looks useful in a demo can create untraceable technical debt in production. You decide what enters the workflow.
- Governing prompt discipline across the team: scoped prompts, codebase context hygiene, no AI-generated code that the author cannot explain line by line.
- Using Claude for architecture reasoning, sprint planning, risk documentation, and client-facing technical communication — not just Cursor for code generation. AI works at every layer of the Lead role, not just the coding layer.
- Staying ahead of the Golden Stack. You should know what Cursor and Claude can and cannot do at the codebase level better than anyone on your Island. When the Mainland updates the standard toolchain, you integrate the change into your Island’s workflow first.
Key Responsibilities
Technical Architecture & Standards Ownership
Design the full-stack architecture for every engagement before the first sprint starts: service boundaries, API contracts, database schema, state management strategy across web and mobile surfaces, and the security baseline. Author the .cursorrules file that governs how the entire Island writes code and uses AI. Own the highest-risk code personally — auth systems, payment integrations, live data migrations — these are not delegated regardless of workload. Enforce Mainland security standards across the entire codebase: input validation, correct auth scoping, safe data handling. If a security issue reaches production that was visible in a PR, that is a failure you own.
CE Prototype Gatekeeping
Review every Concept Engineer prototype before any engineer touches it. This is not a courtesy review — you have veto authority. If the scope is technically unrealistic for the sprint, the architecture is unbuildable as specified, or the prototype makes promises the codebase cannot keep, the sprint does not start until those are resolved. The time to surface a structural problem is before it is built, not after it is demoed. Produce a written checklist verdict for every prototype review — approved, approved with conditions, or blocked with reasons.
Client Technical Communication & Scope Ownership
Own all technical communication with the client directly. This means: what is being built each sprint, what risks exist and what is being done about them, honest timelines when estimates change, and clear explanations of technical decisions in plain language. Push back on risky or scope-expanding requests professionally and always with an alternative — “we cannot do X because Y; here is what achieves the same outcome.” Manage scope creep actively: every request that expands the engagement goes through you, gets assessed for impact, and is either absorbed, priced, or declined with a rationale. Renewal conversations are yours to lead in coordination with the CE.
Island Integration Audit
When a prospective client wants fractional augmentation — one or two roles rather than a full Island — you conduct the Island Integration Audit. This means evaluating their existing engineering team against Fountane Mainland SOPs: coding standards, AI tool usage, deployment practices, and documentation quality. If they pass, fractional deployment proceeds. If they do not, you produce a written audit report that either recommends full Island deployment or a Mainland upskilling programme. You are protecting your team’s velocity — a fractional deployment into a dysfunctional team destroys it.
Delivery & Velocity Management
Review the work cycle board every morning. Flag anything stuck, stale, or at risk before it becomes a client problem — not after. Communicate risks to the CE proactively with options, not just problems. Track every engineer’s billing hours: a shortfall spotted on Wednesday is a Thursday conversation, not a Friday surprise. If an engineer is consistently under-billing, that is either a workload problem, a capability problem, or a motivation problem — each has a different resolution and you are responsible for diagnosing which one it is.
Production Incident Ownership
When something breaks in production, you own the resolution process end to end: take technical lead, make the call on rollback vs. hotfix, communicate status to the client directly if the incident affects them, and own the post-mortem. The client receives the post-mortem within 24 hours of resolution — this is a hard commitment, not a target. The post-mortem covers: what happened, why it happened, what was done to fix it, and what structural change prevents recurrence. You produce it; it is not delegated to the engineer who caused the issue.
Automation & Infrastructure Boundary Arbitration
The Automation Engineer owns the test gates within the CI/CD pipeline. The Infrastructure Engineer owns the pipeline configuration itself. When these overlap and conflict — which they will — you arbitrate. The resolution must be documented in the Island’s .cursorrules and SOP onboarding document so the boundary does not need to be relitigated every sprint. This is not optional housekeeping; an unresolved boundary between these two roles is one of the most common sources of deployment failures on Islands.
Full Stack Ownership — Web & Mobile
You review and own work across the entire application layer: React / Next.js web frontends, React Native or Flutter mobile apps, Node.js / Python backends, and database schema. You cannot delegate a review of mobile code because you do not know mobile, or backend code because your background is frontend. If there is a gap in your full-stack depth, that is something to resolve before taking this role, not on the job.
People Management & Mentoring
Hold bi-weekly 1:1s with every engineer on the Island — focused on growth, blockers, and career direction, not status updates. Status belongs on the board; 1:1s are for the person. Address performance gaps early, directly, and specifically: a pattern spotted in week two is a conversation in week two, not month three. Protect the team from unfiltered client anxiety — absorb it, process it, and give the team clear direction instead of noise. If an engineer is struggling, that is your problem to solve before it becomes the client’s problem to notice.
Network Contribution
At the close of every engagement, submit to the Fountane Mainland: the .cursorrules file, all prompt templates used, a short retrospective on what worked and what did not, and any reusable patterns or scripts developed during the engagement. This is a Lead-level obligation, not a nice-to-have. The network’s collective capability grows through what Leads bring back from the field. An engagement that ends without a Mainland submission has left the network no smarter than it was before.
Qualifications
- 8+ years of software engineering experience, with at least two years in a role where you were accountable for delivery outcomes — not just your own code. You should be able to describe an engagement where something went wrong on your watch, what you did about it, and what you would do differently. If your experience is entirely individual-contributor, this role will be a difficult fit.
- Genuinely full stack across web and mobile: React / Next.js, React Native or Flutter, Node.js or Python, and database architecture including schema design and migrations. You review and own work across all of these surfaces — not just the ones you are most comfortable in.
- Hands-on, daily Cursor and Claude usage with the ability to set and enforce standards for how a team uses them — not just personal proficiency. You should be able to describe the .cursorrules file you would write for a standard SMB engagement and explain the decisions behind it.
- Proven ability to communicate technical risk and decisions directly to non-technical clients — not through a PM, directly, in plain language. You should be able to describe a client pushback you navigated and how you handled it.
- Experience managing scope on a real engagement: a client who wanted more than was in the contract, and how you resolved it without damaging the relationship or the team’s velocity.
- Has conducted security-aware architecture design: auth systems, input validation, safe data handling. You should be able to describe a security decision you made and why.
- Has led or coordinated a small engineering team — run 1:1s, addressed performance gaps, made scope calls under pressure. Management experience at a staffing agency or outsourcing firm counts if the accountability was real.
- Comfortable having direct, specific performance conversations early — not after the situation has compounded. You should be able to describe a time you addressed a performance issue at the first sign rather than waiting.
- Bachelor’s or Master’s in Computer Science or a related field, or equivalent experience.
About Fountane
Fountane is a technology ventures lab - one part product studio, one part startup engine. We build high-quality software and AI products for clients ranging from fast-moving startups to large enterprises, and we co-build and invest in new companies when we see the right opportunity.
Founded in 2017 and headquartered in Minneapolis, we have grown to 60+ people across four continents and were recognised as one of America’s fastest-growing companies, ranking No. 699 on the Inc. 5000 with 595% three-year growth.
We are serious about craft, direct about expectations, and operate at the frontier of AI-assisted engineering. Lead PEs here carry real authority and real accountability — over delivery, over people, and over client outcomes. If that combination is what you are looking for, this is the place.
Follow Cutshort