Adapting to change is a challenge in every industry but particularly in software-related areas because it seems every rule and practice is thrown out every five years or so. I’ve watched peers struggle to adapt when the best practices that got them where they are no longer apply - they feel like their skills and knowledge are obsolete and they’ll have to start over or give up. Developers that get promoted to management often try to keep one foot in both worlds, fearful of being left behind by the next upheaval.
The great news is that if you cut through the noise, more (or even most!) of what you’ve learned will still apply during the next wave if you structure your thinking.
As you learn an industry, you’re taking in concepts that can be organized into three categories: Principles, Strategies, and Tactics. The principles you learn lead to a set of strategies and each strategy is executed through tactics. Changes in any industry primarily affect how you pick tactics, not the strategies they achieve or the principles that they satisfy.
For a comparison of where something fits, consider:
| Principles | Strategies | Tactics |
|---|---|---|
| Guiding Value or Purpose | What you need to achieve | How you’ll achieve it |
| Fundamental | Industry-Wide | Situational |
| Constant for a career | Constant for years | Fluid |
Most change affects the specific tactics we use. Changes to strategies can generally be seen coming a long way off - they come out of fundamental shifts in the inputs to the problem, like changes in costs or customer demographics.
Example: Agile Software Development
In the mid-2000s, most software teams shifted from traditional software development practices (broadly lumped into the “Waterfall” camp) to one or more flavor of “Agile” software development. From the outside, this appears a fundamental change in how development teams and the organizations that contain them produce software. Let’s break it down into Principles, Strategies, and Tactics.
Traditional Software Development
| Principles | Strategies | Tactics |
|---|---|---|
| Deliver on a Schedule | Prevent Outside Change | Up-front, agreed requirements |
| Strong change control | ||
| Eliminate Unknowns Early | Design up front | |
| Deliver on a Budget | Eliminate Rework | Large-scale team code reviews |
| Test at the end | ||
| Strong change control |
Agile Software Development
Now take the same table but for contemporary teams using an Agile process:
| Principles | Strategies | Tactics |
|---|---|---|
| Deliver on a Schedule | Manage Outside Change | Incorporate user experts into dev team |
| Shorten development timelines | ||
| Eliminate Unknowns Early | Continuous Delivery | |
| Deliver on a Budget | Incremental Delivery | Develop and Deliver completed blocks of functionality independently |
| Demo frequently to end users |
You’ll notice the principles haven’t changed, the strategies have a bit (but still connect) and the tactics are completely different. In short, development teams are taking advantage of the advances in software development tools to adopt new tactics based on the most important strategies needed to deliver the same goals.
The same hierarchy of thinking applies to Agile software development practices.
| Principles | Strategies | Tactics |
|---|---|---|
| Lean Process Management | Agile Software Development | Kanban |
| Scrum |
Making Principles & Strategies Work for You
When you’re confronted with the need to change how you, your team, or your company work fall back on this model to understand what the scope of the change is - Perhaps it’s just a different tactic (like adopting a new application framework for your next app) or a modification of a strategy, not a complete upheaval of your experience. Knowing what level the change impacts lets you know what to keep and what to re-evaluate.
As your career progresses and you work your way up through organizations, a common challenge is understanding where to focus your time. As an individual contributor, you spend most of your time at the tactics level. When you start leading teams of contributors (Whether leading the people or managing the work) you want to understand the strategies that determined the tactics your team is using to achieve results. Let’s say this goes well and you are promoted to a Product Manager role, leading teams of people to deliver. Now you’re defining the strategies for how your products work, how you market them, and delegating to your teams the tactics they use to achieve those strategies.
I’ve done both CTO and COO roles. Shifting gears between them is mostly a function of a technical emphasis vs. a business emphasis. In either role, I spend a lot of time mentoring leaders, at multiple levels of the organization. This same perspective has served me well in those conversations.
Orienting your time for the Organization
Working in the business domain of your organization the boundaries aren’t hard and fast, but as a first approach when allocating your time consider:
- CEO: Defines Principles
- COO: Evaluates principles to define Strategies
- VP/Directors: Execute strategies
- Managers: Define Tactics
- Individual Contributors: Execute Tactics
Orienting your time for Technology
If you’re a CTO then you are responsible for overall technology and integrating that into the business domain.
- CEO: Defines Principles
- CTO: Evaluates principles to define Strategies
- VP/Directors: Execute strategies
- Managers: Define Tactics
- Individual Contributors: Execute Tactics
