In software engineering, product design, and infrastructure planning, disagreement isn’t the problem—it’s how disagreement unfolds that determines velocity, morale, and outcome quality. Too often, technical debates stall over “why not this?” rather than “how might we improve this?” Teams invest hours in critiques that don’t land, proposals that get dismissed without iteration, and meetings where consensus emerges only after exhaustion—not insight. Enter plussing: a deceptively simple, rigorously applied communication discipline borrowed from Pixar’s creative process and refined for technical environments. Unlike feedback frameworks that emphasize critique or validation, plussing mandates forward motion—every contribution must add concrete value to an existing idea, however small. It is not positivity for its own sake; it is precision with purpose.
What Plussing Is (and Isn’t)
Plussing originated at Pixar under Ed Catmull, where directors were required to respond to story reels not with “That doesn’t work” but with “What if we tried X to strengthen Y?” The goal wasn’t to avoid criticism—it was to ensure every intervention advanced the work. In tech contexts, plussing operates as a lightweight protocol: when someone presents a proposal—a database schema, a CI/CD pipeline change, a UI interaction flow—responses must begin with an explicit acknowledgment of what’s working, followed by a specific, actionable suggestion that builds on it.
This differs fundamentally from common alternatives:
- “Yes, and…” improvisation: Often misapplied as blind agreement, which suppresses necessary risk analysis.
- Critique-first culture: Where “Here’s why this won’t scale” precedes any engagement with intent or context—eroding psychological safety.
- Solution-jumping: Skipping diagnosis to propose alternatives, leaving the original idea’s constraints unexamined.
Plussing sits between these poles: respectful, grounded, and generative. It assumes competence in the presenter and treats ideas as living artifacts—not fixed positions to defend or defeat.
Tip: Start plussing practice with a 30-second “plus pause”: before replying in meetings or PR comments, ask yourself, “What one thing here already works—and how can I extend it?”The Four Pillars of Technical Plussing
Effective plussing in engineering settings rests on four interdependent principles—each enforceable through norms, not tools:
- Anchor in the current artifact: Reference a specific line in code, a section of architecture diagram, or a user journey step—not abstractions like “the backend” or “the UX.”
- State a strength explicitly: Name *what* functions well and *why*—e.g., “The retry logic on line 42 correctly handles transient network failures because it uses exponential backoff.”
- Propose a concrete extension: Suggest a modification, addition, or refinement—not a replacement. Use “What if we…” or “Could we enhance this by…” rather than “We should…” or “This needs…”
- Clarify the intended outcome: Link the plus to a measurable impact—e.g., “…to reduce median API latency under load by 15%,” or “…to make the error state recoverable without page reload.”
These pillars transform debate from a zero-sum contest into collaborative prototyping. When a frontend engineer proposes a new form validation pattern, a backend peer doesn’t say, “That won’t handle our rate-limiting headers.” Instead: “The client-side regex validation catches 92% of malformed inputs early—great for UX responsiveness. What if we add a preflight OPTIONS check to surface rate-limiting conflicts *before* submission, using the same error-handling component?” That response preserves agency, shares context, and invites co-design.
A Real-World Case Study: Reducing Merge Conflict Density at Verve Labs
Verve Labs, a fintech startup scaling its core transaction engine, faced escalating PR review friction. Engineers reported spending 40% of review time debating naming conventions, error message phrasing, or logging verbosity—issues that rarely impacted correctness but derailed alignment. Their “review checklist” mandated coverage, tests, and security scans—but said nothing about *how* to discuss trade-offs.
They piloted plussing for two sprints across three backend teams. Rules were minimal: every PR comment had to include (1) one observed strength and (2) one specific, implementation-ready plus. Comments like “Rename `processTxn()` to `processTransaction()` for consistency” were disallowed. Instead, reviewers wrote: “The idempotency key generation in `processTxn()` correctly prevents duplicate processing across retries—critical for payment integrity. What if we extract the key derivation logic into a dedicated `IdempotencyKeyGenerator` class? That would let us unit-test it in isolation and reuse it in the refund service.”
Results after six weeks:
- PR cycle time decreased by 31% (median from 18.2 to 12.6 hours)
- Comment-to-merge ratio dropped 44%, with no increase in post-merge bugs
- 78% of engineers reported “higher confidence in team decisions” in anonymous pulse surveys
Crucially, plussing didn’t eliminate disagreement—it redirected energy toward shared ownership. When a senior engineer challenged a junior’s caching strategy, their comment began: “The TTL-based cache invalidation avoids stale reads during normal operation—exactly what we need for this read-heavy endpoint. Could we add a cache-busting header to the POST `/v1/transactions` response? That would let the frontend trigger immediate refresh after write operations, closing the last consistency gap.” The junior implemented it in under an hour.
Plussing in Practice: A Step-by-Step Implementation Guide
Adopting plussing requires no tooling, no training modules—just intentional habit formation. Follow this sequence to embed it sustainably:
- Week 1: Model & Name It
Lead engineers demonstrate plussing in 2–3 high-visibility PRs or design docs. Label comments clearly: “PLUS: [strength] → [extension].” Share the rationale in team sync: “We’re shifting from ‘Is this right?’ to ‘How can we make this stronger?’” - Week 2–3: Scaffold with Templates
Add a comment template to your PR description:✅ Strength: [What works]. Require completion for first-time contributors.
➕ Plus: [One concrete, testable extension]
🎯 Outcome: [How this improves reliability/usability/performance] - Week 4: Normalize “Plus Refusals”
When a non-plus comment appears (“This violates our auth policy”), gently reply: “Help me plus this—what part of the current auth flow does this build on? How might we adapt the policy enforcement here?” Treat refusal as data, not defiance. - Month 2: Measure & Iterate
Track metrics: % of PR comments containing both strength + plus, reduction in “rework loops” (same issue debated >2 times), and time-to-merge for complex changes. Adjust templates based on gaps. - Ongoing: Celebrate Micro-Wins
In retros, highlight examples: “Maria’s plus on the Kafka consumer group naming helped us standardize across services—let’s document that pattern.” Recognition reinforces behavior more than rules.
Do’s and Don’ts of Technical Plussing
Plussing fails when treated as politeness theater. Its power lies in specificity and accountability. This table clarifies operational boundaries:
| Scenario | Do (Plussing) | Don’t (Non-Plussing) |
|---|---|---|
| Reviewing a new monitoring dashboard | “The latency percentile chart highlights P95 spikes during batch jobs—perfect for root cause triage. What if we overlay the job scheduler’s execution timeline as a secondary axis?” | “The dashboard is too noisy.” |
| Challenging a proposed API versioning strategy | “Using URL path versioning (`/v2/users`) makes client migration predictable and caches cleanly. Could we add a deprecation header to `/v1/` responses to guide clients toward v2 adoption?” | “URL versioning is deprecated. Use header versioning.” |
| Responding to a security finding | “The input sanitization on the search field blocks XSS—solid baseline protection. What if we add Content-Security-Policy headers with strict `script-src` directives to mitigate any bypass?” | “This is vulnerable to XSS.” |
Note the pattern: every “Do” names a functional strength *first*, then proposes a bounded, implementable enhancement tied to a clear system property (predictability, cacheability, defense-in-depth). Every “Don’t” states a judgment without anchoring in observable behavior or offering a path forward.
Expert Insight: Why Plussing Scales Technical Judgment
Dr. Lena Torres, cognitive scientist and author of Collaborative Reasoning in Distributed Systems, studied plussing adoption across 17 engineering teams. Her research reveals why it outperforms generic “constructive feedback” guidelines:
“Plussing forces the brain out of binary evaluation mode—‘good/bad’—and into generative modeling: ‘Given what exists, what’s the smallest, highest-leverage change?’ This reduces cognitive load in high-stakes discussions and surfaces hidden assumptions. We found teams using plussing reached technical consensus 2.3x faster *not* because they agreed more, but because they spent less time re-establishing shared context. It’s a protocol for shared cognition.” — Dr. Lena Torres, Senior Researcher, MIT Human Systems Lab
Her findings confirm what practitioners observe: plussing doesn’t eliminate conflict—it compresses it into productive cycles. When every voice must contribute to the artifact’s evolution, defensiveness gives way to curiosity. “What if we…” becomes the default syntax, not “Why didn’t you…”
FAQ
Does plussing suppress necessary negative feedback?
No—it redirects negativity into constructive action. Saying “This will crash under load” offers no path forward. Plussing requires: “The current connection pooling works well for 50 concurrent users (we validated this in staging). What if we add circuit-breaking logic to fail fast above 100 connections, preventing thread exhaustion?” The risk is named, the evidence cited, and the mitigation specified—all within the plus framework.
What if the original idea has fundamental flaws?
Plussing still applies. Identify the strongest element—even if narrow—and build from there. Example: “The state machine diagram correctly models the ‘pending → confirmed’ transition. To address the race condition in the ‘pending → failed’ path, what if we introduce a distributed lock with timeout, using the same Redis instance already configured for session storage?” You’re not pretending the flaw doesn’t exist—you’re starting from shared ground to solve it.
Can plussing work in async written communication (Slack, email)?
Yes—and it’s especially powerful there. Written plussing leaves a searchable, reusable record of reasoning. In Slack, use threading: first message = strength, second = plus, third = outcome. Avoid collapsing threads. In email, structure replies as: ✅ Strength, ➕ Plus, 🎯 Outcome. Teams report 60% fewer follow-up clarification messages after adopting this format.
Conclusion
Plussing is not a soft skill—it’s a technical discipline with measurable impact on system quality, team velocity, and individual growth. It transforms debates from endurance tests into precision instruments: sharpening focus, reducing noise, and ensuring every exchange moves the work forward. You don’t need executive buy-in to start. Next time you review a pull request, join a design review, or draft a proposal, try one plus. Name what’s working. Propose one concrete extension. State the outcome you’re optimizing for. Notice how the conversation shifts—not toward agreement, but toward co-creation.
Productive debate isn’t about winning. It’s about building better systems, together, one thoughtful extension at a time. Your next plus is already forming in your mind. Write it down. Ship it. Watch what grows.
💬 Try plussing in your next technical discussion—and share your first plus in the comments. What strength did you notice? What tiny extension made it stronger? Let’s learn from each other’s real-world iterations.
