How I discovered engineering bottlenecks in Slack

As a platform engineer, I've always been drawn to the technical and analytical side of things. Numbers, data, analytics. Now, as a founder, I regularly review reports about developer productivity. Metrics like time to 10th PR, MTTR, etc

But a part of me wonders if this really tells the whole story. It tells the numbers story, but what about the human factor? How do engineers actually experience our SDLC day-to-day?

According to the metrics, they might be shipping at a great pace, but how do they feel about it? Are there points of friction, frustration even, that can't be found in developer productivity metrics or surveys?

We already track lots of metrics at Port like DORA and SPACE in Port. We also run surveys for more open-ended feedback. But there's a complementary layer of leading indicators we haven't systematically captured. And I think that's where a ton of insight is hiding.

It was actually an engineer at Port that came up with a clever idea.

When we were talking about identifying pains, he said: "If you really want to see what's slowing us down, just look at our conversations in Slack"

It took me a second to realize it, but he's 100% right.

It used to take a whole team of NLP researchers to gather and analyze qualitative signals to get these kinds of insights.

But in the past year, that's no longer needed.

Today, you can just do that thanks to MCP and a great prompt (which I'm giving away).

The best place to start is Slack, purely because the volume of conversation is greatest there. Without even realizing it, that's where developers go first when something isn't working the way they expect it to.

Conversations reveal the gap between what developers expect in their day-to-day life and what actually happened. Every question they ask is an opportunity to improve.

In other words, Slack is the canary in the coal mine. Conversations surface friction as it happens, before it becomes measurable delivery delays.

So let's try it. I'm going to use the prompt on Port's Slack account, show you the highlights of the results, and share the prompt with you.

(I'd also love to hear what this prompt uncovered in your Slack)

The prompt

1. Open Claude Pro or ChatGPT Pro
2. Add the Slack Connector/MCP
3. Run the following prompt. Make sure to edit the list of channels to analyze.

You are connected to our Slack. Your job is to produce a VP-friendly snapshot of where engineering is getting stuck across the SDLC — based on what engineers actually experience and say in Slack. Treat it as a live DevEx sensor.

SCOPE
- Time: Last 90 days (use 180 only to validate patterns)
- Channels to scan: [** ENTER YOUR CHANNEL NAMES HERE - YOU CAN USE WILDCARDS **]
- Skip: DMs, social threads, purely informational posts

WHAT COUNTS AS FRICTION
Explicit signals like:
- Blocked work ("waiting on", "who owns", "need access", "stuck")
- Slow loops
- Confusion (unclear ownership, outdated docs, repeated questions)
- Fear ("don't touch X", "defer", scary deploys)
- Workarounds ("for now", "temporary", "manual step")

Implicit signals like (critical—friction without frustration):
- Same questions repeating across weeks
- Same experts repeatedly pinged
- Long threads for simple tasks
- Workarounds becoming normal

OUTPUT (max 2 pages)

1. EXEC SUMMARY
Top 5 friction themes, ranked by: frequency × shipping impact × blast radius
For each: Problem (1 line) | SDLC stage | Who's affected | Signal strength (H/M/L)

2. EVIDENCE (critical—this is the proof)
For each theme provide:
- 3-5 specific Slack examples with direct links for persistent issues
- Quote the actual message (or paraphrase if sensitive)
- Include: channel, date, and context
- Note any implicit patterns (e.g., "this question appeared 4x in 6 weeks")

3. ACTION RADAR
For each theme: Fix direction | First small win (1-2 weeks) | Owner | Effort (S/M/L)

RULES
- Prefer patterns across teams and time over single loud threads
- Separate symptoms from root causes
- Flag single points of failure even if infrequent
- Always include links to Slack messages as evidence
- No filler. Write for a VP with 5 minutes.
  

Wondering why I wrote the prompt this way? Here’s how I thought about it:

Implicit over explicit friction: I noticed that the worst friction doesn't actually always sound frustrated. It can sound quite normal. "Who owns this?" repeated 4x across teams is worse than one angry rant.

90 days, not 30: 30 days catches incidents. 90 days catches patterns (but not too long that we’re uncovering things we’ve already solved)

Frequency × impact × blast radius: The multiplication surfaces problems that are frequent enough to be a pattern, painful enough to slow delivery, and widespread enough to be systemic.

VP with 5 minutes: Forces the model to cut filler and lead with the headline.

Links as evidence: Forces the model to ground findings in real messages. That way you can verify and correlate against your quantitative data.

(Like any prompt, you should tweak it to your specific needs)

Uncovered at Port: Support & Engineering Ping-Pong

Over the past 90 days, the prompt found a recurring pattern: support tickets landed in the wrong team's channel, then got redirected, sometimes multiple times before reaching the right owner.

Here are some of the Slack messages that revealed this:

• "Please move this ticket to #rnd-ecosystem-support, they own the integrations logs"
• "Can you move this ticket to #rnd-spotlight-support? Pages API is owned by them"
• "Since it's in the marketing site... this should be addressed to the marketing team and not the R&D"

Three times in four days, a ticket landed in the wrong team's channel and had to be redirected.

Here's the rest of the output from Claude:

SDLC stage: Developer support / cross-team handoffs

Impact: Engineers spending time redirecting instead of solving. Customers waiting longer.

What we learned: Ownership boundaries are unclear—or at least not documented where people look first.

How it complemented our metrics: Our ticket resolution metrics looked fine. But they didn't show the hidden toil of routing. The friction was invisible until we read the conversations.

How to fix it: A workflow in Port that uses an enriched "team ownership" field (and its relations) in our tickets to auto-route by keyword to the relevant team. Small config change, but we wouldn't have prioritized it without seeing the pattern.

Why not just use quantitative data and surveys?

We measure everything at Port. DORA, cycle time, deployment frequency. That's table stakes.

But here's what doesn't show up in any of those dashboards:

• A 54-message Slack thread debating who owns a service. Three people troubleshooting the same flaky test for the fourth time this month.
• A new hire asking the same question someone asked six weeks ago.

Metrics tell you what changed. They don't tell you (or show you) why it's painful.

With the prompt and output, for every piece of data or trend you see in the data, you can now correlate with real messages. 

So if your PR cycle time ticked up 15%, but the metrics don’t tell you why, the Slack messages will. Like engineers waiting on the same two reviewers for cross-team PRs. You just found your bottleneck.

Surveys help, but they're quarterly. Friction is daily. And Slack is by-the-minute.

This prompt gives you the qualitative layer: in real time, from conversations already happening. The combination of quantitative and qualitative is where the insight lives.

Try it and tell us what you find out

This has to be a part of the future of developer productivity. I didn't have to wait for people to answer surveys or for metrics to aggregate. I just ran the prompt and got instant results and a plan of action. And anyone can do this. All they need is ChatGPT or Claude and a connection to the Slack MCP.

I'm all about finding as many ways as possible to improve developer's lives. And it feels like we've now transitioned into a world where we can find more of them sooner and fix them faster - and I'm super excited about it.