SOLOVIS / SENIOR PROGRAM MANAGER
From project-based teams with inconsistent ways of working to five coordinated pods, supported by AIPDLC and shared AI context.
I helped redesign how five pods worked together when faster AI-assisted development exposed inconsistent processes. The turning point was aligning roles, collaboration and estimation standards before encoding those practices into AI skills.
My contribution: process design · leadership alignment · pod design · QBR input coordination · reusable skills · formal OKR reviewsTHE CHANGE / FROM FRAGMENTATION TO SHARED OPERATIONS
Coverage across five pods, not a one-to-one assignment of each area to a pod. Solution builders were POs/PMs and could also serve as pod facilitators.
Qualitative assessment, informed primarily by internal ratings and team feedback.
Reported throughput relative to the previous delivery model.
Reported improvement in resolving support issues.
Separate reported improvement in meeting service commitments.
Previous model · index 100
New model · index 300
LEADERSHIP DECISION / AIPDLC ADOPTION
AIPDLC failed to take hold multiple times. I helped shift the response toward pod design, clearer roles and shared working agreements.
Teams were organized by project without consistent ways of working. AI accelerated output but could not establish agreement between people. Story-point estimates also lacked a shared approach.
We adopted pods with facilitators and solution builders, aligned internally on estimation standards, and provided a team-specific story-pointing skill. I helped design the pods and secured leadership buy-in for AIPDLC.
Process design and leadership alignment, pod-design contribution, and product-insights and prioritization skills. The changes depended on collaboration across product areas, data engineering and shared services.
Human agreement on roles, expectations and estimation before automation could reinforce them. The lesson was to address the collaboration gap rather than expect AI to standardize work on its own.
This is a reconstruction from my account of the work, not a reproduced executive approval record. I contributed to pod design and led through influence; I do not claim sole ownership of the organizational redesign. The experience changed how I approach automation: first establish working agreements, then encode the agreed behavior, and use team feedback to revise the standard.
PLANNING & EXECUTIVE COMMUNICATION
Solovis: Product Operations coordination for QBRs and executive readouts: working with teams on needed metrics and feeding the internal AI tool with product insights and a shared fact base. I also formally reviewed OKRs and supported leadership alignment around AIPDLC.
AFS: quarterly and Program Increment planning, capacity and dependency coordination.
Coordinated metric inputs with teams and supplied product insights and factual context to the internal AI tool to support the review process.
The role was Product Operations coordination. The detailed preparation schedule below illustrates the workflow; it does not imply sole ownership of executive decisions.
Illustrative cadences and timing. Company records and numeric targets are omitted.
Inputs: objectives, intake, capacity, dependencies and previous results.
Coordinate: pod owners submit proposals before a shared cutoff; resolve conflicts before commitments.
Output: sequenced roadmap, launch windows, owners and deferred work.
Inputs: Loom summaries, Jira status, blockers and release readiness.
Coordinate: facilitators confirm exceptions and route cross-pod decisions.
Output: changed dates, dependency actions and escalations.
Inputs: actual versus target, evidence quality and guardrail measures.
Coordinate: metric owners validate evidence; distinguish outcome gaps from activity.
Output: continue, adjust or stop; named corrective actions.
Inputs: outcome trends, customer signals, delivery constraints and next-quarter options.
Coordinate: reconcile pod inputs into one leadership pre-read.
Output: strategic trade-offs, capacity choices and updated priorities.
Illustrative timing. Adapt the preparation window to team size and reporting complexity.
A retrospective reconstruction, not a reproduced company document, meeting transcript or dated executive approval.
| Objective | Key-result measure | Definition and evidence | Guardrail |
|---|---|---|---|
| Improve delivery predictability | Commitment completion and carryover | Agreed work completed in the window ÷ work committed at its start; report scope changes separately. Use Jira snapshots and completion records. | Reopened work, defects and unplanned scope. |
| Shorten idea-to-decision time | Median days to a recorded decision | Complete-intake timestamp to proceed, pivot or stop decision; include all outcomes and show sample size. | Decisions reopened for missing evidence. |
| Improve release efficiency | Engineering-done to production lead time | Median and 90th percentile across comparable releases, using work and deployment records. | Rollback, failure and rework rates. |
| Improve support reliability | Resolution time and SLA attainment | Track resolution duration by severity and service clock; SLA attainment = eligible tickets meeting the target ÷ eligible tickets. Report changes separately. | Reopened tickets, backlog age and severity mix. |
| Improve access to team information | Search failure, adoption and time-to-information | Consistent search tasks, defined active users and elapsed time to the correct answer; keep denominators and review windows stable. | Answer accuracy and source freshness. |
For each KR, set an internal baseline, target, deadline and accountable owner. Numeric targets and company records are intentionally omitted. These definitions demonstrate measurement design, not additional achieved results.
MEASUREMENT WITHOUT COMPANY DATA
The reported outcomes are shown above. The measurement framework below explains how to assess them while keeping company values and records private.
Methodology example, not a claim that these exact controls were applied historically. It does not retroactively establish a formula for the reported results.
| Measure | Calculation approach | Make the comparison fair |
|---|---|---|
| Quarterly feature throughput | Features released in the comparison quarter ÷ features released in the baseline quarter. A ratio of 3 is 3× throughput. | Use a stable definition of a feature and equivalent reporting windows. Report staffing, feature size, scope and release-policy changes alongside the ratio. |
| Resolution speed | If speed is defined as the inverse of resolution duration: (baseline duration ÷ new duration − 1) × 100. A percentage reduction in duration is a different calculation. | Compare equivalent ticket severity and service-clock rules; include reopened cases and review the median and long tail separately. |
| SLA compliance | Eligible tickets meeting the SLA ÷ all eligible tickets. Relative improvement = (new compliance ÷ baseline compliance − 1) × 100; percentage-point change = new minus baseline. | Keep targets, exclusions and ticket mix consistent. Distinguish response and resolution SLAs. |
| Information visibility | Report search failure, dashboard adoption and time-to-information separately. Define and document any composite weights before combining them. | Use comparable search tasks, the same definition of active use, and answer-quality checks. Do not average unlike measures without normalization. |
| Team velocity | Completed story points per iteration, interpreted against that team’s calibrated historical range. | Keep iteration length and done criteria stable; account for staffing and support load. Pair velocity with carryover, cycle time and defects. |
Visibility improved significantly based on a qualitative assessment informed primarily by internal ratings and team feedback. No percentage improvement is asserted.
| Before | After | Evidence type |
|---|---|---|
| Status discovery required searching through Jira. | Individual Loom updates and transcripts made current context easier to access. | Reported workflow change and internal ratings. |
| Collaboration and working standards varied across project teams. | Pods, clearer roles and shared expectations supported coordination. | Reported team feedback and operational experience. |
| Data engineering operated reactively. | Clearer roadmaps and expectations supported more proactive work. | Qualitative account of the change. |
This documents a retrospective before-and-after account. Rating scales, respondent counts, dates and underlying company records are not reproduced; it is not a quantified pre/post study.
Search failure rate, dashboard adoption and time-to-information remain useful complementary indicators to instrument. No percentage result is inferred from those indicators.
Results are reported by Grace. The two 60% figures refer to separate improvements in support resolution speed and SLA compliance. A speed improvement is not automatically a 60% reduction in resolution time; a compliance improvement is not a 60-percentage-point increase. Underlying company values, calculation details, quarterly feature counts and comparison periods are not disclosed in this portfolio. These outcomes reflect the broader operating-model change, not an isolated causal estimate of AI impact.
THE POD MODEL / PEOPLE + DAILY RHYTHM
Five pods across product areas, data engineering and shared services. Pod numbering is illustrative; it does not assign a specific product area to a numbered team.
ZOOM IN / POD 1
Approximately 10 people in the pod. Role counts and individual assignments are not shown.
CONNECTIONS
Role descriptions and routing illustrate the operating model; they are not a reproduced company org chart.
ILLUSTRATIVE DAILY SCHEDULE / LOCAL TEAM TIME
Who: pod facilitator, solution builders and team members.
Confirm priorities, ownership and blockers for the day.
Who: pod representatives and program coordination.
Resolve interdependencies and route decisions across pods.
Who: solution builder and relevant validators or team members.
Review acceptance evidence, findings and items needing clarification.
Who: each team member.
Share what changed, show relevant work, flag blockers and identify the next step.
The cadence sequence reflects the described workflow. Clock times, durations and participant routing are suggested for this visual, not historical meeting records. The UAT check-in is a coordination checkpoint, not the full testing window or automatic release approval.
THE INFORMATION FLOW
Team members share work updates and context.
Updates become searchable inputs for AI-assisted synthesis.
Surface discussion topics, obstacles and coordination needs.
Feed the shared AI tool with current team-work context.
Workflow based on my account of the implementation. Jira remained the work-status source; Loom transcripts added context. The diagram does not imply that every transfer was fully automated.
A CONCRETE CORRECTION / STORY POINTING
Story points were not standardized across teams. We aligned internally on an estimation approach and provided a story-pointing skill that worked for each team and supported velocity tracking.
Define what estimation considers and what makes a story ready to estimate.
Use each team’s reference stories and historical delivery context.
Suggest a size with rationale, uncertainty and missing information.
Discuss, adjust and agree the estimate before committing.
The problem and story-pointing skill are reported experience. The input/output contract below illustrates how to make that capability explicit; it is not an exported internal prompt.
01 / The lifecycle
I created AIPDLC with leadership buy-in. This diagram reconstructs the operating model; the detailed gates and scoring rubric are portfolio examples.
02 / Skills at the point of need
Request + product context → problem framing, evidence gaps and discovery questions.
PM chooses what to investigate.For [user], solving [problem] should change [metric], because [evidence]. Revise as evidence changes.
Start as a hypothesis; validate before investment.Problem + assumptions → testable interaction → user feedback → engineering handoff.
Demonstrate the concept, surface unknowns.Validated thesis + options + effort + risks → recommendation, trade-offs and success criteria.
Leadership decides the commitment.Individual roadmaps + evidence + estimates → comparable candidates and sequencing options.
PM and Engineering agree capacity.Jira changes + project links → affected teams, source evidence and requested action.
Teams confirm ownership and resolve risk.Confirmed: product-insights and prioritization skills, Claude prototyping, Rovo/Jira alerts. Value-thesis and business-case skill contracts are proposed extensions of the process, not verified production automations.
03 / Explainable AI-assisted scoring
Illustrative rubric, not historical Solovis scores or a live AI model. AI would suggest each rating with source links and uncertainty; people validate the evidence and decision.
Weighted score = Σ(rating ÷ 5 × weight). This example uses analyst-selected weights, not learned model confidence. 80+ prompts an investment review; 60–79 suggests more discovery; below 60 suggests reframe or park. None authorizes a release.
More discovery before commitment.
04 / The harness around the skills
Product modules
Individual roadmaps
Loom transcripts + blockers
User evidence + Jira records
Read authorized context → check freshness → retrieve evidence → draft output → flag uncertainty → route to an owner.
Claude · Jira / Rovo · Loom
Recommendation + sources
Owner + decision
Next action + due date
Outcome + learning
I helped design the five-pod model, created AIPDLC, built product-insights and prioritization skills, used Rovo dependency alerts, and owned the collaboration tool through Claude prototyping and engineering handoff. The shared Dreadnought environment supplied startup rules, modules and records; authorship of the full environment is not claimed. The controls shown here are a reconstructed design.
05 / Find friction. Improve the system.
Signal: reopened decisions or escaped defects.
Improve → evidence gate + acceptance checksTrack: rework rate; defects per release.
Signal: repeated status chasing and slow handoffs.
Improve → context reuse + targeted alertsTrack: manual coordination minutes; issue-to-owner time.
Signal: work waiting between stages.
Improve → smaller scope + clearer ownershipTrack: idea-to-decision time; blocked days; release lead time.
Additional measurement plan beyond the reported outcomes above. Compare equivalent work before and after each change; include review time, rework and feature scope when evaluating throughput.
Grace Bakalag / Selected work