Running Cross-Team Delivery Without Technical Authority

What this is

As a technical project manager on the platform-vendor side, I owned the planning cadence between a customer and a platform built as independently-owned microservices — each service run by its own team, each with its own technical lead. My job was not to build any of it. It was to turn what the customer wanted into work the engineering teams could commit to, and to keep that commitment visible and current.

How I operated

• Ran a recurring monthly planning cycle directly with the customer: reviewing upcoming feature requests, clarifying intent and priority, and confirming what mattered most for the coming cycle.
• Took each feature request and broke it down into implementable pieces, mapped to the specific service teams whose scope it touched — since a single feature could cross several independently-owned services with no shared team to default to.
• Worked directly with engineers and their leads on estimation: what the work actually involved, what was uncertain, and what a realistic timeline looked like, rather than accepting a top-down date and working backward.
• Converted those estimates into a committed timeline per task, with an owner and an expected finish date, and tracked it through completion — daily coordination, backlog refinement, and milestone tracking across the teams involved, run in Jira.
• Managed resourcing in Jira as well: which engineers across which service teams had capacity for the committed work, and where a team was overcommitted before it became a missed date rather than after.
• Built a change-request tracking tool (a required Slack-based intake and approval flow) when Jira’s ticket-level view wasn’t enough to answer the question I actually needed answered: whether every specific item touching a release was genuinely ready — reviewed, QA’d, and accounted for — before it merged to master or went out to the customer. Any change to dev or production went through it: item, impact, downtime if any, QA status, a link to the change itself, and a named approver, with my review required before it shipped. This sat alongside Jira rather than replacing it, closing the gap between “the ticket is in progress” and “this specific piece is actually safe to ship.”
• Coordinated directly with QA throughout, not just at the end: confirming what had been tested, what hadn’t, and what was still open, so a task’s status reflected real validation, not just development being done.
• Served as the single point of continuity between the customer’s expectations and each service team’s actual capacity, so neither side operated on a guess about the other.

Where it got harder

Estimation is not a one-time event. Scope shifted mid-cycle, a service team’s capacity changed because of an unrelated priority, or a dependency between two services turned out to be tighter than assumed. My job in those moments was the same as at planning time: go back to the engineers who owned the affected work, get a real re-estimate, and update the customer-facing timeline before the gap became a surprise on either side — not after.

Outcome and value

The recurring cadence turned customer requests into work engineering had actually estimated and committed to — owner, date, and status visible across independently-owned service teams that had no shared plan to default to. The change-request tracking tool closed the gap between “the ticket is in progress” and “this specific item is genuinely safe to ship,” so release readiness rested on real validation rather than ticket state. When scope or capacity shifted mid-cycle, the customer-facing timeline was corrected before the gap became a surprise. The value is a commitment that stays real because the people doing the work estimated it and someone kept checking it — not because anyone could compel it.

What this shows about how I operate

Delivery planning is not a single date handed down and defended. It is a cadence: request in, broken down, estimated by the people doing the work, committed with an owner and a date, and revisited honestly when something changes. I do not carry technical authority over the teams whose estimates I coordinate — the commitment has to be real because I asked for it and checked it, not because I could compel it.