Most companies have a performance management tool. Almost nobody uses it.
Walk through the average mid-sized company's HR stack and you'll find a portal with goal-setting workflows, peer feedback forms, 1:1 templates, and a roadmap of features the HR team is excited about. Walk through the team's actual usage data and you'll find that the average employee opens the portal maybe four times a year — almost all of those visits during review season.
The portal isn't broken. The integration into how work actually happens is. This post is about why feedback fails when it lives in a destination — a separate site, a separate login, a separate ritual — and why the systems that work meet people where they already are. The argument extends our previous post on agile performance management: the cadence has to match the work, and so does the location.
Friction kills participation in performance systems
Behavioral economists have studied this dynamic under the term sludge — small barriers that quietly kill action people would otherwise take. Cass Sunstein wrote a whole book on it. The classic illustration is organ donor registration: countries where donation is opt-in have rates around 15%, while countries where it's opt-out have rates above 90%. Same underlying preferences. Different defaults. Different friction.
Performance management has the same dynamic. The question isn't whether managers and employees value feedback. They mostly do. The question is whether the system makes feedback the default action or an opt-in action against friction.
When feedback requires opening a separate tool, finding the right person's profile, navigating to a feedback form, and writing in a different interface than the one where the work happened, the friction adds up to "I'll do this later" — which becomes "I'll do this at the end of the quarter" — which becomes "I'll do this when HR sends a reminder." The portal doesn't have to be bad. It just has to be a separate destination.
Workflow-native feedback inverts the friction. The path to giving feedback is shorter than the path to ignoring the impulse. A manager noticing something in a Slack thread can capture it as a structured observation in three seconds, with zero context-switching cost. The same observation, behind a portal, would take ninety seconds and a deliberate decision to make the trip.
Three seconds versus ninety seconds is the difference between a feedback-rich team and a feedback-poor team. It compounds across hundreds of micro-decisions per quarter per manager. The aggregate is enormous.
Why standalone HR portals fail
The HR portal isn't a single product category — it's a pattern. Most fail for the same reasons, in the same order.
Wrong default destination. Nobody opens an HR portal first thing in the morning. Slack, email, the IDE, the design tool — those are the daily defaults. The HR portal is a place people go because they were told to, not a place they were already going. Every interaction starts with a deliberate trip.
Login friction. Most HR portals require a separate authentication, which means a separate password (or SSO step), a separate session, and a separate tab. Three steps before any work happens. Each one is small. The combination is enough to push "I'll do this later" to "I'll never do this."
Mismatched interface. Performance feedback is short-form text written in flow. HR portals are designed for long-form structured forms with required fields, dropdown taxonomies, and rating scales. The interface doesn't match the unit of feedback the team naturally produces. Managers have to translate their actual observations into the portal's preferred shape, which is more cognitive overhead than capturing the observation in the first place.
Batch-only access. When the portal is the destination, feedback gets batched. Nobody opens the portal to give feedback on one event; they open it to fill out a form due tomorrow, with five months of memory to scrape together. By design, the portal trains its users to batch. Batched feedback is the failure mode the previous post on delayed feedback catalogued in detail.
Asymmetric incentives. HR cares about the data the portal produces. The employee giving the feedback gets nothing back from it — no career impact, no immediate signal that the recipient saw it, no closing of the loop. The system asks for unpaid administrative work and offers nothing in return. Most people decline.
What Slack-native and Teams-native workflows look like
The opposite of an HR portal is feedback that lives where work already happens. In practice, that's Slack, Teams, email, and the IDE — the tools the team has open all day.
Workflow-native feedback works through three patterns:
In-context capture. A manager sees something worth noting in a thread. They invoke a feedback action from inside the channel — usually a slash command, a message action, or a tagged DM — and the system captures it as a structured observation about a specific person. No tab switch. The whole transaction takes seconds.
Asynchronous prompting. The system reaches the manager in the channel they already use to ask follow-up questions, surface upcoming check-ins, or prompt a coaching question before a difficult 1:1. The manager responds in the same channel they got the prompt in. The cycle never leaves the tool the manager is already inside.
On-demand synthesis. When it's time for a quarterly check-in or summary, the system pulls the captured observations together into a draft. The manager reviews and edits. The portal nobody opens isn't part of the loop — the synthesis happens in the place the work happened, or in a quick web view summoned for that one task.
The technical pattern isn't novel. Slack apps have worked this way for a decade — the best ones (Notion, Linear, Asana, GitHub) all have native integrations that turn Slack into a usable workspace for their underlying work. Performance Blocks ships its capture surface through Henry, our coaching agent, which works the same way: a manager can write a quick observation from a Slack message action, prompt a 1:1 from a DM, or invoke a coaching question from anywhere they already are. Performance management was late to adopt the pattern, but the pattern itself is well-understood.
The behavioral design principles that make it work
Why does workflow-native feedback work? The behavioral design literature has a clean answer.
Reduce activation energy. BJ Fogg's behavior model formalizes a simple idea: behavior happens when motivation, ability, and a prompt overlap. Most performance feedback fails not because motivation is missing but because ability — meaning ease of execution — is too low. Workflow-native feedback raises ability without changing motivation, which is why participation rates jump.
Match the unit to the rhythm. A unit of feedback is small (one observation, one note, one prompt). The rhythm of capture should match. Forms are designed for occasional batch entry. Slack messages are designed for high-frequency low-stakes entry. The right unit for feedback is closer to the Slack message than the form, and the surface should match.
Preserve flow state. Sophie Leroy's research on attention residue has documented the productivity cost of context-switching: the lingering cognitive load of a task you just left makes the next task harder. Asking a manager to leave Slack, log into a portal, find the right form, and write feedback breaks their flow on whatever they were doing. The flow break costs more than the feedback is worth, so the feedback doesn't happen. In-flow capture preserves the underlying work.
Close the feedback loop. Behaviorally, what makes a system sticky is that participation produces visible results. When a manager captures an observation and sees it later show up in their direct report's quarterly summary, the loop closes — the manager knows the observation mattered. Most HR portals are write-only from the manager's perspective; the data goes in and they never see what happened to it. Workflow-native systems can do better because the synthesis is visible in the same surface as the capture.
Each of these principles is well-established in behavioral design literature. The thing that's new is applying them to performance management, where the prevailing tooling has been built around the opposite assumptions for thirty years.
What changes when feedback actually gets given
The shift from portal-based to workflow-native feedback isn't just a UX win. It changes the texture of what teams know about themselves.
When a feedback system actually gets used, three things happen.
The signal density rises. Instead of one batched performance review per person per cycle, the manager has dozens of observations spread across the period. The summary at the end isn't built from memory; it's built from data. The signal-to-noise ratio of what gets captured is dramatically higher because the small things that would have been forgotten get captured in flow.
The conversation shifts from defense to development. Most performance reviews under portal-based systems become arguments about whether the manager has the right understanding. The employee feels surprised, the manager scrambles to justify, the conversation becomes about evidence rather than about growth. When the file is full of observations the employee has already seen, the conversation shifts to what to work on next, because the basic facts are already shared.
Lateral feedback emerges. When feedback lives in Slack, peers start using it. A teammate notices something worth flagging in a code review and captures it as an observation. A senior engineer writes a quick note about a junior's strong contribution. Lateral signal — feedback from peers, not just from managers — is one of the most valuable inputs to performance development, and it's almost impossible to capture through portal-based systems. Workflow-native systems get it for free.
The hard part of building this isn't the engineering; it's the assumption shift. HR teams have spent twenty years building systems that gate access to performance data. Workflow-native systems do the opposite — they put feedback in the channels the team already uses, with the data shared rather than gated. The cultural conversation that ships with the technology is harder than the technology itself.
Frequently asked questions
Why do most HR portals fail to drive participation?
HR portals fail because they require users to leave the tools they already use to provide feedback. Every additional click, login, or tab switch increases friction, and friction compounds — small barriers add up to "I'll do this later" and then "I'll do this when HR sends a reminder." Even well-designed portals struggle because the portal itself is a separate destination, not the place where work actually happens.
What is workflow-native feedback?
Workflow-native feedback is performance feedback that lives in the tools where work already happens — Slack, Microsoft Teams, email, the IDE, the design tool — rather than in a separate HR portal. It captures observations in the moment they occur, prompts coaching questions inside the manager's existing flow, and synthesizes summaries on demand without forcing anyone to visit a destination they wouldn't otherwise visit.
How does Slack-native feedback work in practice?
A manager sees something worth noting in a Slack thread, invokes a feedback action through a slash command or message action, and captures it as a structured observation about a specific person — without leaving the channel. The system handles structure (type, impact, recommended action), prompts follow-ups in the same channel, and synthesizes the captured signal into summaries when it's time. The manager never has to open a separate portal.
Why does friction matter so much in performance management?
Performance feedback is high-frequency, low-stakes work that depends on participation across hundreds of small moments per quarter. Even small amounts of friction (an extra click, a separate login, a tab switch) compound across that volume into adoption rates that drop from 80% to 15%. The same dynamic that drives organ donation rates between opt-in and opt-out countries — same preferences, different defaults — applies to feedback systems.
What are the behavioral design principles for performance management?
The four principles that matter most: reduce activation energy (lower the cost of starting an action), match the unit of capture to the rhythm of the work, preserve flow state by avoiding context switches, and close the feedback loop so participation produces visible results. Each is well-established in behavioral design literature; the application to performance management is what's new.
What we know — and what we're refining
If you're running performance feedback through an HR portal nobody opens, the move this week is small: pick the most active Slack channel on your team, install a Slack app that lets you capture an observation from a message action (any of the workflow-native performance tools will do; you don't need ours), and try capturing one observation per direct report per week from inside Slack. Notice what changes in the rate of feedback you actually deliver.
The principle isn't proprietary. Workflow-native feedback works because of behavioral design, not because of any specific vendor's implementation. We've built Performance Blocks around this premise — Henry sits inside Slack, Microsoft Teams, the web app, and email; capture happens from a message action; synthesis happens on demand; nothing requires opening an HR portal. The tools are designed to be where the work is, not to be a destination people visit. We think this is the only architecture that produces sustained adoption at scale, and the only one worth building toward.
The detail we're still refining is the right ratio between proactive prompting and pure capture. Some teams want the agent to ask questions ("did anything notable happen with Sarah this week?"); others find prompts intrusive and prefer the system to be silent until invoked. The tradeoff between participation and overhead probably depends on team culture in ways we're still mapping. If you've thought about this, we'd genuinely like to hear what you found.
The HR portal nobody opens isn't a software problem. It's a behavioral design failure that the entire category has been making for thirty years. The fix isn't to ship a better portal. It's to stop building portals and put the work where the work already is.