Strategy vs Tactics

Strategy is about the overarching problem that needs to be solved, the direction that the ship needs to travel in, the top level objectives which are important to the business. It’s about the “why” and not so much the “how”. It’s a problem defined within the domain and language of the business not necessarily of the technology. Often discussions about technology only even become relevant once the strategy has been refined and clarified.

In other words; Strategy should always come first.

The realm of tactics on the other hand is about software frameworks, programming languages, developer skill-sets, user on-boarding, product teams, roll-out plans, deployment processes, agile vs waterfall, user interfaces, design and branding…

Tactics are fun and exciting!

They’re the primary concern of technologists, developers and technology proponents within an organisation. I’m one of those people. I love talking tactics. It’s easy to have opinions on them. And because it’s largely the domain of technology experts, the (sometimes) less technical business people and project stakeholders can quickly end up delegating and deferring decision making about projects to the technical experts as soon as this decision making gets into this realm of tactics. But if this happens too soon in a project, then there is a risk that the technology concerns start to dominate and lead the direction of the project more than the business strategy does.

But the strategy is after all, The. Whole. Point.

Tactics are inherently tangible and actionable. Strategy is about reflection and high level course setting. It's often a bit more obscure and harder to nail down.

In other words, its sometimes just easier and frankly, more fun, to talk tactics then strategy. And because tactics are closer to the action, this can deceptively make everyone feel like progress is being made.

But to bastardise paraphrase Stephen Covey, your discussion about whether to use a ladder, a rope, or scaffolding may be academic when you’re trying to scale the wrong wall.

There is a risk that the millions of tactical technological related decisions can quickly flood and overrun discussion and planning about a project, crowding out important discussion, clarification and understanding of the strategy.

As a practical example, a tactical decision like which front-end Javascript framework to use for a web app, should not just be made inside a bubble of purely technical thinking. Such a decision can be led sometimes by a desire for technical excellence or influenced by current trends, but when you factor the business objective into this decision making, it may, for example, point you towards picking a much simpler framework to start with - if "speed to market" or solving a problem quickly is more important initially than picking the more technically advanced/complex option for purely technical or longer-term reasons.

Technologists may worry about technical debt, but a project has to survive long enough in order to be impacted by technical debt at all! So early decisions should err towards optimising for "time until initial problem solved". Once the project starts to deliver some value, it's justifiable to then put a little more focus on longer-term decision making and measured reduction/prevention of technical debt. But the project has to make it this far for this to be relevant.

A close relation to the problem I'm describing is Parkinson's law of triviality though in the software development world it's often called Bike Shedding. This describes the tendency of teams and stakeholders to get drawn into endless discussions about relatively unimportant trivialities of a project (eg. what colour to paint a new bike shed), simply because it's easier to have opinions about these small details, compared to the larger, more important issues which require a lot more effort and expertise.

So how can we tackle this problem?

For business leaders, I think it’s important to ensure two things: 1. that there is a clear consensus on the strategy - the why - of a technology project, which everyone involved at the business level really understands, and 2. that this is documented and clearly communicated down the line to all members of the project teams involved.

As much as it’s the responsibility of business leaders and project stakeholders to be clear about (and communicate) the strategy, it’s the responsibility of the project teams to make sure that this strategy is always kept front and centre when making tactical decisions about the project. And it’s the responsibility of everyone involved to keep returning to this strategy constantly throughout the project, to use it as a guiding light when making tactical decisions and course corrections as the project progresses.

Bridging the gap between strategy and tactics can be made easier if you have one or more people on the team who can speak in the languages of both business strategy and some technical detail - often this might be an experienced product/project manager or senior tech lead. Such people can be helpful in translating strategy into language which can inform the tactical decisions made by the technical team. But the smaller the business, the more direct the communication may be between the business leaders or project stakeholders and the tacticians - and that very direct communication can sometimes make up for the lack of someone who can sit in the middle and mediate. But this latter approach doesn't scale well beyond extremely small teams.

It's a universal problem

This is not a challenge purely restricted to technology projects. There is a vast amount of material, models, frameworks, techniques and even whole consulting companies whose principle aim is to help set high level strategy and ensure that this is propagated down through all layers of an organisation.

In my experience though, I think it's a particular challenge with tech projects, because technology and software teams can sometimes seem like opaque, enigmatic "black boxes" within an organisation - understood by few outside these specialised groups. This leaves ample room for miscommunication and crossed wires between these teams and the broader business. I also think that this is why agile/scrum methodologies for software development - or to use less loaded terminology; "short focused iteration cycles" - can be extremely effective. Aside from the advantages of scoping small chunks of work for a software team to focus on at a time and being able to react to the realtime feedback from the business and its customers, this short iteration cycle approach also provides a regular opportunity to reconnect to the top-level goals and objectives of the project on a regular basis. With a more traditional "waterfall" method of managing such a project, the strategic part of this planning is often front-loaded at the beginning of the project - and its for this and many other reasons that waterfall projects have much more chance of drifting off course over time.

I think that the challenge of keeping a project driven by the top-level strategy rather than the minutiae of tactical details might also be one reason why a lot of public sector IT - and possibly infrastructure - projects can go wrong and long. The strategy is always clear right at the start, but then one or more contractors - who are disconnected from that strategy and tend to specialise in the tactics of their respective domains - are brought in to deliver the project. Unless there is repeated anchoring of the project teams back to the original core strategy and objectives of the project, decisions can start to be made for the wrong reasons and the technical details and demands of the project can just fully take over. These decisions can compound over time - creating "lock-in" to a particular technical approach for example, which eventually reduces the ability to steer the project back towards its core goals (which includes time and budget) even if there is an attempt to do so.

Summary

So, to summarise, there is a risk that the technical details of highly technical projects quickly take over the project direction and the "tail can start to wag the dog". There is no blame being apportioned here - for leaders and stakeholders, the natural inclination is to trust the project team to run with things, and for the project team, their primary concerns are understandably rooted in the technical domain.

I think the key thing is for everyone just to try and recognise these tendencies - on both sides - and to remember that projects exist to solve one or more hopefully-well-defined business problems. Solving those business problems is the entire reason for the project's existence, so every decision at a tactical level should be made with that higher strategic objective in mind.