Technical Program Manager

Full Swing is hiring a Technical Program Manager to own delivery for one or more engineering pods. This is an execution and accountability role, not a status-reporting role. You are the person in the room who knows exactly why a date will or won't hold, who has already resolved the dependency that would have blocked it, and who tells leadership the truth about risk before it becomes a surprise.

You will partner directly with engineering leads, QA, product, and design to turn ambiguous scope into a sequenced, resourced, credible plan, and then you will drive that plan to completion. You are measured on whether the things you own ship on the date you committed to, not on how well-organized your tracker looks.

Primary Functions

• End-to-end delivery for your assigned program(s) or pod(s), from scoping through release and post-release wrap-up.
• A single master timeline per program that reflects real engineering capacity and historical throughput, not optimistic guesses.
• Cross-team dependency mapping. You surface the dependency that will break the date and get it resolved before it does, not after.
• Release forecasts leadership can build on. If a date moves, you're the first to know, the first to say so, and you bring the recovery plan with you.
• A risk register that is actually driven to closure, not just maintained as a document.
• Program reviews and syncs built around decisions and unblocking, not readouts. If a meeting produces only a status update, it shouldn't be on the calendar.
• Direct accountability conversations with engineering, QA, and product owners when commitments slip, delivered constructively but without softening the truth.
• Post-release retrospectives that feed real changes back into estimation, sequencing, and how the next program is planned.
• Scope and trade-off input alongside Product, Design, and QA when schedule, quality, and scope come into tension.

WHAT SUCCESS LOOKS LIKE IN THE FIRST 90 DAYS

• You've mapped the real dependency graph for your program(s), not the one in the roadmap slide.
• You've built a forecast grounded in actual team throughput, and you've already flagged at least one date that needed to move, with a reason and a recovery plan attached.
• Engineering and QA leads see you as someone who removes their blockers, not someone who asks them to update a ticket.
• Leadership trusts your forecast enough to make commitments to the business based on it.