Tempo 2.0 - Chapter 2: Strategy, tactics, and maneuver

 

This is the second draft chapter in Tempo 2.0.
Link to the previous chapter.


“We must be able to examine the world from a number of perspectives so that we can generate mental images or impressions that correspond to that world.”

— The Strategic Game of ? and ?, by Col. John Boyd

There are lots of books about business strategy. If you look closely at them, you will find that they are about many different things. Tempo 2.0 isn’t just about strategy, but strategy is an important part. Therefore, it is important to define what strategy means in this book. Strategic Navigation defines strategy likes this:

A strategy is the answer to the question: What is my ultimate objective, and what intermediate objectives do I need to achieve in order to achieve my ultimate objective?1

Thus, a strategy is a set of linked objectives, but that alone won’t get us far. If we want things to happen, we also need to do things in a purposeful manner. For that, we use tactics:

A tactic is the answer to the question: How do we achieve a strategic objective?

Strategy and tactics together allows us to make plans and execute them2.

Fig. 2-1: Strategic goals can be organized as hierarchies.

For example, one of your strategic intermediate objectives may be to deliver value earlier, so you can get paid sooner. There are many ways to do this. One tactic could be to reduce the amount of work done in each delivery cycle. Another tactic could be to do work in parallel, rather than sequentially. A third tactic could be to eliminate work that does not add value.

I decided to use this book itself to demonstrate how to deliver value early, in a manner that you as a reader can easily verify: I publish the first draft of each chapter on my blog, as I write them. You get value early, I get early feedback.

Of course, publishing all the material on my blog might undercut sales, but making a lot of money from book sales is not my goal. I am more interested in spreading useful knowledge, and I happen to like to write.

For those of you who believe there absolutely, positively, has to be a financial goal, yes, there is: So far, my books haven’t generated much money through sales. They are too specialized for that. However, they have contributed to me getting work I might otherwise have missed, so indirectly, they have been profitable.

A strategic goal and its corresponding tactics can be broken down into its own set of intermediate strategies and tactics. This book will teach you how to do that.

Sometimes the problem is that you don’t know what the problem is. All you know is that something hurts, and you want to hurt less, or something feels good, and you want more of it. You will learn how to get a handle on those situations too.

This book emphasizes merging strategic planning and implementation into a unified whole. Most strategy methods separate thinking and acting. That is a mistake I want to avoid, because just as the way you think will influence the way you act, the way you act will influence the way you think. Separate thinking and acting, and you will neither think, nor act, very well.

Strategic Navigation, the framework for thinking and doing in this book, is intended to support you all the way, with methods for how to think and how to do. What you think, and what you do, is up to you though.

The methods you will find in this book emphasize short planning and execution cycles, fast learning, and the ability to change quickly. In short: Agility!

You will learn visual planning, how to implement what you plan, how to make use of serendipitous events, and also how to tip the scale in your favor, so that serendipitous events occur a bit more often.

Strategic Navigation is a civilian adaptation of ideas from Maneuver Conflict, a military strategic framework created by Col. John Boyd, of the U.S. air force. His ideas have become very important both to military and business strategy. The ideas have also, over the past decade or so, become an increasingly important influence on agile software development, as well as the business agility movement.

In Strategic Navigation, the strategic framework, is combined with a powerful planning and problem solving tool, The Logical Thinking Process.

The original Thinking Process was developed by Dr. Eliyahu Goldratt, and is a part of the Theory Of Constraints. The version in this book is based on further developments of the method by Bill Dettmer, and to top it off, some ideas of my own.

The name Strategic Navigation is a homage to Bill Dettmer’s book of the same name. Over the years, my way of working has diverged a bit from what Bill Dettmer originally wrote, but if you read his book, which I recommend, you will recognize The Logical Thinking Process in Part C: Navigation.

Each organization is different, and that makes recipes for how to do things of limited value. Recipes will not fit your situation, and while trying to follow them might work, it can also lead to painful failure.

Your chances of success will improve if you understand how things work, why they work, when they work, and very importantly, when they don’t work. Thus, throughout the book, I will emphasize understanding, not just route doing. What you will need, is a good understanding of your organization, and the people in it, as a system, that is, a whole composed of interconnected parts.

Most of the time, how the parts connect is way more important than what the parts are, so we will spend a lot of effort on how to visualize and understand those connections.

A bunch of connected parts, that influence each other through their connections, is a system. The entire first part of this book is devoted to building a basic understanding of systems.

Takeaways

●  A strategy answers the question What is my ultimate objective, and what intermediate objectives do I need to achieve in order to achieve my ultimate objective?

●  A tactic is the answer to the question: How do we achieve a strategic objective?

●  Strategic objectives can be hierarchically organized.

●  There must be at least one tactic for each strategic objective.

●  Strategic planning and execution must be an organic whole! Split thinking and acting up, and you will neither think, nor act, very well.

●  Your chances of success will improve if you understand how things work, why they work, when they work, and very importantly, when they don’t work.

●         In a system, how the parts connect is way more important than what the parts are.

●         Your organization is a system.


1 In the first edition of Tempo, strategy was defined as “the means and methods required to fulfill the conditions necessary to achieve the ultimate goal of a system”. However, this definition conflates strategy and tactics. It is better to separate the two.

2 The definitions of strategy and tactics used here borrows heavily from the Theory of Constraints. It is one of the few definitions of business strategy and tactics that is consistent with strategy and tactics in other contexts, such as war, game theory, and games.

Comments

Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che...
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so...
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta...
Read more