When I first stepped into management, I made the classic rookie mistake: I treated AI like a glorified copy editor. I used it to polish rough drafts, tweak bullet points, and make my weekly reports sound a little more “executive.”
It didn’t take long to hit a wall. AI is only ever as good as the context you feed it. Garbage context in, generic corporate jargon out.
Recently, with smarter models and way better data plumbing at work, I decided to flip the script. Instead of asking AI to just write for me, I started using it to understand what my team is actually experiencing day-to-day.
My Data Pipeline: Cutting Through the Noise
Let’s be real: as an engineering manager, keeping tabs on every single commit, pull request, Slack thread, and Jira ticket is a fast track to burnout.
My goal was simple: build a lightweight pipeline that aggregates all these scattered breadcrumbs and turns them into a coherent narrative.
Here’s how I structured the workflow:
- Data Extraction: Hooked up MCP (Model Context Protocol) to pull real-time activity straight into my local environment.
- Standardization: Normalized everything into clean JSON so the LLM can parse and reason over it without hallucinating.
- Connecting the Dots: Honestly, this was the hardest part. Bridging the disconnect between messy Jira tickets and actual GitHub progress took some serious wrestling with our internal workflows.
The Managerial “Aha!” Moment
Building the collection layer was definitely tedious and a bit messy at first. But once the pipeline clicked? The turnaround time for generating actionable team insights dropped from hours to seconds.
More importantly, it gave me something a static spreadsheet or weekly standup never could: genuine empathy for the day-to-day grind. I could suddenly see the invisible cognitive load behind complex PR reviews and blocker resolutions. It helped me understand not just what was shipping, but how and why.
What’s Next?
This was never just about saving time on reporting—it’s about leveling up my Managerial Intelligence. I already see where our tracking has blind spots, and I’m itching to build the next iteration.
In my next post, I’ll break down the exact data schemas I’m using to make these signals even more actionable.
If you’re also an engineer-turned-manager trying to bridge the gap between raw dev data and high-level leadership, I’d love to hear how you’re tackling it!