Senior Program Manager

We ship enterprise software for the legal industry, and we are installing a new operating model while we ship. This role keeps delivery organized, visible, and moving across our in-house product teams and our external development partner's teams: one process, one tracking instrument, one calendar of commitments. Product Managers own what we build and why. Engineering owns how it gets built. This seat owns how the work flows between them: the cadence, the tracking, the dependencies, the readiness gates, and an honest picture of where every commitment stands. The job is to make the work less diffuse. Every conversation with this seat should leave the work more organized than it started. It is a steward seat, not a gatekeeper, and it serves the teams it measures.

The three things this role needs in one person

1) You have run one standard process on one instrument across teams that each had their own.

You have landed several delivery teams, internal and vendor, on standard scrum: one work-management tool such as Jira, its defaults first, a shared vocabulary everyone agreed to, enforced in the ceremonies as the work happens. When someone asks for a custom construct, your first question is what problem it solves and whether the standard model already solves it. You add tooling only when live use proves a painful friction point, and you keep the process the smallest version that works, because process for its own sake is the failure mode of this seat. You ask teams for outcomes and the metric that shows them; the how stays theirs.

Evidence looks like: "Moved four teams, two of them at a vendor, from three trackers and three vocabularies onto one Jira instance with standard workflows, and the leadership team stopped asking for status." In an interview, you can name a custom field or workflow you talked a team out of by mapping it back to the standard, and the one you kept and the friction that justified it.

2) You surface a slipping commitment the week it slips, with the fix attached.

Leadership trusts the delivery picture because you keep it honest: say/do by team, scope added after a sprint starts, deploy versus release, and readiness gates run on evidence (binary items, named cross-functional sign-off, an artifact attached before it counts) rather than a thumbs-up. When a date or a dependency starts to move, you raise it once, early, in a form someone can act on: what is wrong, the mechanism that fixes it, how we will know it worked, and what you need from whom by when. Documenting decisions after they are made is not risk management, and chasing people is not either.

Evidence looks like: "Caught a vendor testing dependency slipping two sprints before the release date and re-planned the cutover around it before the date moved," or a risk register where every open item carries a mechanism, an owner, and a check date. In an interview, you can walk through a gate you designed, where you drew the line on what counts as ready, and a time you held that line under pressure.

3) You facilitate so decisions get made in the cadence and the teams own the fix.

You run the operating rhythm: the cadence calendar, the agendas, the facilitation, and a decision log where every decision carries an owner, a due date, and a change reason. Ceremonies exit with decisions rather than open questions. When a process problem shows up, you bring the retro the symptom counted and what it cost the business, and the team chooses the fix, so it is their fix and it sticks. You coach leads to run their own ceremonies and step back when they can. You debate a decision hard, then commit to it fully, in what you say to the team as much as in what you track.

Evidence looks like: "Turned a set of status meetings into decision meetings with a live decision log, and handed the standups to the team leads within a quarter." In an interview, you can describe a retro where the team chose a fix you would not have picked, what happened, and why you let it stand.

Essential Responsibilities

• Administer the single tracking instrument across all delivery teams, in-house and external partner, with standard workflows, agreed definitions, and a recurring whole-list audit to zero untracked work
• Run the intake-to-sprint flow with the Product and Engineering leads: releases, epics, and stories with acceptance criteria from Product; tasks, spikes, dependencies, and estimates from Engineering; one readiness bar before anything enters sprint planning
• Facilitate the recurring cadences (planning, refinement, review, retrospective, scrum of scrums) so each exits with decisions, owners, and dates; maintain the decision log and the risk register
• Keep say/do, scope-change, and cycle-time reporting current per team, and operate the delivery scorecard in standing leadership reviews
• Maintain the release-readiness calendar and run launch and cutover gates as evidence-based instruments with named cross-functional sign-off
• Track cross-team and external dependencies (business sign-offs, pilot cohorts, vendor testing, client onboarding) and raise the ones that start to move the week they move
• Own the plan of record for the operating-model rollout itself, co-built with the VP of Technology, and roll it out one change at a time
• Publish the roadmap and release schedule on cadence so the picture the business sees and the picture in the tracker are the same picture
• Route out-of-process escalations back into the cadence and track them to closure; surface repeat route-arounds to the owning manager as a backstop
• Steward the external development partner relationship so both sides run as one delivery organization: same instrument, same cadence, concerns surfaced early
• Serve the teams, not only measure them: remove blockers, protect focus, and keep communication moving across the seams between Product, Engineering, QA, and DevOps

How you work

• You steward the system, not the content. Priority stays with Product, technical calls with Engineering, scope with the business. When work is missed, the system shows it; you do not police people.
• You bring the recommendation with the concern: a mechanism, a signal, and a named owner. An observation without a mechanism is not ready to raise yet.
• You flag a miss once and let the system carry it. You do not backfill other teams' data.
• You disagree, then commit. Once a call is made you support the plan out loud and work the mechanism.
• You triage. You keep a list of what you see, pick the top two or three, and work them to closure before picking up the next.
• You prepare tightly: why we are meeting, the one outcome that matters, and owners set before the meeting rather than during it.
• You write so nobody has to decode it: short structured recaps with next steps.
• You think two steps downstream, which is why you are in the room at intake for larger initiatives rather than handed the work after it is scoped.
• You use AI tools to compress and check work you have already decided on, and you say when an output is unvalidated.

Compensation & Benefits

$125,000 – $185,000 base compensation, commensurate with experience. Benefits include Medical, Dental, and Vision coverage; Life insurance (Voluntary Term and Whole Life); Voluntary Long Term Disability; paid time off and paid holidays; 401(k); Employee Assistance Program (EAP); and Maternity Leave.

• 5+ years of project or program management on software delivery, with hands-on ownership of the full agile ceremony set (backlog, planning, refinement, scrum of scrums, retrospectives run closed-loop, release coordination) 
• Demonstrated experience standing up cross-team delivery tracking on a work-management tool such as Jira, including custom-field-driven dashboards and reporting that a leadership team consumes 
• Experience coordinating delivery across internal and vendor development teams as one organization 
• Experience running release-readiness or cutover gates on a production system 
• Comfort in a fast-moving environment where priorities shift, paired with the discipline to keep the system honest anyway 
• Scrum Master, PMP or CAPM, and Lean Six Sigma or equivalent are a plus; the requirement is the operating judgment, not the certificate 
• Legal-industry experience is a plus, not a requirement