Mostafa Zaher | Blog

Your team isn't just carrying tech debt. It's carrying context debt, and that one is harder to pay back

2026-03-22T00:00:00.000Z

There's a conversation that happens in almost every sprint retrospective I've ever run. Someone says "we really need to address our technical debt." Everyone nods. It gets added to the backlog. Three months later, same retro, same nod, nothing changed.

I used to think that was a prioritization problem. Product keeps pushing features, leadership doesn't see the value of cleanup, the usual. But after inheriting a few systems mid-flight and watching capable engineers struggle with codebases that looked fine on the surface, I started to suspect something else was going on.

The code wasn't always the problem. The problem was that nobody could tell me why the code was the way it was.

Two kinds of debt, very different pain

Technical debt is the stuff your linter can find. Tangled dependencies. Missing tests. A function that does seven things and is named handleData. You know it's there. You know roughly where it lives. On a good team, you can schedule paying it down.

Context debt is different. It's the accumulated loss of institutional knowledge about why your system was built the way it was. Not what it does, but why it does it that way and not some other way. The architectural decision that happened after a painful incident. The edge case that's handled by what looks like arbitrary code but was actually the result of three partner integrations and a compliance audit. The service boundary that exists because of an org change eighteen months ago, not because it was the cleanest technical choice.

None of that lives in the code. Very little of it lives in documentation, because documentation is something teams aspire to write and rarely maintain. Most of it lives in the heads of the engineers who were in the room when those decisions were made.

When those engineers leave, that knowledge walks out with them. And they always eventually leave.

Here's what I've noticed managing engineering teams at a company moving fast: context debt doesn't hurt until it suddenly really hurts. Technical debt creates friction gradually. You feel it on every sprint: things take longer than they should, estimates are off, PRs need more review rounds. It's chronic. Context debt is mostly invisible until the moment someone tries to change something load-bearing and discovers they don't understand why it works the way it does. Then it's acute.

The difference matters because you manage them completely differently.

Then AI arrived and made this dramatically more complicated

I want to be careful here because I think some of the discourse around AI and code quality is overblown in one direction or underblown in another, and I'm not sure which.

Here's what I do think is real: AI tools have genuinely shifted the economics of writing code. Generating a working service that passes tests used to be expensive in engineer-hours. Now it's cheap. That's a real capability change and I'd be lying if I said it hasn't changed how my teams work.

But there's a paradox in it that took me a while to articulate clearly. Addy Osmani wrote about this recently as "comprehension debt": the growing gap between how much code exists in your system and how much of it any human actually understands. He put it well: the codebase looks clean, the tests are green, and the reckoning arrives quietly at the worst possible moment.

I've seen this happen on a smaller scale. A junior engineer uses an AI tool to implement something, the code looks clean, it passes review, it ships. Six weeks later something breaks in production in a way that surprises everyone, including the engineer who wrote the code. Not because the AI wrote bad code. Because nobody fully internalized what the code was doing or why it was doing it that way, and so nobody caught the implicit assumption it was making about a downstream system.

What Osmani is describing as comprehension debt is real. But I think it's actually a symptom of something deeper, which is context debt at the system level. And AI accelerates context debt in a way that's worth being specific about.

When rewriting is cheap, the incentive to understand before replacing drops toward zero. Your AI assistant can regenerate a service in an afternoon. What it cannot regenerate is the institutional knowledge about why that service exists, what edge cases it was patched for over eighteen months, which downstream consumers depend on its specific response shapes. You get code that compiles, passes tests, and handles the happy path. You don't get the scar tissue.

I read a framing I thought was sharp from Michael Tuszynski: "AI can regenerate the code layer fast. It cannot regenerate the institutional context that made that code correct." That's the line I keep coming back to.

What context debt actually looks like on a team

Let me be concrete, because "loss of institutional knowledge" is the kind of phrase that sounds meaningful but doesn't tell you what to do.

Here are the specific places I've seen context debt accumulate:

Architectural rationale that nobody wrote down. Why is this a separate microservice instead of a module in the monolith? Why is the database schema structured this way? If the answer is "because we decided to do it this way two years ago" and the people who made that decision are gone, you have context debt. The next engineer who touches this will either make a change that conflicts with the original rationale, or they'll leave the structure alone out of fear, and neither outcome is good.

Boundary knowledge. Which partners or internal consumers depend on specific response shapes? Which integrations are fragile in ways that aren't obvious from the code? This is the knowledge that shows up as "why did you change that field name, three other systems broke" six hours after deploy. It's invisible until it isn't.

Failure memory. The race condition that an engineer caught after an incident eighteen months ago and quietly patched. The validation logic that exists because of a security audit finding. The retry logic that's tuned the way it is because the default behavior destroyed a downstream system under load. This code looks redundant if you don't know the story. An AI tool rewriting the service will likely strip it out. And you won't know it was wrong until the same failure happens again.

The uncomfortable thing is that all of this is also exactly what AI coding tools are worst at. They operate within a context window. They see the file you're working on, the adjacent files, whatever system prompt describes your stack. They don't see the full topology of your system: every service, every contract, every shared assumption that holds your architecture together. When three engineers independently use AI to build three services that interact, each service can be internally clean and the integration between them can be quietly wrong in ways nobody catches until production.

The measurement gap that makes this a leadership problem

Here's what makes context debt particularly difficult to manage: nothing in your current measurement system captures it.

Your velocity metrics look fine. DORA metrics hold steady. PR counts are up. Code coverage is green. Performance reviews see output volume. The comprehension deficit, the accumulated context loss. None of that appears in any artifact your organization measures.

This is what makes it a leadership problem and not just a technical one. Technical debt is visible enough that engineers can advocate for paying it down. Context debt is invisible to the tools, the metrics, and often to the engineers themselves. They'll approve a PR that looks right, because it does look right. The problem is invisible until it compounds into something that isn't.

I've thought about this a lot in the context of AI adoption. There's genuine pressure right now to show velocity improvements from AI tooling. That pressure is real and not unreasonable. But if your measurement system only captures what moves fast, you'll optimize for speed and discover the context you've shed when something breaks at scale.

What you can actually do about it

I want to be direct here: I don't think this is primarily a culture problem. "Slow down and review more carefully" is advice that sounds reasonable in a blog post and falls apart in a sprint with a deadline. The teams that will manage context debt well are the ones that treat it as an infrastructure problem, not a discipline problem.

Architectural decision records, maintained as living documents. ADRs have been around for years. The format is basically Title, Status, Context, Decision, Consequences. What's changed is the urgency. Before AI-assisted development, context accumulated naturally as engineers wrote code slowly enough to internalize it. Now it dissipates faster than it accumulates unless you deliberately counteract that. An ADR written when a decision is made and living alongside the code is worth ten retrospective explanations after the fact.

The key word is "living." A dusty Confluence page nobody updates is not an ADR. It's archaeology. If your ADRs aren't being referenced and updated as part of the development workflow, they're decoration.

Structured project memory as a first-class artifact. Context documents (system descriptions, constraint inventories, edge case catalogs, partner dependency maps) should be versioned and reviewed with the same rigor as code. Not because engineers will read them compulsively (they won't), but because when an engineer or an AI tool is about to make a change, the context needs to be accessible right there. Embedded in the workflow, not sitting in a separate system someone has to remember to consult.

Explicit integration contracts. If your services are generated independently by AI tools without awareness of each other, you will accumulate integration debt. The data formats, error handling conventions, retry semantics, authentication flows: these will diverge. The fix is defining and maintaining explicit contracts that both engineers and AI tools can reference during generation. The contract becomes the source of truth, not the individual engineer's mental model of how everything connects.

Offboarding as a context transfer ritual. When a senior engineer leaves (and eventually everyone leaves), their departure is the most expensive context loss event your team will experience. I've seen teams do thorough technical offboarding (here's how the systems work) and nothing about contextual offboarding (here's why these systems work this way, here are the decisions I'd revisit, here's the undocumented partner integration that will break if you do X). The latter is what you actually need.

One thing I've started doing: before an engineer leaves, I ask them to record a "walk through the weird parts" session. Not a systems overview. Specifically the things that look wrong but aren't, the things that need to stay exactly the way they are and why, the decisions they made that they'd make differently now. That's the institutional knowledge you can't recover after someone's gone.

Context-aware generation as a deliberate workflow. If your engineers are using AI tools to generate code, the tools should be ingesting project context before they generate. This means investing in the scaffolding (the context files, system prompts, reference documents, constraint catalogs) that gives the AI a real understanding of the system it's working within. The alternative is an amnesiac collaborator that produces clean code in a vacuum. That's fine for a proof of concept. It's not fine for production.

What I'm still figuring out

I'll be honest about where I don't have clean answers.

Measuring context debt is genuinely hard. I can measure test coverage, PR cycle times, defect rates. I cannot tell you with a number how much institutional context my team has lost in the last six months of AI-assisted development. I can observe signals: engineers expressing uncertainty about why something works the way it does, changes that break things in surprising ways, architectural discussions that require me to explain history that should be documented. But I don't have a dashboard for this.

I'm also not sure yet how much of this is fundamentally new and how much is the same old context-loss problem that's always existed, just accelerating. My guess is it's both, and the acceleration is the part worth treating seriously right now, before the debt compounds further.

What I'm reasonably confident about: the teams that will do well in the AI era aren't necessarily the ones that generate code fastest. They're the ones that maintain the richest context while moving fast. That combination compounds. A year from now, the team that invested in context architecture will be moving quickly and safely. The team that optimized only for velocity will be drowning in debt they can't see and can't name.

The old tech debt conversation was mostly about code quality. This one is about knowledge architecture. And most teams haven't started having it yet.

If you're thinking about this differently on your team, or you've found approaches that actually work for maintaining context at pace, I want to hear about it. Reach out on Twitter or LinkedIn.

Measuring eNPS on your engineering team (and using AI to actually make sense of it)

2026-03-20T00:00:00.000Z

By the time someone hands in their resignation, you already missed the moment. The frustration was there three sprints ago. Maybe six. You could feel something was off but you couldn't name it, couldn't quantify it, and without numbers you couldn't justify doing anything about it. That's the trap most engineering managers fall into: waiting for a signal clear enough to act on, and by then it's too late.

eNPS (Employee Net Promoter Score) doesn't solve this problem completely, but it does give you a repeatable, low-overhead signal that keeps you honest. And when you pair it with an LLM doing qualitative analysis on the open-ended responses, it goes from "we have a vague sense of morale" to "here's exactly what's bothering the team and here's how it compared to last quarter."

I've run this across a few team configurations now. Here's what I actually learned, not just what the framework says.

What eNPS is (and isn't)

The concept borrows from customer NPS. One core question:

"On a scale of 0–10, how likely are you to recommend this team as a great place to work?"

Responses fall into three groups: Promoters (9–10), Passives (7–8), and Detractors (0–6). The score is:

eNPS = % Promoters − % Detractors

It ranges from −100 to +100. Above 0 is acceptable. Above +20 is genuinely healthy. Above +50 is rare in engineering.

Here's the part most guides skip: the number itself is almost meaningless in isolation. I've seen teams with a +35 that were quietly miserable in ways the score didn't capture, and teams with a +10 that were actually in a good place given the chaos they were navigating. What matters is the trajectory across quarters, and what the open-ended responses say about why.

eNPS is not a diagnostic tool. It's an early warning system. It tells you something shifted. The actual diagnosis comes from everything else.

Why it works for engineering specifically

Generic engagement surveys miss what engineers actually care about. A 60-question annual survey asking about cafeteria quality and office amenities tells you nothing about whether your team trusts the technical direction, whether they have enough uninterrupted time to think, or whether the deployment process is so painful that shipping feels like punishment.

Engineers are also unusually resistant to performative feedback tools. If they don't trust that responses are truly anonymous, they'll all score 7 and write nothing in the open-ended fields. Your data becomes noise. The survey design has to earn that trust before it can generate any useful signal.

The other thing eNPS has going for it: it takes two minutes. High response rates from engineers are not a given. Short surveys get answered; long ones get abandoned or half-heartedly completed.

How to run it

Cadence: quarterly. Monthly creates fatigue and the scores become too noisy to trend. Annually is too slow to catch anything while you can still act on it.

Questions: three, maximum.

"On a scale of 0–10, how likely are you to recommend this team as a great place to work?"
"What's the primary reason for your score?"
"What's one thing we could change that would make the biggest difference for you?"

Anonymity: non-negotiable, and engineers will know if you're not serious about it. Use Google Forms with no email collection enabled. Don't restrict responses by Google account unless you have a strong reason to. Don't use a tool that ties response timestamps to Slack activity or calendar data. Engineers will notice and they will talk.

Send the survey at the start of a sprint, keep it open for five days, send one reminder on day three with the current response count (not individual results), then close it. Calculate the score. Export the open-ended responses. That's your raw material.

Interpreting the score

A rough guide:

Score range	What it probably means
+50 to +100	Something is working well. Figure out what and protect it.
+20 to +49	Healthy baseline. Keep iterating.
0 to +19	Worth digging into. Not a crisis but not comfortable either.
Below 0	Structural problems. Act fast.

A 10-point drop after a reorg or a brutal quarter is normal. I've lived through that. A sustained decline over two or three consecutive quarters is the signal you can't ignore.

When the score drops, the instinct is to figure out what you did wrong. That's sometimes the right question. But sometimes the team is going through something difficult and the score reflects reality accurately: a painful migration, a product direction that isn't landing, organizational uncertainty above your level. Understanding the context matters as much as the number itself.

Where AI actually earns its place here

The quantitative score is table stakes. The real value is in the open-ended responses, and that's also where most managers quietly give up. Reading 40 free-text responses and trying to synthesize them into something coherent, while keeping your own biases out of the interpretation, is harder than it sounds.

This is the problem LLMs are genuinely good at.

Theme clustering

Paste your open-ended responses into an LLM with this prompt:

"Below are anonymous survey responses from an engineering team. Group them into 3–5 themes. For each theme, provide a label, the number of responses related to it, and one representative quote that captures the theme. Do not identify or speculate about individual people."

The output is faster and more consistent than manual synthesis, and it surfaces themes you might unconsciously deprioritize because they're uncomfortable. I've had the model surface a career growth concern that I had mentally filed under "individual ambition". When I looked at how many responses touched on it, it was clearly a team-wide pattern, not a personal thing.

Sentiment tracking over time

Run the same prompt every quarter and log the results in a simple table:

Quarter	Theme	Sentiment	Mentions
Q1	Technical debt	Negative	14
Q2	Technical debt	Mixed	9
Q3	Technical debt	Mostly positive	4

If you committed sprint capacity to reducing technical debt in Q2, and by Q3 the mention count dropped and the sentiment shifted, that's real feedback that the change landed. Teams rarely tell you directly that something you did worked. This is one way to see it.

Early warning detection

This one is the most sensitive to get right. The prompt is:

"From the following survey responses, identify any that suggest the respondent may be considering leaving or is highly disengaged. Do not identify individuals. Summarize the systemic concerns that appear across multiple responses."

The important framing there is systemic. You're not trying to identify who wrote what. You're trying to spot whether five different people independently described the same structural problem. That's a different thing from surveillance, and how you talk about this internally matters. If your team thinks you're using eNPS to identify the disgruntled people, you've already lost.

Quarter-over-quarter comparison

Once you have data from two quarters, run this:

"Compare the themes from Q1 and Q2 survey responses below. What got better? What got worse? What's new this quarter that wasn't there before?"

This gives you a narrative. "Last quarter, meeting load was the loudest concern. We cut three recurring syncs. This quarter it's not in the top themes." That's a story you can tell the team, and closing that loop is the part that actually makes people keep participating.

A workflow that doesn't take over your life

Here's the full sequence, realistically:

Quarter starts. Send the survey on Monday of sprint one. Keep it open until Friday. Send a reminder Wednesday. Close it, calculate the score, export the responses as a text file. Run the AI analysis (ten minutes, maybe fifteen if you want to iterate on the prompts). Log the score, themes, sentiment, and three to five action items. Share the results with the team that week: score, what you heard, and one concrete thing you're committing to. Do the thing before the next survey goes out.

The last step is the one that determines whether this works. If the team sees feedback going into a void, participation drops. Not dramatically at first (people give it one more cycle), but it hollows out. The survey becomes a ritual without a point.

The AI agent skill: what it actually does and how to use it

I built a reusable skill file for MCP-compatible AI agents that automates this entire workflow. If you've used Claude or any agent that supports the Model Context Protocol, you can drop these files in and run the full eNPS cycle from a single prompt.

The skill is two files: SKILL.md (the main workflow) and reference/prompts.md (the AI analysis prompt templates with worked examples). Here's what's in each.

SKILL.md: the full workflow

The skill file opens with a metadata block that tells the agent when and how to activate:

---
name: team-health
description: Run quarterly eNPS surveys to measure engineering team health.
  Creates anonymous surveys via Google Forms, distributes via Slack, collects
  responses, and uses AI to analyze themes and track sentiment over time.
triggers:
  - "run eNPS survey"
  - "team health check"
  - "quarterly survey"
  - "measure team morale"
integrations:
  - slack-mcp
  - google-workspace-mcp
---

The trigger phrases matter. A well-defined skill file tells the agent not just what to do, but when to activate without you having to explain the context every time.

The workflow then breaks into seven steps, each with explicit success criteria so the agent knows when a step is genuinely complete before moving on:

Step 1: configuration check

Before creating anything, the agent asks for four variables:

Variable	Purpose	Default
`slack_channel`	Where to post announcements	`#engineering`
`survey_title`	Name for this cycle (e.g., "Q1 2026 Team Health")	Derived from current quarter
`engineer_emails`	Optional list to restrict form access	Empty (open access)
`collection_window_days`	How long the survey stays open	5

The agent won't proceed without slack_channel and survey_title. The others have sensible defaults. This matters because a poorly configured survey (wrong channel, wrong anonymity settings) produces bad data that takes a quarter to detect and correct.

Step 2: create the Google Form

The skill specifies exact form configuration, not just "create a form":

Form title: {survey_title}
Collect email addresses: OFF
Limit to 1 response: ON (if engineer_emails is set, else OFF)
Require sign-in: OFF

Question 1:
  Type: Linear scale
  Label: "On a scale of 0–10, how likely are you to recommend this team as a great place to work?"
  Scale: 0 to 10
  Low label: "Not at all likely"
  High label: "Extremely likely"

Question 2:
  Type: Paragraph text
  Label: "What's the main reason for your score?"
  Required: false

Question 3:
  Type: Paragraph text
  Label: "What's one thing that would make the biggest difference for you right now?"
  Required: false

The "Required: false" on the open-ended questions is intentional. Forcing text input when someone doesn't have anything to say produces garbage. Better to get a clean 0–10 score with no commentary than a score plus a placeholder response.

Step 3: launch announcement to Slack

The skill includes the exact Slack message template, not a generic "post to Slack" instruction:

:bar_chart: *Q1 2026 Team Health Check*

Quick survey, takes about 2 minutes.

This is fully anonymous. I don't see individual responses, only aggregated themes. No email collection.

Link: {form_url}

Open until {close_date}. I'll share results and what I'm doing about them the week after.

The transparency line ("I don't see individual responses") is not optional. It directly affects response quality and honesty.

Step 4: three-day reminder

The reminder includes the current response count, which creates low-key social proof without pressure:

:reminder_ribbon: Reminder: Team Health Survey is still open ({response_count} responses so far)

Closes {close_date}. Two minutes: {form_url}

Don't send a second reminder after this. Two Slack messages is the limit before it starts feeling like pressure.

Step 5: close and collect

The agent closes the form at end of business on day five, exports responses in two formats: a CSV with the raw 0–10 scores for eNPS calculation, and a plain text file with the open-ended responses formatted for LLM input.

The text file format matters for prompt reliability:

=== Q2: Primary reason for score ===
[Response 1] I feel like we ship fast but never slow down to fix things properly.
[Response 2] My manager actually listens. That's rarer than it should be.
[Response 3] No clear path to senior. I've been here 18 months and don't know what I'm being evaluated on.
...

=== Q3: One thing that would make the biggest difference ===
[Response 1] 20% time that's actually protected, not just promised.
...

The [Response N] prefix keeps responses visually separated without leaking any identifying metadata.

Step 6: calculate eNPS

The agent runs this calculation and logs the components, not just the final score:

Total responses: N
Promoters (9–10): P  →  P/N × 100 = P%
Passives (7–8):   A  →  A/N × 100 = A%
Detractors (0–6): D  →  D/N × 100 = D%

eNPS = P% − D% = {score}

Logging the breakdown matters. A +20 from 60% Promoters / 40% Passives / 0% Detractors is a very different situation from a +20 from 40% Promoters / 40% Passives / 20% Detractors. The score is the same. The underlying health is not.

Step 7: AI analysis

The agent runs all four prompt templates sequentially against the exported responses and assembles the output into a structured report (see the prompt details in the next section).

Step 8: results post to Slack

The results message template is designed to close the loop, not just report numbers:

:bar_chart: *Q1 2026 Team Health Results*

*eNPS: {score}* ({interpretation})
{total_responses} responses · {response_rate}% of the team

*What I heard most:*
• {theme_1}: {theme_1_summary}
• {theme_2}: {theme_2_summary}
• {theme_3}: {theme_3_summary}

*What I'm doing about it:*
{action_item_1}
{action_item_2}

Full analysis posted to {confluence_link or notion_link}.

Next survey: {next_quarter_date}

The "What I'm doing about it" section is the point. It's the reason people respond next time.

reference/prompts.md: the four AI templates

This file is the most portable part of the skill. Even if you never use an AI agent, these prompts work standalone in any LLM.

Prompt 1: theme clustering

You will receive anonymous survey responses from an engineering team.
Your task is to group them into 3–5 themes.

For each theme:
- Give it a short, specific label (not "Communication", but something like "Unclear priorities at the team level")
- Count how many responses relate to it
- Select one representative quote that captures the theme without identifying anyone
- Note whether the theme is about something structural (process, tooling, org design) or interpersonal (manager relationship, team dynamics)

Do not speculate about individuals. Do not infer who wrote what based on writing style or context.

Responses:
{paste responses here}

The instruction to distinguish structural from interpersonal is something I added after a few cycles. It changes how you prioritize the actions. Structural problems need system changes. Interpersonal ones often need different conversations.

Prompt 2: sentiment scoring

For each of the following themes identified in the survey analysis, rate the overall sentiment expressed across the related responses.

Use one of four ratings:
- Positive: team members feel good about this area
- Mixed: roughly split between positive and negative
- Negative: team members are frustrated or disengaged here
- Neutral: factual observations without strong emotional signal

Also provide a one-sentence characterization of the specific flavor of the sentiment (e.g., not just "Negative" but "Frustrated with slow progress rather than opposed to the goal itself").

Themes: {paste themes here}
Responses: {paste responses here}

The one-sentence flavor note is the useful part. "Negative" tells you something is wrong. "The team is frustrated that the reorg happened, not that the new structure is bad" tells you whether to address the change or the change management.

Prompt 3: early warning detection

Review the following survey responses for signals of attrition risk or significant disengagement.

Categorize signals as:
- High risk: language suggesting the person is actively considering leaving or has mentally checked out
- Medium risk: language suggesting disengagement, unfulfilled expectations, or feeling stuck
- Systemic: patterns appearing across multiple responses that suggest a team-wide issue rather than individual circumstances

For each category, summarize the concern in general terms. Do not quote directly in ways that could identify individuals. Do not attempt to guess who wrote what.

If no clear signals are present, say so plainly. Do not manufacture risk signals that aren't in the data.

Responses:
{paste responses here}

The last instruction ("do not manufacture risk signals") matters. LLMs have a tendency to find patterns when prompted to look for them, even in clean data. Explicitly telling it to say "nothing significant here" when that's true reduces false positives.

Prompt 4: quarter-over-quarter comparison

Below are theme summaries from two consecutive quarterly eNPS surveys for the same engineering team.

Compare them:
1. What improved between Q{N-1} and Q{N}? Be specific about what changed.
2. What got worse or didn't improve despite being flagged last quarter?
3. What is new this quarter that wasn't present before?
4. Is there anything in Q{N} that contradicts what Q{N-1} suggested?

Be direct. If something got worse, say it got worse. If an action the manager took seems to have had no effect, note that.

Q{N-1} themes:
{paste previous quarter themes}

Q{N} themes:
{paste current quarter themes}

The instruction to note when an action had no apparent effect is important and uncomfortable. It's also the most useful feedback a manager can get. If you dedicated sprint capacity to tech debt last quarter and this quarter's responses still mention it as the top frustration, something is off. Either the effort wasn't visible, wasn't enough, or wasn't addressing the actual problem.

how to install it

For Claude or any MCP-compatible agent, place the files at:

.agents/skills/team-health/SKILL.md
.agents/skills/team-health/reference/prompts.md

The Slack MCP and Google Workspace MCP need to be connected for the automated steps to work. If they're not available, the skill degrades gracefully: the agent walks you through each step manually with the exact configuration to use.

The prompts in reference/prompts.md work standalone regardless. Copy them, paste your responses, run them in whatever LLM you use. That's the minimum viable version and it's where I'd start before connecting any integrations.

The thing that actually determines whether this works

I've seen eNPS programs that ran for a year and produced nothing. Not because the questions were wrong or the cadence was off, but because the results went into a document that nobody referenced until the next survey went out.

The feedback loop only works if people believe it works. That means two things: the survey has to be genuinely anonymous (not just said to be), and the actions have to be visible before the next survey lands. One concrete change, clearly connected to what the team said, is worth more than five action items that quietly drop.

If you've run eNPS on your team, or you've tried a different approach to measuring morale, I'd actually like to hear what you found. What signals were you watching that the survey missed? Reach out on LinkedIn.