The outsourcing decision that looked different to everyone

A company decides to outsource part of a new product. The founder sees a strategic bet that reshapes the business. The engineering lead evaluates vendors. A team manager plans the collaboration. A senior engineer audits APIs. And a junior developer just sees a confusing backlog. Same decision, five completely different experiences. This article explores why that happens, and what it reveals about how communication breaks down between organizational levels.

If you're already familiar with Stratified Systems Theory, you can skip ahead to Why This Matters for how I apply the model to organizational diagnosis.

What Most Discussions of Team Collaboration Miss

In previous articles, I've explored how teams collaborate across organizational boundaries: the strategy-to-execution continuum that maps where work sits, and the friction that emerges when teams have mismatched expectations about their working relationship.

But there's a deeper question these models don't fully answer: why does friction emerge so predictably between certain roles? Why do founders and engineers talk past each other even when both are competent and well-intentioned?

The answer lies in how work itself stratifies by complexity. The cognitive demands of a junior engineer's work are qualitatively different from those of a CTO, not just quantitatively larger. And these differences occur at specific discontinuities, not along a smooth gradient.

Elliott Jaques spent 35 years studying this phenomenon. His insight: the nature of work changes, with different time horizons of the longest task a role is accountable for. These different horizons are not arbitrary. They reflect real changes in how people think about problems, "just as ice changes to water and water to steam at certain specific temperatures."¹

Understanding these strata matters for two reasons. First, it explains why communication breaks down between certain roles and what to do about it. Second, it provides a framework for deciding which capabilities you need inside your organization and which you might source from a vendor. When you outsource software engineering, you're drawing a line on this continuum. The question is whether you've drawn it in the right place.

The Model: How Work Stratifies by Complexity

The model I'm drawing on here is Stratified Systems Theory (SST), developed by Elliott Jaques.¹ Jaques observed that organizations naturally stratify into distinct levels of work complexity. Not because someone designed it that way, but because the work itself demands it.

Each stratum is defined by several dimensions: the time horizon over which decisions play out (what Jaques called "time span of discretion"), the level of abstraction required, and the cognitive mechanisms used to solve problems. These dimensions cluster together in predictable ways.

Jaques identified seven strata. For startups and smaller companies, the first five capture most of the relevant dynamics. Where a founder needs to operate depends on the complexity of the product and the market: a straightforward product in a known market may only require Stratum IV thinking, while a complex product in an emerging market demands Stratum V.

Five Strata In One Startup

What makes these strata distinct isn't just the time horizon. It's how you think at each level.

To make these strata concrete, I'll use a single scenario that runs through all five levels. A growing software company has decided to build a new product alongside its existing platform. Leadership has agreed to outsource part of the development to an external vendor to move faster. The decision has been made at the top, but it hasn't reached the full organization yet. Watch how the same situation looks completely different depending on where you sit.

I'm deliberately not using job titles in these examples. The same role can operate at different strata depending on the organization. What matters is the nature of the work, not the title on the door.

Stratum I: Direct Judgment

Alex is the newest member of the engineering team. He doesn't know it yet, but the company is about to outsource part of its new product development to an external vendor. That decision is being made several levels above him.

What Alex sees is a backlog full of bugs and operational issues. A flaky integration test is blocking deployments. A customer reported data showing up twice. The monitoring dashboard has three alerts he needs to triage before standup.

The cognitive work here is direct judgment: combining immediate sensory and experiential data into a problem construct. The time horizon is hours to days. The skills that matter are technical depth, pattern recognition, and the ability to stay calm under pressure.

This is valuable, demanding work. But it's a specific kind of work, and the judgment it develops is tuned to this context.

Stratum II: Diagnostic Accumulation

Priya is one of the more experienced engineers on the team. She's heard rumors about an outsourcing decision, and she's already thinking about what it means technically.

If an external team is going to build parts of the new product, they'll need to integrate with the existing codebase. Priya starts systematically evaluating the integration surface: which APIs are stable enough to expose, which internal services have undocumented dependencies, and what data contracts would need to be formalized.

Over several weeks, she accumulates evidence from code reviews, architecture documents, and conversations with colleagues. Eventually she produces a clear assessment: three integration points are ready for external consumption, two need significant refactoring, and one core service is too tightly coupled to expose safely.

This is diagnostic accumulation: gathering information over time to construct a discrete set of evidence that reveals what's actually happening. The time horizon is longer (months, not hours), and the cognitive work is different. Not direct judgment, but systematic pattern-building across architectural concerns.

Stratum III: Alternative Pathways

Marcus manages the team that will work alongside the outsourced vendor. The decision to outsource has been made. His job is to figure out how to make it work.

There's no playbook for this. Marcus has to construct alternative pathways. What if the vendor works in a separate repository with defined API contracts? Clean boundaries, but slower iteration. What if they work in the same codebase with feature flags? Faster integration, but more onboarding and review overhead. What if they start with a small pilot module before scaling up?

Each possibility branches further. Who owns integration tests? What does each model mean for his team's capacity to keep delivering on the existing roadmap? Marcus maps these scenarios, evaluates their downstream effects, and turns them into a concrete collaboration plan.

This is serial alternative pathway construction: thinking through branching futures and choosing among them. The time horizon extends to 1-2 years, and the cognitive work is scenario planning and stakeholder alignment, not just diagnosis.

Stratum IV: Parallel Processing

Elena leads the engineering organization. David has asked her to evaluate outsourcing options and come back with a recommendation. She has three vendor candidates in different locations, each with a different profile.

Vendor A is in Eastern Europe: strong talent, reasonable rates, geopolitical risk. Vendor B is in Southeast Asia: cheapest, but time zone challenges. Vendor C is a local boutique: expensive, but easy to manage.

Elena can't evaluate these sequentially. She processes them in parallel across multiple dimensions: technical capability, cost, communication overhead, IP protection, time zone compatibility, and scaling flexibility. Her job is to turn this into a structured analysis of trade-offs that David can act on.

This is parallel processing with trade-offs: managing multiple streams simultaneously, using exception-based attention to avoid drowning in data. The time horizon is 2-5 years, and the cognitive work is orchestration across complexity, not sequential problem-solving.

Stratum V: System-Wide Consequences

David founded the company and runs it. The outsourcing decision started with him, but not as a simple "build vs. buy" choice. It's a system-wide bet.

Building in-house would mean slowing down the core product and stretching the team thin. Outsourcing means putting part of the company's future in hands he doesn't directly control. But the cost difference could extend runway by six months, which changes the fundraising timeline, which changes his negotiating position with investors.

These aren't parallel workstreams David can delegate. They're interconnected variables: product quality, team morale, financial runway, IP risk, investor perception, competitive timing. Every choice produces 2nd-order effects that propagate across the business.

Jaques observed that at this stratum, executives often appear to be "deciding things off the cuff" because the synthesis they're doing isn't visible in their words. They're integrating across a broader context than their subordinates can see.

This is practical judgment of system-wide consequences: evaluating trade-offs where every decision affects every other part of the system. The time horizon is 5-10 years, and the cognitive work is integration across domains, not just orchestration within them.

Beyond Startups: Strata VI and VII

Jaques identified two additional strata beyond the five described above. While they're rarely relevant for startups and smaller companies, they complete the picture.

At Stratum VI, the question shifts from managing a system to choosing between fundamentally different systems. In our scenario, this isn't about whether to outsource. It's about whether the company should remain a product builder at all, or become a platform that others build on. The time horizon is 10-20 years, and the cognitive work is evaluating competing business models, each with its own internal logic and trajectory.

At Stratum VII, the scope extends beyond any single company. Think of someone defining international standards for software supply chain integrity, or shaping regulatory frameworks for cross-border technology outsourcing. The outsourcing decision that started as a practical business choice connects to questions about global labour markets, intellectual property regimes, and the future structure of the technology industry. The time horizon is 20-50 years.

For the remainder of this article, we'll focus on strata I through V, where most of the relevant dynamics play out for growing companies.

Different Work, Not Better Work

None of these strata is "better" than another. They're different kinds of work, requiring different kinds of judgment, operating at different points on the same continuum. The engineer isn't "less than" the executive; they're solving different problems with different feedback loops.

Every point on the continuum is necessary for organizational function. And individuals often operate at different points for different aspects of their role: the same person might handle a production incident (Stratum I) in the morning and contribute to quarterly planning (Stratum II-III) in the afternoon.

Why This Matters: The Communication Breakdown

These strata map directly onto the strategy-to-execution continuum I introduced in an earlier article. That model describes where work sits along the spectrum from strategic intent to operational delivery. SST explains why that spectrum exists: the cognitive demands of work change at specific discontinuities, and people at different points on the continuum are literally thinking in different ways.

This is what makes communication break down.

When David announces the outsourcing decision in an all-hands, he frames it in terms of strategic positioning and runway extension. Alex hears vague statements about "strategic partnerships" and wonders why nobody will just tell him what to build next. They're responding to the same decision, but their responses are qualitatively different.

Jaques observed this precisely:

"His subordinates experienced his decisions as cavalier because they thought they understood him. After all they speak the same language. But the president was in fact problem-solving at the next higher order of thinking, and because that was not articulated he seemed to be deciding things off the cuff."

I've written elsewhere about the expression gap: when strategic intent doesn't translate into execution-ready language. SST explains why this gap exists. Stratum V thinking doesn't automatically convert to Stratum I language. The gap doesn't close just because you hold more all-hands meetings.

When that translation doesn't happen, both sides get frustrated. David wonders why the team seems resistant to a decision that's obviously necessary. Alex wonders why leadership "keeps changing direction." Neither is wrong. They're operating at different altitudes, and the signal is getting lost in transit.

The Bridge Role

In the outsourcing scenario, Marcus and Priya are both doing translation work, each at their own stratum. Marcus converts Elena's vendor analysis into a concrete collaboration plan. Priya translates that plan into technical requirements: which APIs to expose, what documentation to write, how to structure the repositories.

This is the bridge role. It's not one person. It's a chain of translation across strata. The key is that someone at each level can operate across adjacent strata, understanding both the context above and the execution reality below.

When this chain is broken, the organization develops chronic communication problems that look like personality conflicts or bad management, but are actually structural gaps.

Putting It Into Practice

If you recognize these dynamics, the model gives you four lenses.

Diagnosis. When collaboration feels "off," check whether the roles involved are operating at different strata. Naming the mismatch transforms vague frustration into something you can discuss and address.

Planning. When assembling a team, check for coverage across strata and bridge roles between them. Watch for roles that span too many strata. The "player-coach" who must execute detailed technical work and set strategic direction often does neither well, not because of personal limitations, but because the cognitive demands conflict.

Hiring. Match candidates to the stratum the role actually requires. Stratum capacity isn't about intelligence. It's about the type of problem-solving the role demands, and whether the candidate has developed that capacity through experience.

Vendor selection. When outsourcing, you're drawing a line on the continuum. If the outsourced work is purely Stratum I/II execution, an external team can likely deliver it. If it requires Stratum III judgment about your product direction, the translation cost rises sharply. The key question: who will bridge between your internal strategy and the vendor's execution? Outsourcing doesn't remove strata from your organization. It moves them across an organizational boundary, where translation becomes harder by default.

I'll explore the outsourcing dimension in more depth in a future article.

Conclusion

Work changes in nature as you move along the strategy-execution continuum. It's not just that executives have "bigger" problems. They have different problems, requiring different cognitive mechanisms.

Understanding this helps explain persistent organizational friction:

• Why founders and engineers talk past each other
• Why some roles feel impossible to fill
• Why certain collaborations always feel harder than they should

The model also points toward solutions:

• Identify stratum mismatches instead of blaming individuals
• Build bridge roles into your organization
• Design roles that don't span too many strata

Jaques's work goes deeper than I've presented here, and his 1990 Harvard Business Review article "In Praise of Hierarchy" is a good starting point if you want to explore further. For now, the key insight is this: when communication breaks down across levels, measure the distance first. Some gaps require a bridge. Not because anyone is failing, but because the work itself demands translation.

Ivo Timmermans is the founder of Sparqpath, where he works as a fractional CTO and strategic technology advisor, helping companies navigate complex technical decisions.

Footnotes