3-part series | Estimated reading time: 10 minutes
Last time, I traced the process of turning a 685-page classic into a three-layer framework through back-and-forth sessions with AI. A shared foundation, profiles, and a talent development environment. I even designed a privacy architecture.
Honestly, I was pretty satisfied at that point.
Then I did what the framework itself recommends: "bounce this very design off an AI." What is the biggest weakness in my own design? That question revealed two more structural blind spots.
Blind Spot ①: Development without goals is just a "fix your weaknesses" game
Using the five-dimensional evaluation introduced in Part 1—depth of structuring, breadth of perspective, critical thinking, metacognition, and profile fit—I generated an analysis report for a hypothetical 18-person organization.
The report came out beautifully. It aggregated scores for each team, flagged homogenization risks, suggested complementary pairings, and prioritized development initiatives. Things like "breadth of perspective is 3.2, let's get it to 3.6" and "metacognition is 3.1, let's aim for 3.4."
Then a decisive question arrived.
"This report doesn't account for goals. Shouldn't it also factor in the company's medium- and long-term plans, as well as each individual's goals for 1, 5, and 10 years out—and plan and evaluate using Working Backwards from those goals?"
Absolutely right.
Every initiative had been designed around improvement-based thinking: "this score is weak, let's fix it." Low breadth of perspective → raise it. Weak metacognition → train it.
But the "what for" was completely missing.
If the company is entering the payments business next year, strengthening security thinking is the top priority. If the strategy is to launch a flood of AI-driven new products, the ability to iterate quickly in Profile A is what matters most. If an engineer's five-year goal is to become CTO, it might be better to invest heavily in metacognition and breadth of perspective rather than raising every dimension evenly.
Without goals, development is nothing but a "fix your weaknesses" game.
Working Backwards: fixing weaknesses vs. back-casting from goals
Once you bring in the Working Backwards perspective, the same scores produce a completely different set of priorities.
Weakness-fixing approach (before):
- Introduce sparring templates (raise the floor on breadth of perspective)
- Address metacognition homogenization
- Knowledge-mapping workshop
Goal back-casting approach (after):
- Accelerate Profile B promotion (back-cast from major client onboarding in Q3 → Q2 deadline)
- Build security infrastructure (back-cast from payments feature launch → Q3 deadline)
- Introduce sparring templates (customized for immediate impact on the two items above)
Even "raising the floor on metacognition" can drop in priority under goal back-casting. If the external API release deadline isn't until Q1 2027, strengthening that dimension can wait.
Individual development plans change too
Consider member J, six months into the job. Scores across all dimensions range from 2.0 to 2.8—low across the board.
Weakness-fixing plan: Raise the floor on every dimension. Build fundamentals on a Profile A team.
Working Backwards plan: J's five-year goal is "security engineer." In that case, spend year one building fundamentals in Profile A—but consciously weave a security lens into every sparring session from day one. Plan a move to a Profile C team in year two.
Even with the same "build fundamentals" starting point, having a goal to back-cast from changes the focus of every daily sparring session.
The hierarchy of goals
To make Working Backwards function, goals are connected in four layers.
Company medium/long-term plan (3–5 year vision)
└→ Annual OKRs or business targets
└→ Quarterly targets for each project
└→ Individual short-term (1 year) / mid-term (5 year) / long-term (10 year) career goals
Back-casting from the top down determines "what should this team prioritize developing next quarter?" Profile promotion timing also becomes active and intentional—driven by "the business plan says so"—rather than the passive "seems about time."
The weaknesses of Working Backwards
That said, goal back-casting isn't a silver bullet. It has three weaknesses.
Dependence on goal quality. Whether "I want to be CTO in five years" is a genuine aspiration or just something that sounds good changes the entire plan. The goal-setting itself needs to be worked through in a sparring session.
Goals change. Discovering a passion for large-scale systems and pivoting from security to architecture—it happens all the time. You need the flexibility to welcome those changes.
Company goals and personal goals can conflict. If the company needs security talent but the person wants to go into front-end development, AI can't resolve that. The manager and the individual have to talk it out and find a middle ground.
Even so, it's clearly better than "fixing weaknesses with no goal in sight."
Blind Spot ②: Relentless rationality kills what rationality can't create
I had just integrated Working Backwards and thought Framework v2 was complete—when another fundamental question arrived.
"Developer creativity, motivation, team cohesion, and a sense of play are the sources of innovation. Just as Google's '20% rule' gave birth to Gmail and AdSense, shouldn't the framework preserve space for 'irrational' experimentation? In the long run, that contributes to organizational sustainability."
Looking back at everything we'd discussed, it was all underpinned by a single philosophy: design rationally, measure rationally, improve rationally.
The shared foundation is rational. The profiles are rational. The evaluation is rational. The privacy architecture is rational. We even added Working Backwards to back-cast from goals.
Everything was rational. And that perfect rationality was itself the blind spot.
Gmail came from Google's 20% rule. So did AdSense and Google News. None of these could ever emerge from "development investment back-cast from the company's medium- and long-term plan." If something doesn't exist in the plan, it can't be a target for back-casting.
This framework had taken Software Engineering at Google as its starting point—and yet had missed one of Google's most important cultural traits.
The sixth dimension: openness
The five-dimensional evaluation—structuring, breadth of perspective, critical thinking, metacognition, profile fit—all measure "how well you handle known problems."
But the source of innovation lies in "the ability to notice what no one has yet recognized as a problem." This connects deeply to the Big Five personality trait of Openness to Experience.
So I added "openness" as a sixth dimension—but it is treated in a fundamentally different way from the other five.
| Design question | Answer |
|---|---|
| Include it in the evaluation score? | No. Openness is a personality trait, not a skill. Framing low openness as a "weakness" is inappropriate. |
| Then what is it measured for? | Observation and encouragement. For the individual's self-awareness, and to monitor diversity across the team as a whole. |
| How does it inform team composition? | A team where everyone scores 5 on openness is stimulating but never ships. A team where everyone scores 1 is reliable but never innovates. It's used to check the balance of diversity. |
Space for exploration: institutional design
Measuring openness alone isn't enough. You need to institutionally create a state in which exploration is welcomed by the organization.
The 20% exploratory sparring rule (recommended). At least 20% of all sparring sessions should be on topics with no direct connection to the current project. But "recommended, not required" is absolutely critical. The moment it becomes mandatory, it transforms into "20% obligatory exploration" and loses its meaning as a source of creativity.
Exploratory sparring showcase (monthly). A forum where anyone who wants to can share "this is the interesting thing I discussed with AI." Quality of presentation and business relevance are irrelevant. "It was interesting" is enough. Attendance and presenting are both optional. It is explicitly stated that none of this feeds into evaluations.
Hackathon sparring day (quarterly). Everyone steps away from regular work and spends the day building something through free-topic AI sparring. This is intentionally disconnected from the Working Backwards goal back-casting—on this day alone, "irrational" things are officially permitted.
The design decision to "not manage"
Here lies the most delicate design point.
The moment you institutionalize playfulness, it stops being play.
The moment "Hackathon Sparring Day" is institutionalized, it becomes "play that the organization has sanctioned"—different in nature from genuinely spontaneous playfulness. But without any institution, the psychological barrier of "am I even allowed to play?" remains.
The answer to this contradiction is to let the institution do nothing more than grant permission, and manage the content not at all. What to do, what to build, whether to produce any output—completely free. The design decision to "not manage" is itself the most important mechanism for protecting playfulness.
Recommended exploration levels by profile
The space for exploration is also calibrated differently for each profile.
| Profile | Exploration recommendation | Reason |
|---|---|---|
| A: Small-scale, high-velocity | ★★★ Strongly recommended | Experimentation and discovery determine product direction at this stage |
| B: Large-scale systems | ★★ Recommended | A source of improvement ideas that push beyond existing constraints |
| C: Security-strict | ★ Permitted | Creative offensive thinking is valuable, but core work comes first |
| D: Mission-critical | ☆ Permitted with restraint | Stability is the top priority |
Final architecture: 3 layers + 2 axes
Integrating the two blind spots, the final form of the framework is complete.
┌─────────────────────────────────────────┐
│ Horizontal axis ①: Working Backwards │
│ Company → Division → Project → Individual goal back-cast │
├─────────────────────────────────────────┤
│ │
│ Layer 1: Shared Foundation │
│ Monorepo / Trunk-based / AI-driven CI/CD │
│ Cultural principles / Goal hierarchy / Space for exploration │
│ │
│ Layer 2: Profiles (A / B / C / D) │
│ AI dependency / Test standards / Review structure │
│ Exploration recommendation set per profile │
│ │
│ Layer 3: Talent Development Environment │
│ 6-dimensional evaluation (5 dimensions + openness) │
│ 3-stage feedback │
│ Privacy architecture (3 data layers) │
│ │
├─────────────────────────────────────────┤
│ Horizontal axis ②: Space for Exploration │
│ 20% exploration / Showcase / Hackathon │
└─────────────────────────────────────────┘
Two design principles
Two principles run through this entire framework.
Principle ①: Protect through mechanisms, not policies. Not "even the CEO won't look at the logs" but "even if the CEO tried, the access rights don't exist." Not "we won't use this for evaluations" but "the data doesn't exist in a form that could be used for evaluations."
Principle ②: Protect what lies outside rationality—rationally. Working Backwards goal back-casting is fully rational. But unplanned innovation doesn't come from rationality. So we "rationally design," "rationally institutionalize," and "rationally protect" the space for exploration.
Coexistence of rationality and irrationality. It looks like a contradiction—but this was the final piece the framework needed.
Coming up next
In Part 2, I explained the discovery of two structural blind spots (Working Backwards and space for exploration) and laid out the full picture of the final framework (v2).
In Part 3, I'll translate this framework into something you can use starting tomorrow. That means the concrete operating rules for Profiles A through D as implemented in Claude Code's CLAUDE.md file, the design of the AI analysis report generation prompt, and a look back at how this very article is itself a live example of sparring in action.
Continues in Part 3: "Ready to Use Tomorrow — Implementing CLAUDE.md and AI Analysis Prompts" →