Senior Delivery Manager

The Senior Delivery Manager (SDM) is the delivery discipline layer on our largest engagements. You own the fact that a multi-team, multi-stakeholder program actually ships: the risk register, the launch readiness, and the hard conversations with clients about what makes the cut and what doesn't. Stand-ups and sprint mechanics are in your toolkit; they're not the job.

You work alongside an Agentic Managing Director (AMD) who owns the commercial and technical relationship, and a Principal Product Lead (PPL) who owns the product plan. Your lane is the one the AMD can't always cover because their bar is technical-first, and the PPL can't always cover because their bar is product-first: the delivery execution itself. Schedule, dependencies, cross-team coordination, and the client-side launch work that usually decides whether a program lands or drags.

This is a vantage point a technical-first leader won't naturally hold. Handed a delivery problem, an AMD reaches for a technical answer (re-architect, re-sequence the build); meanwhile the question that actually decides the engagement, are we delivering on what the client expects, needs someone holding it steadily. That steadiness is what you bring. You keep the team's work and the client's expectations moving together as both evolve, so the team has room to be creative about how they deliver without anyone losing the thread of what was promised.

This role runs dedicated on one or two engagements, typically our largest enterprise accounts. You'll carry it client-facing, hold the room when a release slips or a scope argument turns hot, and be accountable alongside the AMD for the engagement landing well.

What You'll Do#

• Own delivery execution across one or two engagements: scope, schedule, dependencies, risk, and the trade-offs that keep a program on course when reality changes
• Hold the intent of what was committed. Keep the intent of the commercial commitment (the SOW) and what the team is building aligned as both evolve, and keep the client's expectations moving with them. The team should have room to be creative about how they deliver; your work is to make sure that creativity stays connected to what the client is expecting, not to police it. When the work starts to diverge from that intent, surface it as a deliberate, shared decision (reset the expectation with the client, or realign with the team) rather than letting a silent gap form
• Run the risk register like it matters, and read delivery health from real signals. Surface risks early with clear impact and urgency, build SMART mitigation plans, and make the dashboards scream red when a client is drifting. Watch the empirical signals that show whether work is flowing (throughput, review latency, commit cadence, stalls) so you can spot a stall early and go help, not so you can keep score. Don't wait until the retrospective
• Help the team finish, and keep scope changes deliberate. A pile of 80%-done work is a delivery risk, not progress, and gold-plating quietly trades the commitment for polish nobody asked for. Help the team keep work-in-progress bounded and favor done-and-integrated over broad-and-drifting, and keep scope changes as conscious, shared decisions rather than things that just happen
• Hold the delivery conversation with clients in a way the AMD shouldn't have to. Weekly progress and risk communication, escalation judgment, and crucial conversations on scope, schedule, and readiness
• Keep the client's priorities current and visible. A client who can't see progress, or who doesn't have a clear next focus, tends to fill the vacuum themselves: disengaging, second-guessing, or going around the team to build it on their own. Keep priorities visible and refreshed so the engagement stays anchored in a shared, current plan and the client stays a partner in it
• Read the client's organizational reality. Individual stakeholder motivations, reporting structure, pain points, shifting priorities, and translate that context into delivery decisions the team can act on
• Partner with the AMD on the client relationship and the PPL on scope trade-offs. You represent the delivery lane alongside them, not downstream of them
• Coordinate across delivery teams when an engagement scales past one team. Sequencing, shared dependencies, and the handoffs between teams that usually go wrong quietly
• Coach ASEs and APEs on delivery awareness. Not how to do their job, but how to think about commitments, risk, and stakeholder impact as they ship
• Use process where it enables trust, not where it becomes a crutch. We don't sell Agile ceremonies; we sell shipped software. Lean on the rituals that reduce real risk; drop the ones that are there out of habit
• Contribute reusable delivery meta-systems back to the team: risk register templates, launch playbooks, dashboard patterns, escalation runbooks that the next engagement starts with instead of rebuilding

What the Day-to-Day Looks Like#

• Walk into Monday with a risk view across your engagement and a 30-minute talk with the AMD and PPL on what's about to slip and what to do about it
• Run a working session with a tech lead to get a realistic read on a milestone before the client presentation, not after
• Draft a weekly client-facing status that a VP can read in three minutes and know exactly where things stand on scope, schedule, and risk
• Sit in a design-and-product call where a scope change is being discussed; make the delivery implications clear without killing the change
• Notice that a cross-team dependency is missing an owner and wire it up before the teams realize they're blocked
• Pair with an ASE on a launch plan for a release with real business stakes (regulatory dates, vendor coordination, client-side go-live dependencies), not just a deploy
• Contribute an updated launch playbook to our shared practice library when one of your engagements teaches you something new

Qualities That Will Help You Thrive#

• Judgment under constraint. You've learned that when you have 15 things to do and can only do 10, the 5 you don't do are the 5 you obsess over. You're good at that decision
• Leads by enabling, not by running. When a team is struggling, your first instinct isn't "add process." It's "what does this team actually need to be trustable here?"
• Calm in the hard conversation. You can tell a client a date is slipping, keep their trust in the same breath, and walk out with a clearer plan than you walked in with
• Agentic-native. Claude Code (or equivalent) is a primary tool for you. You use it to draft status reports, synthesize risk signals, compress meeting prep. You encode what works into reusable skills, not one-off prompts
• Client-ready. You can sit in a room with a VP and explain a trade-off without dumbing it down or getting defensive
• Low ego, high standards. You multiply the team. Your win is the engagement landing, not your fingerprints being visible on every decision
• Bias toward the meta-system. A risk template you build for one engagement should be something the next engagement picks up for free

Qualifications#

Required#

• 7+ years in delivery leadership: program management, project management, delivery management, or a Scrum Master who has grown into program ownership. Direct experience owning end-to-end delivery on complex, multi-stakeholder engagements
• 3+ years in a consulting or client-facing delivery context. You've built executive trust quickly and navigated organizational politics on the client side
• Fluent in Agile, Scrum, Kanban, and the broader Lean/Agile toolkit. Not as a methodology you enforce, but as a set of tools you pick from based on context
• Risk management as a daily practice, not a compliance artifact. You can look at a program and name the top three risks within a week of being on it, and you read delivery health from empirical signals (throughput, WIP, commit cadence) rather than status-meeting optimism
• Demonstrated conflict mediation and escalation judgment. You've held the line with difficult stakeholders and course-corrected team dynamics without escalating unnecessarily
• Agentic fluency. Daily use of Claude Code, Cursor, or equivalent for real delivery work. You have examples of agent configuration (skills, rules, runbooks, custom commands) that save you time week over week
• Strong written and verbal communication: status reports, executive summaries, and crucial-conversation framing that lands clearly with non-technical stakeholders
• Comfort in client-facing delivery conversations. You can hold the room without taking it over

Bonus#

• Experience running delivery on enterprise engagements in regulated or complex environments (financial services, healthcare, pharma, retail, insurance)
• Experience coordinating across multiple delivery teams on a scaled program
• Familiarity with flow-based delivery metrics (cycle time, throughput, WIP limits) and using empirical data to communicate project health
• Proposal development, engagement scoping, or launch-readiness governance on professional-services work
• Prior work on platform or 0-to-1 engagements where the scope is ambiguous and delivery discipline has to do a lot of the stabilizing

How We Work#

• Delivery cadence: Continuous delivery rhythm paired with explicit risk reviews; working software as the primary artifact for alignment, not status decks
• Discipline tools: Risk registers, RAID logs, burndown/burnup, flow metrics (cycle time, throughput, WIP), launch playbooks, escalation runbooks
• Partners: Agentic Managing Directors, Principal Product Leads, Agentic Systems Engineers, Agentic Product Engineers, Product Designers
• Agentic layer: Claude Code is our daily driver. You won't build agent tooling, but you'll use it daily and shape how delivery discipline gets encoded into reusable patterns across engagements
• Stakeholder surface: Client project sponsors, product owners, engineering leads, VPs, and executive sponsors up to C-suite when the engagement warrants it
• Practice contribution: We capture the delivery patterns that work so the next engagement starts further along. You'll contribute to that library the same way our ASEs contribute code patterns