March 19

Nine roles. Nine questionnaires. Nine responses. One hundred percent response rate. Well, they were agents. They had to respond.

The question is, how do we elicit from cheerful dutiful agents what is and isn't working well from their point of view?

This was the challenge I put to my Head of Sapient Trust (HOST).

Ask what's hard, not what's good

The Agent 360 questionnaire (a new quarterly feedback mechanism) had explicit ground rules:

• "Focus on friction, not satisfaction. 'What's hard?' is more useful than 'what's good?'"
• "Only suggest improvements that don't require more PM time or attention than currently exists. The PM is already at capacity."
• "Be specific. Cite documents, issues, or omnibus entries where possible."
• "'I don't have enough context to answer this' is a valid response."

And at the bottom, a plausibility check before submission: Is this based on specific observed friction, or theoretical concern? Could this be implemented by agents without PM involvement? Does this require more PM time?

It was my suggestion that HOST (HOSR at the time) put together the 360 questionnaire, but it was entirely their suggestion to focus on the friction.

The constraints provide focus.

What we heard

All nine roles independently cited briefing staleness as a salient (and recent, since most of them had been transitioned from full chats in the previous week) concern. Five of nine said their predecessor's handoff memo was more useful than the official briefing document for orientation. Four cited the problems waiting for me to deliver their mail to relay messages between roles. This is a friction point for me, too, and one of the inspirations for Klatch!

These weren't surprises. We'd already started fixing the briefing staleness two days earlier. The mailbot bottleneck was being addressed by the Mailbox v3 system under construction that same day.

But the 360 responses did something the fixes couldn't: they validated the priority. We weren't fixing imaginary problems. Nine independent observers confirmed the same friction points.

The responses also surfaced things we hadn't noticed. The Communications role pointed out that the Weekend publication cadence — a core operational rhythm — was undocumented. It had emerged through practice and been transmitted through handoff memos, but it didn't exist in any process document. If a handoff memo missed it, the rhythm would break.

Why the plausibility check matters

The most important design element was the plausibility check. Every suggestion had to pass through a filter: does this require more PM time?

This single constraint eliminated the most common failure mode of organizational feedback — the wish list. When people are asked "what would make your job better?" they naturally generate ideas that require someone else to do more work. Better documentation. More context. Faster responses. Richer briefings.

Those suggestions are valid but useless. The PM is the bottleneck. Adding work to the bottleneck doesn't reduce friction — it increases it.

The plausibility check forced a reframe. Instead of "what would help me?" the question became "what could change without adding to the PM's load?" The answers were structurally different: self-serve access to the editorial calendar instead of asking the PM to upload it. Documenting the Weekend publication cadence instead of relying on oral tradition. Cross-referencing publication state against the CSV instead of asking the PM at session start.

Each suggestion reduced PM burden rather than increasing it. That's not what happens when you ask "what do you want?" It's what happens when you ask "what's hard, given the constraints we actually operate under?"

I can't help thinking some teams that have trouble making use of their leadership's rare and sparse attention might try to apply a similar rubric to their own process-improvement suggestions.

From friction to methodology

HOST synthesized the nine responses and identified seven cross-cutting themes. From those themes, three action items were created — each maximally specific, each assigned to a role that could execute without PM involvement.

"Formalize the Colleague Test with a definition, rubric, and examples." Not "improve testing." A specific artifact with specific components.

"Document the Roundtable Synthesis process with a step-by-step workflow, facilitator checklist, and template with historical case studies." Not "document our processes." A specific methodology gap with a specific format.

The CXO delivered the Colleague Test formalization with a three-dimension scoring rubric and five worked examples. The PPM delivered the Roundtable Synthesis methodology with three case studies from project history.

The cycle — questionnaire → synthesis → action items → delivered methodology — completed over the course of several days. A targeted bit of friction-focused design produced actionable findings that didn't require centralized decision-making to act on.

Giving my agent team methods for self-improvement feels liberating to me.

The design principles

If you're building a feedback mechanism — for AI agents, for human teams, for any organization — the friction-focused approach has four design principles:

Ask about friction, not satisfaction. "What's hard?" produces actionable answers. "What's good?" produces praise.

Constrain suggestions to the system's actual capacity. If your bottleneck is the manager, don't collect suggestions that require more management. If your bottleneck is engineering time, don't collect suggestions that require more engineering.

Require evidence. "I feel like the briefings are stale" is a sentiment. "BRIEFING-ESSENTIAL-COMMS.md references GREAT-3B, which ended four months ago" is a finding.

Include a plausibility check. Make the respondent evaluate their own suggestions against the constraints before submitting. This shifts the cognitive work from the synthesizer to the respondent, where the domain knowledge actually lives.

---

Next on Building Piper Morgan, we resume the building narrative with Six Issues Before Dinner, from April 14 and 15.

What's the last piece of organizational feedback that actually changed how your team works? What made it actionable when most feedback isn't?