This Company Eliminated All Managers and Turned Every Product Team Into a Profitable Startup

This Company Eliminated All Managers and Turned Every Product Team Into a Profitable Startup

Whilst most tech companies are debating the merits of OKRs versus alternative goal-setting frameworks, a Chinese appliance manufacturer has been quietly running one of the world’s most radical organisational experiments. Haier’s “Rendanheyi” model—which translates roughly to “inverted triangle of individual-goal combination”—has transformed a near-bankrupt refrigerator company into a global giant by eliminating traditional management and replacing it with market-driven entrepreneurship.

But could this model work for software development organisations? The answer might surprise you.

What Is Rendanheyi?

Rendanheyi flips traditional corporate structure on its head. Instead of hierarchical departments managed through cascading objectives, Haier operates as an ecosystem of thousands of small, autonomous business units called “self-managed teams” or SMTs. Each unit:

Operates as an independent business with full P&L responsibilityServes real customers (either external customers or other internal units)Buys and sells services from other units at market ratesShares in financial outcomes through profit-sharing and ownership stakesHas direct access to resources without middle management gatekeeping

The result? No middle managers, no annual planning cycles, no OKRs—just market forces driving alignment and accountability.

Why Traditional Goal-Setting Falls Short in Software Development

Before exploring how Rendanheyi might apply to software organisations, it’s worth acknowledging why conventional approaches often struggle:

The Innovation Problem: OKRs assume you can predict what success looks like. But breakthrough software products often emerge from experimentation that defies predetermined key results.

The Measurement Trap: Software development involves significant creative and problem-solving work that’s difficult to capture in quarterly metrics. Teams often end up optimising for what’s measurable rather than what’s valuable.

The Speed Penalty: Complex goal-setting processes add overhead and delay decision-making in an industry where speed to market is crucial.

The Scaling Challenge: As software organisations grow, maintaining alignment through cascading objectives becomes increasingly bureaucratic and disconnected from actual customer value.

Rendanheyi in Software: The Natural Fit

Software development organisations might actually be ideal candidates for Rendanheyi-style transformation, for several reasons:

Digital Products Enable Clean Unit Separation

Unlike manufacturing, where supply chains create complex interdependencies, software products can often be cleanly separated into distinct services, features, or platforms. A music streaming service, for example, could organise around units like:

Recommendation Engine Team (sells personalised playlists to other units)Audio Infrastructure Team (provides streaming services to product teams)Mobile Experience Team (builds customer-facing apps, buys services from backend teams)Analytics Platform Team (sells data insights to all other units)Natural Market Pricing Mechanisms

Software organisations already use internal concepts that mirror market pricing:

Infrastructure costs (AWS bills, computational resources)Engineering time (sprint capacity, story points)User engagement metrics (DAU, retention, conversion rates)

These existing metrics could form the basis of an internal market where teams buy and sell services from each other.

Rendanheyi Through the Lens of Quintessence

The “Quintessence” framework—which describes the ideal software development organisation—provides a compelling lens through which to evaluate Haier’s model. The alignment is remarkably strong, suggesting that Rendanheyi might represent one of the closest real-world implementations of quintessential organisational principles.

Strong Convergence Areas

Elimination of Traditional Management: Both Rendanheyi and Quintessence completely reject traditional hierarchical management. The quintessential organisation has “no managers” and emphasises that people doing the work should own “the way the work works.” Haier’s elimination of middle management and direct connection between autonomous units mirrors this perfectly.

Flow Over Silos: Quintessence emphasises horizontal value streams rather than vertical departmental structures. Haier’s approach of organising around customer-facing business units rather than functional departments aligns with this principle of organising around value flow rather than organisational convenience.

Trust and Autonomy: Both frameworks treat people as capable adults rather than resources to be controlled. Theory-Y assumptions about human nature—that people find joy in collaborative work and naturally take ownership—align with Haier’s trust in unit leaders to make entrepreneurial decisions.

Distributed Decision-Making: Quintessence advocates for the “Advice Process” and pushing decisions to where information originates. Haier’s model of autonomous decision-making within market constraints serves a similar function.

Key Tensions and Philosophical Differences

Market Mechanisms vs. Needs-Based Coordination: This represents the most interesting tension. Haier uses internal markets and P&L responsibility as coordination mechanisms, whilst Quintessence emphasises collaborative attention to “folks’ needs” through dialogue and consensus. However, these approaches might be more complementary than contradictory—internal markets serve as a mechanism for surfacing and meeting stakeholder needs.

Individual vs. Collective Accountability: Haier emphasises individual entrepreneurial ownership within small units, whilst Quintessence explicitly prefers group accountability and rejects “single wringable neck” approaches. Though Haier’s focus on small teams (10-15 people) somewhat bridges this gap.

Financial Incentives: Haier relies heavily on profit-sharing and market-based rewards, whilst Quintessence views extrinsic motivation sceptically, preferring intrinsic motivation through purpose, mastery, and autonomy. This represents a fundamental difference in assumptions about what motivates human behaviour.

Assessment: 75-85% Alignment

Haier achieves remarkable alignment with Quintessence principles—perhaps 75-85%—which is extraordinary for any large-scale implementation. The core philosophy of trusting people, eliminating bureaucracy, focusing on customer value, and enabling self-organisation aligns strongly.

The main gaps centre around Quintessence’s emphasis on nonviolence, psychology, and broader stakeholder consideration beyond customers and profits. Haier’s internal market mechanisms, whilst effective, might create competitive pressures that Quintessence would view as potentially harmful to interpersonal relationships.

Learning from Toyota’s Chief Engineer Model

Toyota’s Chief Engineer (CE) system offers another organisational model worth considering alongside Rendanheyi. The CE has complete responsibility for a vehicle programme from conception through production, coordinating across functional departments without formal authority over the specialists involved.

Key aspects of Toyota’s model that complement Rendanheyi thinking:

Cross-Functional Integration: The CE integrates expertise from multiple disciplines—similar to how Haier’s business units must coordinate across traditional functional boundaries.

Responsibility Without Authority: The CE must influence and coordinate without commanding—developing skills in consensus-building and collaborative decision-making that would serve software organisations well.

Long-Term Product Ownership: Unlike project-based structures, the CE maintains responsibility throughout the product lifecycle, similar to how Haier units maintain ongoing customer relationships.

Market-Driven Decisions: The CE makes trade-offs based on customer needs and market constraints rather than internal politics or resource optimisation.

For software organisations, a hybrid approach might combine Haier’s entrepreneurial autonomy with Toyota’s integration model—autonomous product teams with designated integrators responsible for cross-team coordination and long-term product vision.

Built-in Customer Feedback Loops

Software development organisations already have rapid feedback mechanisms through user analytics, A/B testing, and deployment metrics. This real-time customer data will drive market dynamics more effectively than quarterly OKR reviews.

A Rendanheyi Software Organisation in Practice

Imagine a mid-sized SaaS company reorganising around Rendanheyi principles:

Team Structure

Instead of traditional engineering, product, and design departments, the company forms customer-focused units:

Onboarding Experience Squad (responsible for new user activation)Core Platform Team (provides APIs and infrastructure services)Enterprise Features Unit (builds B2B functionality)Growth Engine Team (drives user acquisition and retention)Internal Market Dynamics

Teams operate on market principles:

The Growth Engine Team “buys” A/B testing infrastructure from the Core Platform Team at rates based on computational costs and engineering timeThe Enterprise Features Unit “pays” the Onboarding Squad based on how many enterprise customers successfully complete setupTeams can choose to build internally or “buy” from other teams based on cost and qualityProfit and Loss Responsibility

Each unit tracks financial performance:

Revenue attribution: Customer subscription revenue is attributed to teams based on feature usage and customer feedbackCost allocation: Infrastructure, support, and development costs are allocated based on actual resource consumptionProfit sharing: Teams share in the financial success of their contributionsAutonomous Decision Making

Teams make independent choices about:

Technology stack and architecture decisionsHiring and team compositionFeature priorities based on customer valueWhether to build, buy, or partner for new capabilitiesThe Benefits for Software Development

This approach could solve several persistent challenges in software organisations:

Faster Innovation: Teams can experiment and pivot without waiting for approval or updating company-wide roadmaps.

Better Customer Focus: When teams’ success is directly tied to customer value rather than internal metrics, product decisions improve.

Natural Scaling: As the organisation grows, new teams can form organically around customer needs rather than requiring top-down reorganisation.

Reduced Bureaucracy: No need for complex planning processes, alignment meetings, or quarterly business reviews.

Talent Retention: Engineers and designers get entrepreneurial ownership and direct impact on business outcomes.

The Challenges and Considerations

However, implementing Rendanheyi in software development isn’t without significant challenges:

Technical Architecture Requirements

Software systems would need to be architected for independence:

Microservices architecture to enable teams to deploy independentlyClear API boundaries to facilitate internal marketsRobust monitoring and billing to track resource usage across teamsCultural Transformation

The shift from employee to entrepreneur mindset is profound:

Risk tolerance: Team members must be comfortable with financial accountabilityCollaboration vs. competition: Internal markets could create unhealthy competition between teamsLeadership development: Teams need entrepreneurial skills, not just technical expertiseMeasurement and Pricing Complexity

Creating fair internal markets is challenging:

How do you price shared infrastructure like security, compliance, or platform services?What happens to teams working on foundational technology that doesn’t directly drive revenue?How do you handle cross-team dependencies that don’t fit clean market models?Regulatory and Compliance Constraints

Software companies often face regulatory requirements that don’t align with fully autonomous units:

Data privacy regulations may require centralised oversightSecurity standards might mandate consistent practices across teamsFinancial reporting may require traditional departmental structuresImplementation Strategies for Software Organisations

For software companies interested in experimenting with Rendanheyi principles, here are some practical starting points:

Start with Product Teams

Begin by giving product development teams more autonomy and P&L visibility. Let them make technology choices, prioritise features based on customer data, and share in the financial outcomes of their work.

Create Internal Service Markets

Identify shared services (infrastructure, design systems, analytics) and experiment with market-based allocation. Let teams choose between building internally or “buying” from shared service teams.

Implement Transparent Cost Allocation

Make infrastructure costs, engineering time, and other resources visible to teams. Start charging teams for their actual resource consumption rather than treating these as free shared resources.

Develop Customer-Centric Metrics

Move beyond engineering metrics (story points, velocity) to customer value metrics (feature adoption, customer satisfaction, revenue attribution).

Experiment with Team Formation

Allow teams to form organically around customer problems or business opportunities rather than maintaining static organisational boundaries.

The Future of Software Organisation

Rendanheyi represents a fundamentally different approach to organisational design—one that treats internal operations like external markets and replaces management hierarchy with entrepreneurial ownership. For software development organisations facing scaling challenges, innovation bottlenecks, and talent retention issues, it offers a compelling alternative to traditional approaches.

Whilst full implementation requires significant commitment and cultural change, the principles behind Rendanheyi—customer focus, market accountability, entrepreneurial ownership, and autonomous decision-making—can be adopted incrementally by forward-thinking software organisations.

The question isn’t whether your next quarterly planning cycle should use OKRs or another goal-setting framework. The question is whether you’re ready to move beyond goal-setting entirely and trust market forces to drive alignment and performance.

For software organisations willing to make this leap, the rewards could be transformational: faster innovation, better customer outcomes, and a more engaged, entrepreneurial workforce that thinks like owners because they actually are owners.

The future of software development might not look like traditional corporate hierarchies at all. It might look more like a marketplace of entrepreneurial teams, competing and collaborating to create customer value. And that future might be closer than we think.

Further Reading

Hamel, G. (2011). The big idea: First, let’s fire all the managers. Harvard Business Review, December 2011.

Hamel, G., & Zanini, M. (2020). Humanocracy: Creating organizations as amazing as the people inside them. Harvard Business Review Press.

Marshall, R. W. (2021). Quintessence: An acme for software development organisations. Falling Blossoms. [Available on Leanpub]

Hamel, G., & Zanini, M. (2018). The end of bureaucracy. Harvard Business Review, November-December 2018.

Kennedy, M. N. (2003). Product development for the lean enterprise: Why Toyota’s system is four times more productive and how you can implement it. Oaklea Press.

Pink, D. H. (2009). Drive: The surprising truth about what motivates us. Riverhead Books.

Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing.

Sobek, D. K., Ward, A. C., & Liker, J. K. (1999). Toyota’s principles of set-based concurrent engineering. MIT Sloan Management Review, 40(2), 67-83.