Prepared: May 8, 2026 Sources: METACON Jira project (live data), Cortex service catalog, O'Reilly DevDocs, ORM Service Tier Classifications CSV Audience: Engineering leadership, product management
The MetaCon team has 5 engineers (plus a director, engineering manager, project manager, product manager, and product director) responsible for the O'Reilly content ingestion pipeline and 38 services — including 10 Tier A services and 5 Tier B services. Tier A represents the highest criticality designation; an incident on any of these services is a platform-wide event.
The team runs at 40 story points per sprint (~8 points per engineer per sprint). Critically, only 1/3 of sprint capacity (~13 SP) is available for Pub/Sub migration work — the remaining 2/3 (~27 SP) is consumed by operational overhead, maintenance, and other committed work. This is itself a signal about team load, independent of the backlog question.
The Pub/Sub migration is approximately 64% complete. At 13 SP/sprint available for migration work, 5–7 sprints remain — roughly 2.5–3.5 months from today, putting completion in the July–August 2026 range at earliest.
After excluding tickets labeled suggest_closing, the active backlog stands at 271 tickets. Of those, 92 have story point estimates totaling 306 points — a hard floor of ~7.7 sprints of tracked work at current velocity. 66% of tickets are unestimated; if unestimated tickets average the same 3.3 points as estimated ones, the implied total backlog is approximately 897 points, or ~22 sprints. Four additional feature epics are currently being scoped and not yet decomposed into tickets.
The hiring process takes months. A decision made today will not produce a productive engineer for several months — a timeline that closely mirrors when the Pub/Sub migration is projected to complete. There is no meaningful benefit to waiting. Every month of delay is a month of additional backlog accumulation with no new capacity to address it.
5 acting engineers:
| GitHub Handle | Name |
|---|---|
| [REDACTED] | [REDACTED] |
| [REDACTED] | [REDACTED] |
| [REDACTED] | [REDACTED] |
| [REDACTED] | [REDACTED] |
| [REDACTED] | [REDACTED] |
Leadership, management, and product (non-engineering):
| Name | Role |
|---|---|
| [REDACTED] | Director |
| [REDACTED] | Engineering Manager |
| [REDACTED] | Project Manager |
| [REDACTED] | Product Manager |
| [REDACTED] | Product Director |
Sprint velocity: 40 story points/sprint = ~8 points per engineer per sprint. Effective Pub/Sub allocation: ~13 SP/sprint (1/3 of total capacity). Operational and other work: ~27 SP/sprint (2/3 of total capacity).
All open Jira tickets are listed as "Unassigned." Real work distribution is managed informally via Slack and standups and is not reflected in Jira.
MetaCon owns the platform content ingestion pipeline — the infrastructure that ingests publisher content into the O'Reilly Learning Platform and distributes it to all consuming services. 38 total catalog entries spanning 10 Tier A services, 5 Tier B services, 9 Tier C, 9 Tier D, and 5 untiered library/tooling entries.
All are ingressed on learning.oreilly.com and/or www.oreilly.com. An incident on any of these is a platform-wide event.
| Service | Role |
|---|---|
| Card Service | Metadata for content cards; primary front-end content API |
| Content Overlay Service | Content overlay data for the platform |
| Cover Image Service | Serves original and resized cover images |
| Epub Data Service | EPUB data backend; serves parsed epub content |
| Kaltura Service | Clip-level Kaltura video data |
| Media Storage Service | GCS abstraction layer; consumed broadly across the pipeline |
| Publisher Data Service | Publisher identity and work listings; source of truth |
| Scenario Metadata Service | Serves Katacoda scenario metadata to the platform |
| Topic Graph | Platform-wide topics, classification, and tagging API |
| Video Metadata Service | Video and audiobook metadata backend API |
| Service | Role |
|---|---|
| Falcon | Search-as-a-service (legacy; active migration to Miso underway) |
| Integrations Service | Delivers content metadata to external LXP partners |
| Miso Delivery Service | Feeds content metadata to Miso search index |
| Platform Retirement Service | Serves title retirement status; affects content availability |
| Talent Service | Contributor attribution for all works on the platform |
| Service | Role |
|---|---|
| Content Submission Service | Parses ONIX files; creates Portal submissions |
| Cowbird | Ingestion entry point and source of truth for the content pipeline |
| Epub Ingestion Service | EPUB ingestion, conversion, and validation |
| Ingestion Monitoring Service | Monitors pipeline health via log consumption |
| Library Distribution Service | Sends metadata to MARC record partner (OCLC, EBSCO) |
| Magpie | Legacy content orchestration; still in Canon's critical path |
| Stork | Delivers Magpie content to downstream sources |
| Transcription Service | Generates video/audio transcriptions and translations |
| Video Ingestion Service | Validates videos/audiobooks and uploads to Kaltura |
Book v1 Facade, Content Filters, Content Ingestion Messages, Content Metabase, Epubutils, Media Storage Client, Ourns Python, Pyli, Safari Metadata.
Content Ingestion Integration Tests, Liten, Ourns JS, Ourns Kotlin Multiplatform, Unified Ourns. These are libraries or CLI tools with no production service footprint and do not warrant tier classification.
MetaCon sits at the center of the messaging fan-out. Canon publishes product messages consumed by content-type microservices, which each publish content messages consumed by 8+ downstream teams. MetaCon must coordinate both publisher and subscriber migration across this entire graph — and several of the services in that graph are Tier A.
Additional complexity:
-
MetaCon's "large messaging" architecture (full metadata embedded in messages, not just CUD events) makes schemas more complex than typical services
-
No wildcard subscriptions in Pub/Sub — each RabbitMQ routing key pattern becomes a separate subscription
-
Legacy Magpie is still invoked by Canon for retire/block/ingest operations and its migration path is undefined
-
The Ingestion Monitoring Service consumes RabbitMQ log messages and likely needs its own migration path
| Phase | Status |
|---|---|
| Phase 0–3: Infra, dual-publish setup, EDS/VMS migration | ✅ Complete |
| Phase 4: Product/Academy/Publisher CUD message subscribers (most services) | ✅ Mostly complete |
| Phase 4: Content message subscribers | 🔄 In progress (active sprint) |
| Phase 4: Content message publishing release gate | ⏳ Blocked on subscriber completion |
| Phase 5: RabbitMQ code removal | ⏳ Not started |
16 tickets remain open. 8 are estimated (32 SP total); 8 are unestimated, with 4.0 pts assumed per ticket based on the average of estimated Pub/Sub tickets.
| Ticket | SP | Status | Description |
|---|---|---|---|
| METACON-3219 | 3 | In Progress | Test Pub/Sub publishing for content messages in CMS |
| METACON-3235 | 3 | In Progress | Add Pub/Sub subscribers for academy CUD messages in Integrations |
| METACON-3255 | 3 | In Progress | Add Pub/Sub subscriber for product messages to VMS |
| METACON-3218 | 5 | Ready for QA | Add Pub/Sub publisher code for content messages |
| METACON-3253 | 3 | Needs Review | Add Pub/Sub subscriber for product messages to Talent Service |
| METACON-3256 | 4* | Needs Review | Add Pub/Sub subscriber for product messages to Magpie |
| METACON-3220 | 5 | To Do | Code content message Pub/Sub subscriber |
| METACON-3210 | 5 | To Do | Add ingestion logging message Pub/Sub subscriber |
| METACON-3242 | 5 | To Do | Use ingestion library for ingestion logging messages |
| METACON-3221 | 4* | To Do | Add Pub/Sub subscriber for content messages to all services |
| METACON-3234 | 4* | To Do | Migrate to Pub/Sub subscribers for CUD messages in Falcon |
| METACON-3222 | 4* | To Do | Remove RabbitMQ consumers, delete queues (needs all subscribers migrated) |
| METACON-3223 | 4* | To Do | Remove RabbitMQ code from content-ingestion-messages (needs 3222) |
| METACON-3344 | 4* | To Do | Replace feather.user.update.* consumer with auth.user-topic subscriber |
| METACON-3289 | 4* | To Do | Duplicate search.query messages in Pub/Sub |
| METACON-3347 | 4* | To Do | Release Pub/Sub content message publishing (gate ticket) |
*Assumed at 4.0 pts (average of estimated Pub/Sub tickets). Actual may be higher for METACON-3222 and -3223 (RabbitMQ removal touches many services), METACON-3234 (Falcon is Tier B with known test coverage gaps), and METACON-3221 (fan-out across all services).
Sprint projection:
Only 1/3 of sprint velocity (~13 SP/sprint) is available for Pub/Sub work, with the remainder consumed by operational overhead and other commitments.
| Scenario | Total Pub/Sub SP | SP/Sprint Available | Sprints Remaining | Estimated Completion |
|---|---|---|---|---|
| Low end (4.0 pt average for unestimated) | 64 SP | 13 SP | ~4.9 sprints | Late July 2026 |
| High end (larger cleanup/fan-out tickets) | ~88 SP | 13 SP | ~6.8 sprints | Late August 2026 |
| Metric | Value |
|---|---|
| Raw open tickets (all statuses, non-epic) | 363 |
Excluded: tickets labeled suggest_closing |
92 |
| Substantive active backlog | 271 tickets |
| Tickets with story point estimates | 92 (34%) |
| Tickets without story point estimates | 179 (66%) |
| Total estimated story points | 306 SP |
| Hard floor: sprints to clear estimated backlog | ~7.7 sprints |
| Implied ceiling: sprints to clear full backlog | ~22 sprints (speculative — see note below) |
Note on implied ceiling: If the 179 unestimated tickets average 3.3 points (the current estimated average), total implied backlog is ~897 SP = ~22 sprints at 40 pts/sprint. This should be treated as an order-of-magnitude planning bound, not a forecast. The 66% unestimated rate remains a planning risk — a targeted grooming session would substantially improve projection accuracy.
Note on effective backlog burn rate: With 2/3 of sprint capacity (~27 SP) consumed by operational overhead and other committed work, the team's capacity for proactive backlog reduction is severely limited during the migration period. Post-migration, if operational overhead stabilizes, more capacity will open up — but the current overhead fraction suggests the team is already running close to capacity on maintenance alone.
suggest_closing label (92 tickets): A backlog hygiene label identifying tickets that have been flagged as candidates for closure. These have been excluded from all backlog counts above. The set is dominated by METACON-359 (Content Operations & Routine Maintenance), which accounts for 50 of the 92 tickets. The oldest date to 2019. These should be formally closed to remove false signal from the board.
Stale epics (recommend closure, ~18 epics): Epics are excluded from ticket and story point counts by convention, but 18 open epics have had no activity in over a year and are candidates for closure independently of the suggest_closing label. These include four 2020 LANE2-OUTCOME planning epics (METACON-21, -27, -236, -403) that predate the current team structure and are almost certainly obsolete, plus several epics marked "In Progress" whose child work has long since stopped. Closing these would clean up the board without affecting the backlog counts above.
| Epic | Summary | Open Tickets | Estimated SP | Implied SP* |
|---|---|---|---|---|
| METACON-3027 | Pub/Sub Migration (current focus) | 16 | 32 | ~64 |
| METACON-2832 | Integrations Ops & Maintenance | 9 | 18 | ~30 |
| METACON-3292 | Self-Serve Academy Creation | 5 | 3 | ~15 |
| METACON-2721 | Linking Content Editions/Translations | 4 | 6 | 6 (fully estimated) |
| METACON-2720 | Distinct Content Filter Rules by Vendor (LDS) | 4 | 5 | ~13 |
| METACON-3110 | Jupyter Notebook Content Type | 3 | 6 | ~10 |
| METACON-3184 | Academy Tracks as a Content Type | 3 | 3 | ~10 |
| METACON-3005 | Soft Skills/Manager Academies — Back End | 3 | — | ~10 |
| METACON-2367 | Topic Correction: Admin UI Multi-Topic Tagging | 3 | — | ~10 |
| METACON-2438 | Multi-topics by Score Threshold | 2 | — | ~7 |
| METACON-2927 | Audiobook Chapter Names | 2 | — | ~7 |
| METACON-3126 | Integrations Metadata APIs | 2 | — | ~7 |
| (other epics + orphaned tickets) | ~78 | — | — |
*Implied SP applies the 3.3-point average to unestimated tickets. Treat as rough planning inputs only.
Two key services are below the "Basic Quality" tier on the service-health-backend scorecard:
| Service | Tier | Line Coverage | Branch Coverage |
|---|---|---|---|
| Magpie | C | 97.23% | 78.09% |
| Falcon | B | 95.67% | 88.44% |
Django upgrade debt is compounding — the 4.2 prep work (METACON-2310) was never completed, and 5.2 tickets have already been created on top of it:
-
METACON-2310: Django 4.2 upgrade prep — still open
-
METACON-3197: A-tier services → Django 5.2
-
METACON-3200: B/C-tier services → Django 5.2
Four scope statement tickets are in progress, each expected to generate 10–30+ new tickets based on comparable MetaCon integration work:
| Ticket | Scope Item |
|---|---|
| METACON-3318 | External Learning Plan API |
| METACON-3317 | Tracks as a Content Type |
| METACON-3315 | Cornerstone Integration |
| METACON-3298 | ServiceNow University Integration MVP |
At the current 3.3-point average, a 20-ticket epic adds ~66 SP to the backlog. Four such epics adds ~264 SP — roughly 6–7 additional sprints of work arriving in the near term, on top of the existing implied backlog.
-
MeasureUp Integration — [REDACTED] and [REDACTED] are in negotiations with MeasureUp to incorporate their practice tests into the platform. This project is still in the discovery phase.
-
Custom Academies — A customer has asked for a private custom Academy. This project is still in the discovery phase.
-
PDF Conversion — PDF Conversion is currently on track to be decommissioned due to unmaintained dependencies and lack of SOC2 compliance. There are some attractive options for replacing these dependencies, but further work needs to be done to evaluate these and incorporate one into the pipeline.
5 engineers owning 10 Tier A services and 5 Tier B services is a substantial operational responsibility at steady state. Tier A services require the highest level of operational attention; a failure on any is a platform-wide incident affecting all users. MetaCon carries the highest Tier A service count of any engineering team at O'Reilly.
The capacity picture is compounded by overhead: with only 1/3 of sprint velocity (~13 SP) available for the team's primary initiative, 2/3 of capacity (~27 SP per sprint) is consumed by operational work, maintenance, and other commitments before the backlog is even considered. This overhead fraction is consistent with what would be expected for a 5-person team responsible for 15 tiered production services — but it leaves very little room for forward progress.
At full 40 SP/sprint, the implied backlog ceiling is ~22 sprints. Given that much of available capacity is consumed by operational overhead, the backlog is not being meaningfully reduced at current staffing levels. Four incoming feature epics will add a further ~264 SP in the near term.
A 6th engineer adds approximately 8 SP/sprint — a 20% capacity increase — and creates meaningful headroom for backlog reduction and absorption of incoming scoped work without displacing operational coverage.
The hiring process takes months. Given the revised Pub/Sub projection of 5–7 sprints (~2.5–3.5 months), the hiring timeline and migration completion timeline are nearly identical. A hire started today could arrive just as the migration wraps up — or while it is still in its final sprints. Either way:
-
There is no benefit to waiting until after the migration. The timelines overlap. Waiting only ensures the new hire arrives into a post-migration team with a cold start, rather than having any opportunity to ramp up alongside the work.
-
The backlog accumulates during the hiring gap. Active integration failures (METACON-2832) are going unaddressed today. The four scope statement tickets will decompose into full epics during this period. Django upgrade debt compounds. Every month of delay is a month of additional accumulation.
-
Starting now is the earliest possible action. There is no upside to delay.
Structured as a 6-month ramp. Tier 1 work is fully unblocked and independent from the active migration.
Tier 1 — First Sprint (available on day 1)
| Work | Tickets / SP | Rationale |
|---|---|---|
| Integrations Ops & Maintenance (Degreed) | 9 tickets, ~30 implied SP | Active delivery failures; self-contained; immediate value |
| Django 5.2 upgrade — B/C-tier services | METACON-3200 | Mechanical; good for learning the service portfolio |
| Security vulnerability triage | METACON-3346 and similar | Reactive but important; good first contribution |
| Backlog grooming (stale tickets) | ~30 candidate tickets | Productive onboarding activity; clears false signal from backlog |
Tier 2 — Post-Migration Ramp (sprint 2–4)
| Work | Tickets / SP | Rationale |
|---|---|---|
| Library Distribution Service content filter rules | METACON-2720: ~13 implied SP | Scoped, isolated, cross-team visibility (OCLC, EBSCO) |
| Jupyter Notebook Content Type | METACON-3110: ~10 implied SP | New content type; well-documented pattern |
| Linking Content Editions/Translations | METACON-2721: 6 SP (fully estimated) | Cross-team coordination with FLEX2; good platform context |
| Django 5.2 upgrade — A-tier services | METACON-3197 | Higher stakes; appropriate after B/C-tier experience |
Tier 3 — Owns New Scope (sprint 5+)
| Work | Status | Rationale |
|---|---|---|
| Cornerstone Integration | Scope statement in progress | First integration they own end-to-end |
| ServiceNow University Integration MVP | Epic created, not decomposed | Greenfield; clear ownership opportunity |
| External Learning Plan API | Scope statement in progress | API-first; well-defined spec deliverable |
| Academy Tracks as a Content Type | METACON-3184: ~10 implied SP | New content type; foundational platform work |
With a new hire absorbing Tier 1 work, the current 5 engineers no longer need to context-switch for Degreed delivery failures, security remediations, or Django upgrade prep — protecting the 1/3 of sprint capacity allocated to Pub/Sub and reducing the operational overhead fraction that currently consumes 2/3 of velocity.
| Finding | Confidence | Limitation |
|---|---|---|
| 5 acting engineers | High | Directly from Cortex IDP group, corrected for non-engineering roles |
| 10 Tier A, 5 Tier B services | High | Confirmed via Cortex metadata and ORM Service Tier Classifications CSV |
| 40 SP/sprint velocity | High | Provided by team; not derived from Jira |
| 1/3 capacity (~13 SP) available for Pub/Sub | High | Provided by team |
| Pub/Sub: 5–7 sprints remaining | Medium | 50% of remaining tickets unestimated; some cleanup tickets may run larger than assumed 4.0 pt average |
| Backlog floor: ~7.7 sprints (306 SP) | High | 34% of tickets estimated; still likely understates real work |
| Backlog ceiling: ~22 sprints (~897 SP) | Low | Assumes unestimated tickets average 3.3 SP; treat as planning order-of-magnitude only |
| Upcoming scope adding ~6–7 sprints | Low | Scope statements not yet decomposed into tickets |
| Django upgrade as manageable new-hire work | Medium | A-tier service upgrades carry real regression risk |
Highest-impact gap: 66% of active backlog tickets are unestimated (179/271). A single grooming session to estimate or discard these tickets would dramatically improve projection reliability and is recommended before any capacity planning conversation is finalized.
Other missing data:
-
Status of the Pub/Sub migration tracking spreadsheet — may have more granular cross-service completion status
-
Magpie's intended role post-Pub/Sub (documented as legacy but still in Canon's critical path)
-
Whether any of the ~76 unestimated, non-stale orphaned tickets are high-priority bugs vs. feature requests
-
What specifically comprises the 2/3 operational overhead — understanding this in more detail could identify whether any of it could be reduced or automated
| Resource | URL |
|---|---|
| METACON Jira Board | https://intranet.oreilly.com/jira/secure/RapidBoard.jspa?rapidView=212 |
| Pub/Sub migration tracking spreadsheet | https://docs.google.com/spreadsheets/d/1WggkbDWgn-PYx13C27F2i_EM1HPTw_aXmJ5zxCItMxs |
| Pub/Sub migration Slack | #tmp-pubsub-migration |
| Team Slack | #team-content-and-metadata |
| Ingestion monitoring dashboard | https://ingestion-monitoring-service.platform.gcp.oreilly.com/admin/product_tracking_issues |
| Pub/Sub overview (DevDocs) | https://devdocs.common-build.gcp.oreilly.com/docs/guide/chassis/migrations/explanation-rabbitmq-to-pubsub-overview.html |