Strategy-to-Execution continuum in software development

Software development activities exist along a continuum from strategic to execution. Understanding where activities fall in this continuum helps guide decisions in domains like hiring, team composition, team collaboration, and outsourcing. In this article, we discuss a model that enables you to map activities, and make better-informed decisions.

Why organizational structure matters: Conway's Law

Conway's law states that software architectures mirror organizational structure¹. For most companies I work with, the most important objective is to serve customers. Software, and hence software architecture, are a way to achieve this objective. So therefore, if we want to achieve a particular architecture, we need to be intentional about the organization design.

But Conway's Law doesn't tell you how to structure your organization². When companies start out, roles are distributed across whoever is available. As teams mature or grow, roles become more specialized.

However, when you start splitting responsibilities and some of the roles are no longer fully committed to one project, problems start manifesting themselves. An example is: a product owner who was not assigned to this project full-time. Or: an expert who is only available a couple of hours a week. Then, suddenly, you start introducing all kinds of new failure points into this process. The question becomes: which activities can tolerate this distribution, and which require tight integration?

Simple models don't provide a framework for making these decisions.

What's been done: Existing models

Most folks will be familiar with the sequence of processes called the Software Development Life Cycle. There are several models describing this. One example is the Agile model, where you have a core process of iterating on the software engineering, and then on the left-hand side, you've got product definition, and on the right-hand side, you've got the release process.

And in my experience as an engineering manager, a very similar mental model is when working across different software development teams. Team Topologies³ actually goes into a fair amount of detail on this.

What these models don't address is the nature of the work itself. They tell us what activities happen (SDLC), or how teams should interact (Team Topologies), but not which activities require strategic thinking versus tactical execution. That distinction is critical for organizational decisions.

What's missing: The strategy-to-execution continuum

In order to reason about this and related problems, we need a model to break down software development activities. These activities exist along a continuum from strategic to execution. At one end, activities require deep business context, long-term thinking, and alignment with company vision. At the other end, activities require specific execution skills, attention to detail, and consistent delivery. The Outsourcing Handbook⁴ acknowledges this, yet the authors represent this dimension as a binary choice at the level of the entire company: Core versus Auxiliary.

Understanding where different activities fall on this spectrum is crucial for making informed decisions.

Using the model: mapping activities

Consider the following examples of major functions involved in software development:

• Product Management spans from product vision (highly strategic) through product definition, features, and roadmap, down to requirements and detailed specifications (increasingly execution).
• Development ranges from architecture decisions (strategic) through design documentation and development planning, down to sprint execution, story implementation, and individual development tasks (execution).
• UX/UI Design moves from brand guidelines and wireframes (strategic) to detailed UI design work (execution).
• Quality Assurance progresses from testing strategy and automation planning through test plans and QA planning, down to sprint-level QA and detailed test steps (execution).

Each of these functions contains activities that sit at different positions on the strategic-to-execution continuum. The leftmost activities require the most business context and long-term thinking. The rightmost activities require the most detailed execution and consistency.

Where does your organization experience friction?

This continuum provides a lens for examining organizational decisions. This includes team structure, hiring priorities, and vendor partnerships. The key insight is recognizing that software development isn't monolithic or even bimodal. It's a collection of activities with fundamentally different characteristics.

Some of the common friction points that I'm seeing:

• Mismatched expectations when internal teams and external partners are not aligned on where responsibilities fall on this continuum.
• Capability gaps when strategic activities get pushed to executors.
• Communication breakdown when stakeholders assume they're discussing the same type of work, but one is thinking strategically while the other is in execution mode.

Where does your organization struggle? Are you unclear about which activities require deep business context vs. specialized execution? Do your team boundaries reflect the required software architecture?

In future articles, I will explore specific applications of this framework. Stay tuned.

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