Action Planning Across Multi-Domain People Platforms

Action Planning Across Multi-Domain People Platforms

An Evidence Synthesis and Architecture for the peoplework Stack

Whitepaper — 3 May 2026

Synthesis note. This document combines two parallel research streams: an external scan compiled by Rob Browton using Grok ¹ and an internal review focused on identifying missing modules in the @consulting/action-planning shared package. Where the two streams diverge in scope, this whitepaper takes the narrower position appropriate to a shared technical package consumed by four product apps (employeeexperience, portraits, coaching, maturitymap) rather than a single flagship product. References use numbered footnotes and are listed in full at the end.

---

Executive summary

Action planning is the bridge between any diagnostic instrument — an engagement survey, a 360 feedback cycle, a coaching conversation, a maturity assessment — and a measurable change in the underlying condition. The peer-reviewed evidence is unambiguous: well-executed action planning produces small but compounding gains in work attitudes, engagement, retention, and business outcomes; absent or performative action planning erodes trust and reduces participation in the next cycle. The most rigorous longitudinal study to date (Huebner & Zacher 2022) ² tracked 3,091 organisational units over three annual cycles and found that units with formal action plans showed statistically significant gains in a 22-item work attitude index, with continuous planners accumulating the largest effect.

For peoplework, the implication is that the four apps in our consulting stack each face the same underlying problem in different costumes: the EX app needs to convert survey results into team-level commitments; the 360 app (portraits) needs to convert feedback profiles into development plans; the coaching app needs to convert session insights into commitments tracked between sessions; the maturity app needs to convert assessment scores into transformation roadmaps. Building a separate action-planning system in each app is wasteful and produces inconsistent quality. The shared @consulting/action-planning package, scaffolded over the past 48 hours and now active in three of the four apps, is the foundation we need.

This paper does three things. First, it synthesises the evidence base — what we know works, what we know doesn't, and what we know moderates outcomes. Second, it lays out a recommended module backlog for the shared package, drawing the line clearly between package responsibilities (types, validation, UI components, orchestration primitives) and app responsibilities (DB schema, prompts, branded artefacts, vertical-specific workflows). Third, it proposes a phased delivery roadmap that stays honest about scope: a single shared package consumed by four apps, not a flagship platform product.

The headline recommendations are seven prioritised modules to add to the package over v0.3 and v0.4, the most consequential of which are a workshop module for collaborative facilitated planning (the strongest single intervention in the literature) and a quartet of behavioural-science modules (implementation intentions, mental contrasting, confidence and commitment, templates and playbooks) that meaningfully shift completion rates with modest build cost. We recommend explicitly not building, in the package, the things that belong in apps: AI-driven recommendation engines, branded PowerPoint generators, A/B testing infrastructure, or an external-tools sync layer.

---

1. The evidence base

1.1 Action planning works, modestly and cumulatively

Huebner and Zacher's (2022) ² three-year study of one large German company is the strongest causal-adjacent evidence available. Across 3,091 organisational units running anonymous annual surveys, units that produced formal action plans showed a small but significant improvement in a composite work-attitude index. Units that planned every year accumulated the largest gains (a raw mean shift of approximately 0.08 on a 5-point scale per cycle); single-year planners showed partial gains; non-planners often regressed. Managers who had planned in one cycle were 3.74 times more likely to plan in the next, suggesting the practice is self-reinforcing once started.

The effect size matters less than the shape: action planning produces compounding improvement, not a one-off lift. This implies that the most important thing a tool can do is reduce the effort of re-planning in successive cycles, not maximise the value of any single cycle's plan.

The same authors' systematic review (Huebner & Zacher 2021) ³ across 53 studies spanning seven decades concluded that participatory and collaborative approaches consistently outperform solo or top-down ones. Industry data corroborates: Gallup's meta-analysis of more than 183,000 business units links top-quartile collaborative action planning to roughly 10 percent higher engagement ⁴; Perceptyx reports that organisations using their structured 1-2-3 framework are six times more likely to exceed financial targets ⁵; Culture Amp's playbook documents engagement lifts in the 7–12 percentage-point range from facilitated team workshops ⁶.

1.2 Four moderators predict who benefits

Huebner and Zacher's 2023 follow-up ⁷ (5,875+ units) identifies four moderators that significantly predict whether action planning produces a downstream score lift:

1. Mean item ratings. Plans that target the lowest-scoring items produce the largest lifts. Plans that scatter across already-high scores produce little.
2. Topic distance. Local, team-level issues are more actionable than enterprise-wide ones. The same plan is more likely to succeed at the team level than at the org level.
3. Direct leadership quality. Plans go nowhere when the team's immediate manager doesn't support them.
4. Voice climate. Plans go nowhere in low-psychological-safety environments because the input that shapes them is filtered or false.

These four findings have direct implications for the package: the UI should make it easy to target low-scoring items, easy to scope at team level rather than organisational level, and easy to surface (or at least flag) the voice-climate context. They are hints, not gates — the package's job is to make the right path the easy path, not to refuse the wrong path.

1.3 Behavioural science: why some commitments turn into action

The general action-planning literature explains whether action planning works. The behavioural-science literature explains why particular plans succeed or fail. Three findings are especially load-bearing.

Implementation intentions — Gollwitzer and Sheeran's (2006) ⁸ meta-analysis of 94 studies found a medium-to-large effect (d ≈ 0.65) on goal attainment when goal intentions ("I want to do X") are converted into implementation intentions ("When situation Y occurs, I will perform behaviour Z"). The mechanism is the pre-commitment of attention: the if-then format binds future behaviour to a contextual cue, so when the cue arrives the behaviour fires automatically rather than requiring fresh deliberation.

Mental contrasting (WOOP) — Oettingen's ⁹ research on mental contrasting shows that positive fantasising about a desired outcome, on its own, reduces follow-through; pairing the desired outcome with explicit identification of the obstacles in the way roughly doubles goal-pursuit energy. The WOOP protocol — Wish, Outcome, Obstacle, Plan — is the operationalisation. This is particularly relevant to EX action plans, where managers tend to write aspirational platitudes ("we will improve communication") without naming the obstacle that has prevented improvement to date.

Confidence and commitment as predictors — In motivational interviewing practice (Miller & Rollnick) ¹⁰, explicit confidence and commitment ratings on a 0-10 scale are used as leading indicators: clients who rate their confidence in following through below 7 are unlikely to follow through, and the gap is itself a useful conversation. The ICF coaching framework ¹¹ embeds the same idea in Core Competency 8.

1.4 Self-Determination Theory underpins the social finding

The repeated finding that collaborative planning beats solo planning is explained by Self-Determination Theory (Deci and Ryan) ¹²: collaborative planning satisfies all three psychological needs the theory identifies — autonomy (participants co-create rather than receive), competence (focused, achievable actions build mastery), and relatedness (the dialogue itself reinforces connection). Solo manager-driven planning satisfies none of these and predictably underperforms.

The mechanism is the same in coaching, where ICF ethics treat the client's ownership of the action as constitutive of the engagement, and in maturity transformation, where capability-building research at McKinsey ¹³ consistently finds that imposed capability programs underperform participatory ones at scale.

1.5 Where the evidence is thinner

Two areas frequently treated as evidence-based actually rest on weaker ground.

Vendor case studies. Industry reports from EX vendors (Culture Amp, Worktango, Perceptyx, Quantum Workplace) carry self-selection and reporting bias. Their effect estimates should be treated as plausible directional indicators rather than reliable point estimates. The ten-percent-engagement-lift figure from top-quartile organisations conflates the effect of the action planning with the effect of being in an organisation likely to be in the top quartile in the first place.

Predictive impact scoring. The notion that a tool can show "similar organisations saw +8% lift with this combination" requires a calibrated, well-populated historical dataset. None of the major EX tools currently publish their calibration. This is reasonable as a marketing claim and unreasonable as a load-bearing product feature without serious data infrastructure behind it.

---

2. Package versus app: drawing the line

A central confusion in much of the available material on EX action planning is the conflation of platform features (something a flagship product does) with package primitives (something a shared library exposes). For peoplework, this distinction is doctrinally important: the package serves four apps with different domains and different pricing models, and its job is to provide reliable primitives, not to embed any single domain's product strategy.

The line we draw is:

Package responsibilities:

• Canonical types for actions, plans, parent links, people, events
• Validation (Zod schemas) at the boundary
• React UI components that are theme-able and label-overridable per app
• Orchestration primitives — providers, callbacks, event emission for audit
• Schema templates for both Prisma and Drizzle that apps copy and adapt
• AI-handoff contract (ActionDraft + ingestDrafts) that any generator can target
• Behavioural-science wrappers (implementation intentions, WOOP, confidence and commitment ratings, GAS scales) as opt-in modules

App responsibilities:

• Database schema and migrations
• Authorisation and tenancy
• AI prompts and generation logic (using @rbrowton/ai-client plus the package's ingestDrafts)
• Branded artefact generation (PowerPoint decks, PDFs, Miro boards) — uses @consulting/presentations if needed
• Recommendation engines that pick the right approach for the right context
• A/B testing across clients
• External-system integrations (Slack, Teams, Jira, Asana)
• Compliance workflows (GDPR consent capture, audit log surfacing)
• Vertical-specific frameworks (Gallup Q12 in EX, GROW in coaching, CMMI in maturity)

The dividing rule of thumb: if a feature is naturally domain-specific or requires a calibrated dataset, it belongs in the consuming app. If it is structural and would benefit at least two apps if it lived once, it belongs in the package.

This positioning is more conservative than Grok's whitepaper ¹ suggests. Grok's vision treats the package, the recommendation engine, the kit generator, and the predictive scoring as one integrated platform. That is a coherent product strategy if you are building one EX product. It is the wrong shape for a package that has to serve four apps and not become an EX-shaped fork in disguise.

---

3. Recommended module backlog

The table below merges the modules already planned in the original proposal ¹⁴, the modules surfaced in the internal research scan ¹⁵, and the genuinely novel additions from the Grok synthesis ¹. Status reflects what ships in the current package versus what is yet to land.

3.1 Already shipping (v0.1 / v0.2)

3.2 v0.3 — high priority

The five modules below comprise the recommended next iteration. The first four are tightly coupled behavioural-science primitives that reinforce each other; the fifth is a structural module that meaningfully widens what the package can model.

The four behavioural modules deliberately compose: a template can pre-populate WOOP fields, which include implementation intentions in the Plan step, which trigger confidence-and-commitment ratings on save. This is why we recommend shipping them as a quartet rather than serially.

The workshop module is the largest single capability gap in the package today and the one most directly traceable to the strongest evidence in the literature. It is described in detail in section 4.5.

3.3 v0.4+ — medium priority

3.4 v0.5+ — low priority but worth tracking

3.5 What we are deliberately not building

---

4. Architectural principles

4.1 Storage-agnostic

The package owns no database. Each app keeps its own tables and supplies adapters at the boundary. This is non-negotiable: the four consuming apps already use two different ORMs (Prisma in EE and Portraits, Drizzle in Coaching and MaturityMap) on three different database technologies. The package ships schema templates as reference, not enforcement.

4.2 Prompt-free

The package owns no prompts. Each app keeps its own AI generators (using @rbrowton/ai-client) and hands the package a clean batch of ActionDraft objects via ingestDrafts. The package never sees a model name, an API key, or a prompt string.

4.3 Theme + labels for re-skinning

Every component reads its labels from ActionPlanProvider. The same <ActionList> renders as "Action Items" in EE, "Commitments" in Coaching, "Roadmap Actions" in MaturityMap, and "Development Actions" in Portraits. CSS variables for theme tokens follow the same pattern bookshelf established.

4.4 Opt-in modules

The slim core ships first; modules are opt-in via subpath imports (@consulting/action-planning/check-ins, @consulting/action-planning/workshop, etc.). Apps consume only what they need; the package stays small for apps that don't need everything.

4.5 Workshop as the central new abstraction in v0.3

The workshop module is structurally different from existing modules and worth describing in some detail.

A workshop in the package's sense is a planning event attached to a plan. It has an agenda (a sequence of activities, each with a duration and a prompt), a list of attendees (resolved from the apps' Person source), a set of prompts (questions to ask during specific activities), and a harvest — the structured output of the workshop, typically a list of candidate actions that get ingested into the plan via ingestDrafts.

The shape:

Workshop
  id
  planId        — the plan this workshop produces actions for
  title
  scheduledAt
  durationMinutes
  facilitatorId
  attendees     — Person[]
  agenda        — { activity, duration, prompt }[]
  status        — scheduled | in_progress | completed | cancelled
  harvest       — { source, candidateActions: ActionDraft[] }
  notes

The package ships a <WorkshopRunner> UI component that walks the facilitator through the agenda step by step, captures responses against each prompt, and ends with a harvest view where candidate actions are selected, edited, and committed to the plan. The component is mode-aware: facilitator-mode for the person running the workshop, attendee-mode for everyone else (read-only or limited input depending on activity).

This is the shape that lets EX support facilitated team workshops, coaching support session-end commitment captures, and maturity support transformation kickoff sessions — all from the same primitive.

What the package does not do: ship facilitator scripts, generate branded PowerPoint decks, or send calendar invites. Those are app concerns or separate-package concerns (@consulting/presentations).

---

5. Phased delivery plan

The sequencing below was revised after a first-principles review on 3 May 2026. The original plan bundled five modules into a single v0.3 (workshop plus the behavioural quartet); the revision unbundles workshop because it carries the package's biggest structural change and deserves its own merge cadence. Each phase is one focused session unless noted; each treats the four shipping apps as validation gates rather than parallel rollout targets.

Two cross-cutting items run in parallel with these phases:

Telemetry and analytics, owned by the consuming apps but informed by the package's event stream. The package emits action.created, action.completed, etc.; apps decide which events feed which analytics. This is what eventually makes a credible recommendation engine or predictive scoring possible — but it is a downstream consequence of the events stream, not a feature the package ships.

MaturityMap migration, the largest remaining piece of the original proposal. MaturityMap is more complex than the other three apps because it carries the richest existing data shape (effort, impact, dependencies, RACI, measures, themes, attachments, horizons). The migration gate is alignment-tree, since MaturityMap's roadmap actions inherently roll up to capability levels.

---

6. Risks and open questions

Risk 1: scope creep from the EX product roadmap. The Grok synthesis ¹ is, in places, an EX product roadmap dressed as research. There will be pressure to pull EX-specific features into the shared package because they look like primitives from inside the EX app. The discipline is to ask "would three of the four apps actually use this?" — if not, the feature lives in EE.

Risk 2: workshop as a Trojan horse. The workshop module is deliberately ambitious. If the v0.3 implementation grows beyond the slim shape described in section 4.5 — particularly if it starts trying to generate branded artefacts or send calendar invites — it will block the rest of v0.3 and create EE-shaped scope. Hold the line on the slim shape; punt artefact generation to a separate concern.

Risk 3: behavioural-science fields without behavioural-science training. Implementation intentions and WOOP only work if users actually use them as designed. Shipping the fields without the prompting and tooltips that explain what they're for and why will produce empty rows and survey-style frustration. The v0.3 spec must include the help text and first-use prompts as a non-negotiable part of the fields, not a follow-up.

Open question 1: when do we revisit the recommendation engine? A package-internal recommendation engine that takes Huebner moderators, voice climate, and survey type and suggests an approach is appealing. We have deliberately deferred it. The trigger to revisit is when at least three of the four apps have populated survey-loop data for two cycles — which gives us a real (if small) calibrated dataset for the first time.

Open question 2: how do we represent OKR-style outcomes vs. actions? The literature is split on whether key results are "actions" or a parent type. We have provisionally treated key results as a separate type to be added under alignment-tree, but this is a v0.4 design decision worth re-litigating when we get there.

Open question 3: where do we capture the "why" of an action? Implementation intentions partially answer this (the cue and response carry context). WOOP partially answers it (the obstacle is the why-not). But neither captures the strategic rationale: "we are doing this because the engagement driver scored X". Adding a rationale field to the core is small and probably worth it; or we leave it as a tag in the existing tags bag. To decide.

---

7. Success criteria

The package is successful, in our terms, when:

• All four consulting apps render their action-planning UI from the package, with theme + labels overrides.
• Adding a new app with action-planning capability takes a day, not a sprint.
• Changing a behaviour (e.g., adding a new status, fixing a bug in the edit form) changes it everywhere.
• The package ships modules opt-in, and apps adopt only the modules they need.
• The behavioural modules are demonstrably used (i.e., not empty fields on most actions) — measured by app analytics.
• The workshop module supports at least one facilitated workshop per app (EE: campaign-improve workshop, Coaching: session-end commitment capture, MaturityMap: transformation kickoff, Portraits: dev-plan workshop).
• The package's typecheck stays green and its API surface stays small enough to fit in one architectural diagram.

The package is unsuccessful if it grows into an EX-shaped fork in disguise; if it accumulates app-specific features behind feature flags; if its API surface becomes too large to hold in one head; or if more than half of its components require non-trivial wrapping in each app to be usable.

---

References

Footnotes

1. Browton, R. (2026, May 3). Action planning in organizational surveys: A comprehensive evidence-based review of methods, techniques, frameworks, meta-framework, and implementation guidance for multi-client employee experience platforms. Internal research compiled using Grok. Saved at consulting/docs/2026-05-03-action-planning-grok-research.md. ↩ ↩² ↩³ ↩⁴

2. Huebner, L.-A., & Zacher, H. (2022). Effects of action planning after employee surveys. Journal of Personnel Psychology, 21(1), 23–36. https://doi.org/10.1027/1866-5888/a000285 ↩ ↩²

3. Huebner, L.-A., & Zacher, H. (2021). Following up on employee surveys: A conceptual framework and systematic review. Frontiers in Psychology, 12, Article 801073. https://doi.org/10.3389/fpsyg.2021.801073 ↩ ↩²

4. Gallup. (2023–2026). Q12 employee engagement meta-analysis and State of the Team action planning resources. https://www.gallup.com/workplace/356063/gallup-q12-employee-engagement-survey.aspx ↩ ↩²

5. Perceptyx. (2024–2026). Employee listening maturity model and 1-2-3 action framework research. https://blog.perceptyx.com/ ↩ ↩²

6. Culture Amp. (2024). Action framework: Tools to turn feedback into action. https://support.cultureamp.com/en/articles/7048533-action-framework ↩ ↩² ↩³

7. Huebner, L.-A., & Zacher, H. (2023). The role of mean item ratings, topic distance, direct leadership, and voice climate in action planning after employee surveys. Acta Psychologica, 238, Article 103950. https://doi.org/10.1016/j.actpsy.2023.103950 ↩ ↩²

8. Gollwitzer, P. M., & Sheeran, P. (2006). Implementation intentions and goal achievement: A meta-analysis of effects and processes. Advances in Experimental Social Psychology, 38, 69–119. ↩ ↩²

9. Oettingen, G. (2014). Rethinking positive thinking: Inside the new science of motivation. Current. ↩ ↩²

10. Miller, W. R., & Rollnick, S. (2013). Motivational interviewing: Helping people change (3rd ed.). Guilford Press. ↩ ↩²

11. International Coaching Federation. (n.d.). ICF Core Competencies and Code of Ethics. https://coachingfederation.org/ ↩

12. Deci, E. L., & Ryan, R. M. (2000). The "what" and "why" of goal pursuits: Human needs and the self-determination of behavior. Psychological Inquiry, 11(4), 227–268. ↩

13. McKinsey & Company. (various). The building blocks of capability (organisational health and capability-building writeups). https://www.mckinsey.com/ ↩

14. Browton, R. (2026, May 2). Action Planning — Shared Package Proposal. consulting/docs/2026-05-02-action-planning-package-proposal.md. ↩

15. Browton, R. (2026, May 3). Action Planning — Candidate Module Backlog. Internal research scan. consulting/docs/2026-05-03-action-planning-module-backlog.md. ↩

16. Kiresuk, T. J., & Sherman, R. E. (1968). Goal attainment scaling: A general method for evaluating comprehensive community mental health programs. Community Mental Health Journal, 4(6), 443–453. See also: Spence, G. B. (2007). GAS powered coaching: Goal attainment scaling and its use in coaching research and practice. International Coaching Psychology Review, 2(2), 155–167. ↩

17. Doerr, J. (2018). Measure what matters. Portfolio. See also: Lattice Goals (https://lattice.com/goals), Asana Goals (https://asana.com/goals), Quantum Workplace help documentation. ↩