
Loading...
Loading...


Assembling top individuals doesn't make a team. This article outlines how to design a small but solid team using three principles—role design, execution autonomy, and communication structure—along with the Quinn and Cameron organizational growth model.

Open innovation is a paradigm where companies must intentionally bring in external ideas and technologies, share internal assets with the outside world, and create value to survive and grow. In other words, it's about breaking down organizational boundaries and increasing the probability of innovation through active external engagement—clearly demonstrating why 'absorptive capacity' is a core competitive advantage for modern startups.

Even the clearest vision remains an empty slogan without collective efficacy—the shared belief that the team can execute it. An overly grand vision can overwhelm and paralyze a team. One of a founder's most important roles is not just to articulate a vision but to design and build the team's self-efficacy.
CODEX 19. How to Turn Problem-Solving Into Organizational Capability
The startup world is a continuum of unpredictable variables. At every decision point, what we need to find isn't the 'right answer' but 'criteria' to build a learning system for problem-solving. Problem-solving ability depends on how clearly and effectively we establish these criteria.
'Establishing criteria' isn't simply listing principles—it's the process of clarifying which values to prioritize and from what perspective to view problems in complex situations.
"Should we launch or hold off?" "Should we hire more people or save resources?" A startup's day is like driving on a foggy road. Many founders try to dodge every obstacle with exceptional 'driving skill (intuition).' But this approach is like starting from zero before every new crisis.
To determine 'what criteria will we use to decide' when facing these questions, you must establish the right criteria. Without criteria for problem-solving, decisions are left to 'luck' and failures don't lead to 'learning.'
Great teams don't rely solely on driving skill. They turn the entire team into an 'autonomous driving system.' Every driving experience, especially accidents or wrong turns (failures), becomes valuable 'learning data' that improves the accuracy of the next drive. The more failure data accumulates, the more sophisticated the team's autonomous driving system's decision-making model becomes.
Surviving teams aren't 'teams that make good decisions'—they're 'teams that accumulate every aspect of decision-making as assets and evolve into smarter systems.'
The starting point of all problem-solving isn't finding the 'right answer' but establishing 'criteria.' Criteria are like a compass that determines which direction a ship sails in a foggy sea. In autonomous vehicle terms, this is like the core driving principle that serves as the foundation for all decisions: "In any case, passenger safety comes first." Without this principle, the car has no choice but to drift in confusion before countless variables.
The same applies to startups. Without clear criteria when facing questions like "Is market response speed important? Or is bug-free stability more important?" success becomes 'luck' and failure doesn't lead to 'learning.'
Many founders say "I decided intuitively," but intuition alone can't explain the causal relationship of that decision to the team or reproduce the next success. Therefore, establishing 2-3 simple, clear criteria that can connect to specific actions and results—like "contribution to reducing user churn" or "development resource efficiency"—is the first step in the long journey of problem-solving.
On the road, countless obstacles appear simultaneously. 'Priority' is a real-time decision algorithm that determines which obstacles to respond to first with limited resources and which to ignore. For startups, setting priorities goes beyond 'choice and focus'—it's the skill of clearly deciding what to 'focus on' and what to 'exclude.'
The most common misconception here is that 'urgent tasks' are 'important tasks.' While fixing a bug right in front of you (urgent and important work) is necessary, designing a system that reduces the bug occurrence rate itself in the long term (important but not urgent work) determines the team's future.
The Eisenhower Matrix is a powerful framework that classifies tasks into four categories based on importance and urgency, telling us exactly where to focus.

According to these criteria, we can decide which tasks to 'handle immediately (Do),' which to 'plan (Decide),' which to 'delegate,' and which to boldly 'delete.' Clear priority setting like this concentrates the team's energy on the most important problems, creating explosive execution power that achieves maximum effect with limited resources.
The most powerful force of autonomous vehicles lies in 'Fleet Learning.' When one vehicle's accident or error data is transmitted to a central server, all vehicles connected to the network simultaneously learn from that experience and don't repeat the same mistake.
A startup's 'failure archive' is the core of this fleet learning. Failures shouldn't be hidden as individuals' embarrassing experiences but accumulated as the entire organization's 'shared memory.'
Google, the symbol of innovation, has a success rate of only about 50% among its countless projects. Since 2006, it has even operated a unique space called 'The Google Cemetery' that displays tombstones of discontinued services. This space honestly records numerous failed problem-solving projects with their year-by-year termination dates and reasons. In fact, the average lifespan of Google products and services is 4 years and 1 month.

Google thoroughly analyzes these failures using the post mortem method. Like autopsying a body, it identifies direct and indirect causes of problems, documents them precisely, and establishes countermeasures.
The important point here is that this process isn't about assigning blame for failure. By creating a standard format for the post mortem process, recording it, and sharing it across the organization, accumulated failure data becomes a valuable learning asset.
When all these setbacks come together, they become real 'assets.' Failures in problem-solving shouldn't end as individual disappointments—their criteria and priorities must be recorded and turned into organizational strength.
Why do some teams repeat the same mistakes while others grow dramatically through failure? Harvard professor Chris Argyris explains this difference with his 'Double-Loop Learning' theory.

Single-Loop Learning
This is the stage of correcting errors that occur within established rules and assumptions. It's actions like "Ad conversion rates are low, so let's change the ad copy." This is like fine-tuning an AI model's weights.
Double-Loop Learning
Beyond correcting errors, this is the stage of questioning the rules and assumptions themselves, like "Why did we assume this ad copy would be effective in the first place?" This is like redesigning the AI model's structure itself, enabling it to solve new dimensions of problems it couldn't solve before. A startup's problem-solving archive is the essential tool that enables this 'double-loop learning.'
Step 1: Set Criteria and Priorities
Before solving any problem, create a culture of first defining and agreeing on "What are the 3 most important criteria for judging the success of solving this problem?" and "What is the priority among those criteria?"
Step 2: Structure and Store All Decisions
Beyond simple meeting notes, archive all important problem-solving processes in this framework: [Problem (Situation) → Criteria/Priorities → Alternatives → Final Decision and Reasoning → Results → Lessons Learned].
Step 3: Regularly Analyze and Learn from Data Together
At least once a month, bring the entire team together to share and discuss a recent archive of failures. This is not a session for blame—it's the most critical time to update your team's autonomous driving algorithm.
Your team doesn't need problem-solvers—it needs architects of a 'learning system' that turns even failures into assets
A startup's true strength doesn't lie in an individual's exceptional problem-solving abilities. It depends on whether you've built a 'learning system' that transforms even the experience of failure into the collective intelligence of the entire team. The market tells you the right answer, but the ability to learn can only be created by you.
[Startup Codex 22]
Produced using content with permission from Brunch writer jaha Kim.