The problem
Reporting requests came in from across the marketing organization and competed for the same eight people. I found three bottlenecks: ownership was unclear, priorities were set inconsistently, and requests arrived too loosely defined to build from. The team spent its time working out what was being asked instead of delivering it.
Intake
Requests came in through a form with three fields: what you need, the expected outcome and the team asking. The expected outcome was required. I wanted each requester to say what decision or problem the report would support, not just ask for another dashboard.
We then ranked requests by business value, urgency and the team's capacity, instead of working through them in the order they arrived.
A broad ask like "we need a dashboard" got questions back. What outcome are you after? Which metrics matter? Who will use it, and what will it help you decide? The answers set the scope. They also showed whether we needed a new dashboard at all, or whether an existing report already answered the question. Unclear requirements came out at the start, so there was less back and forth later.
Key decisions
- An expected outcome on every request, required. Reporting throughput went up 70%.
- Clear milestones, owners and operating routines across the engineering workstreams. Delivery speed went up 25%.
- Ask about the problem before agreeing to the work: what the report is worth, and whether another approach would meet the need better.
- Maintenance and improvements in one plan. The team completed 60 engineering improvements and fixes to enterprise analytics systems while still delivering new reporting.
- Fewer tools: project records moved from ClickUp to SharePoint.
Mixpanel to Databricks
I directed the migration to lower platform costs, scale further and give reporting a more reliable foundation. The work was more than moving data: the reports had to stay reliable and useful for the people who used them. I coordinated the work across the analytics team and used SQL myself to check it, comparing records between the two systems, checking the aggregation logic and investigating discrepancies before we relied on the new data.
How we measured
We tracked reporting requests from intake to completion in the team's request records and compared the periods before and after the new workflow. Over a comparable period, the team completed 70% more requests, and delivery speed went up 25%.
What I'd do differently
Set the intake criteria, the baselines and the success measures even earlier. The sooner a baseline exists, the easier it is to show what a process change did.