Why This Matters for Outsourcing
This framework matters because different positions on the continuum have different implications for outsourcing success.
Activities on the strategic end typically require:
- Deep understanding of your business model and competitive position
- Long-term commitment to your company's success
- Ability to make judgment calls with incomplete information
- Alignment with company culture and values
Activities on the execution end typically require:
- Specific technical or domain expertise
- Capacity and consistency in execution
- Clear processes and quality standards
- Ability to work from well-defined requirements
When you're considering outsourcing, you're not making one decision—you're making multiple decisions about where to draw boundaries across these different functions. A company might reasonably choose to outsource detailed development tasks while keeping architecture in-house. Or outsource UX design execution while maintaining brand strategy internally. Or the reverse of either.
Using the Model
This model provides a practical framework for outsourcing conversations:
Clarifying scope. Instead of vague requests for "development help," you can specify exactly which activities you're looking to outsource. "We need support with development sprints and story implementation, but we'll handle architecture and planning internally" is much clearer than "we need developers."
Evaluating vendors. Different vendors excel at different positions on this continuum. Some are excellent at taking detailed specifications and delivering quality execution. Others thrive in environments where they're involved in design decisions and technical planning. Understanding where you need help makes it easier to assess fit.
Identifying gaps. If you realize you need to outsource activities on the strategic end but lack the internal capability to manage that effectively, that's a signal you might need a different type of engagement first—perhaps bringing in advisory support to build that capability.
Communicating internally. When discussing outsourcing with stakeholders, this framework helps explain why you're not simply "hiring developers" but rather making specific decisions about which activities benefit from external support.
What This Model Doesn't Address
This framework is a starting point for thinking about outsourcing decisions, not a complete guide to making them. It doesn't address important questions like:
- How do you assess whether a vendor can actually deliver at their claimed position on the spectrum?
- What organizational structures and processes support different outsourcing arrangements?
- How do you maintain quality and alignment when work is distributed?
- What does effective collaboration look like in practice?
These questions deserve their own exploration. For now, my goal is to provide a mental model that moves beyond binary thinking about outsourcing and creates a shared language for discussing these decisions.
What's next: where do you need help?
If you're considering outsourcing—or if you're already working with external teams and questioning whether the arrangement is optimal—I encourage you to map your needs across these functions. Where do you have strong internal capability? Where are you stretched thin? Which activities truly require your business context, and which would benefit from specialized external expertise?
The answers shape everything that follows: who you hire, how you structure the relationship, and what success looks like.
I'm continuing to develop this framework and would welcome your perspective. Does this mapping match your experience? What activities did I miss? Where does your organization find the most friction in these decisions? I'd be interested to hear your thoughts.