The invisible internal platform team
An internal analytics platform team of 12 engineers supports 38 product teams. Its three-year-old charter says 'provide data infrastructure and dashboards.' Work arrives through Slack, a service desk, and direct requests to engineers. Last quarter the team completed 214 tickets but missed every committed roadmap item. Sixty percent of effort went to ad-hoc extracts and dashboard fixes; the rest split between platform upgrades and a data catalog project. Product teams complain about slow responses, while the platform manager reports 'we are busy but invisible.' The team measures story points and utilization. The service desk has only P1-P4 labels, and requesters choose the label themselves. An executive asks whether the team is a cost center or a product team. Two engineers are leaving, and headcount is frozen. The data catalog deadline is eight weeks away. The team has never interviewed its customers or analyzed its demand mix.
1. How would you establish this team's service purpose and customer, and what evidence would you gather?
Read the worked answer
Start by separating the charter from the purpose. Purpose is the outcome customers need, not the team's activity. Interview a stratified sample of the 38 teams: high-volume, high-value, and neglected. Ask what job they hire the platform for, what happens when it fails, and what they do instead. Analyze the last quarter's 214 tickets by requester, type, lead time, and rework. That reveals the real demand mix and whether ad-hoc extracts are a service or a defect. Define three to five service offerings with customers and outcomes, such as governed data access, production dashboard support, and platform upgrade. Write a purpose statement naming the customer, outcome, and boundary. Test it with the executive using demand data and the cost of unmanaged requests. Avoid the cost-center/product-team binary; frame the group as an internal service with explicit customers and value. Outputs: customer segments, service catalog, demand profile, purpose statement, and a list of what the team will stop doing.
2. Given 38 requesting teams and frozen headcount, what policies would you propose to reconcile demand and capacity?
Read the worked answer
Use demand data and service classes. Publish an intake policy: all requests enter one queue; requesters cannot set priority. Define classes by cost of delay and risk: Standard (5-10 day target), Fixed Date (committed events), Expedite (one at a time, sponsor required, four-hour response), and Intangible (best effort). Allocate capacity explicitly: for example 60% standard, 20% platform upgrades and catalog, 15% fixed date, and 5% expedite reserve. Capacity numbers matter: 12 engineers facing about 4.3 requests per day cannot promise 10-day lead time with 85 items in progress; cap total WIP around 45. Create a ready queue with entry criteria: data source identified, owner named, acceptance test agreed. Establish a service manager or product owner who triages daily against policy. Publish a service level for each class and report performance. For the catalog deadline, protect a fixed capacity slice and make the trade-off visible to the executive: every expedite displaces standard work. Handle the two departures by reducing commitments, not by raising WIP.
3. How should the team change its measures to reflect service purpose rather than activity?
Read the worked answer
Replace utilization and story points as primary measures. Utilization encourages starting work and hiding capacity; story points measure output, not service. Use lead time by class at the 50th and 85th percentiles, throughput by service, demand mix and unplanned percentage, due-date performance for fixed-date items, rework rate, and customer outcome measures such as time to first trusted dataset and dashboard adoption. Add flow efficiency (active time divided by lead time) and queue age. At team level, track WIP and blocked time; at service level, track end-to-end lead time from request to outcome. Review monthly with the executive and a customer panel. Keep utilization as a diagnostic only. This changes behavior: the team can show that 60% ad-hoc work is a policy decision, not a productivity failure. It also gives the executive a basis for choosing what the service will and will not do, rather than judging busyness.