Vision, strategy, plans and tactics

This one’s kinda tangled, not least because it starts off from a follow-up that I never saw, to my previous post ‘Enterprise Architecture and Strategy‘.

(It’s also long, as usual… 🙁 – click on the ‘Read more…’ link for the rest.)

The response came via Twitter from corporate-strategist and author Chris Potts, who unfortunately I hadn’t been following there, and due to a Twitter ‘feature’ even posts addressed to me from him never showed up. So I was kind of left in the dark when various other colleagues such as Richard Veryard and Leo de Sousa sent off a stream of related ‘tweets’ in my direction:

• richardveryard: @chrisdpotts @tetradian Isn’t it the same difference as between driving and navigating? Because you can’t always stop to look at the map.
• tetradian: @richardveryard apols, what’s the context for “difference between driving and navigating”? can’t see what you’re replying to…
• leodesousa: RT @chrisdpotts: @tetradian Do you see ‘strategy’
• tetradian: @leodesousa @chrisdpotts apols, I’m obviously missing something – is there a discussion I should be following here?
• leodesousa: @chrisdpotts asked you if you thought there was a difference between strategy & strat planning?

At this point things finally started to make sense for me, so I gave a tweet-sized summary of my view on the relationship between ‘strategy’ and ‘strategy-plan’:

• tetradian: @leodesousa @chrisdpotts strategy planning (SP) is a subset of strategy (ST): SP assumes the possibility of a plan, ST doesn’t // Chris’ own example: “the IT strategy is to not have a strategy” [i.e. no SP] – eg. emergence becomes the ‘plan’

Richard Veryard came back late that evening with a summary that started off a veritable barrage of back-and-forth tweets, which I hope I’ve arranged below in a meaningful sequence (also minus name cross-references unless needed for sense):

• richardveryard: I was responding to @chrisdpotts response to your blogpost. ‘strategy’ is like driving, ‘strategic planning’ is like navigating.
• tetradian: “strategy is like driving, strategic planning is like navigating” – strategy is more like ‘deciding where to go’, surely?
• MartinHowitt: realised strategy=driving. Deciding where 2 go=strategic planning. u may not end up where you planned! #Mintzberg
• tetradian: “strategy=driving. Deciding where 2 go=strategic planning” – disagree: plan comes _after_ vision, not before!
• oscarberg: vision (destination) comes first, then strategy (directions). Strategy is a plan (of action) // the execution of actions as defined in the strategy (plan) = driving
• seabird20: driving how abt “Wanting to visit grandma weekly”= strat plan” “Figuring how to get to grandma = strategy” “driving = execution”
• tetradian: vision/strategy/plan etc – are we just disagreeing about terminology here? 🙂
• oscarberg: Seems as a terminology confusion. If strategy is not a plan, then what is it?
• MartinHowitt: yes term confusion! Mintzberg defines Realised Strategy as outcome of planned+ unplanned behaviour
• tetradian: to me, strategy looks outward (conversation w enterprise), strategy-plan looks inward to execution
• oscarberg: strategy answers “How?”. The plan is a key component, but also guiding principles etc
• adrianrcampbell: I agree that Strategy is deciding where to go, then #entarch is the planning, map reading and navigating etc.
• richardveryard: I don’t see strategy as a plan, often more like situated action (Lucy Suchman). // I think guiding principles are over-rated, sometimes little more than vague maxims and warm slogans. // What’s Wrong with Principles?: Lots of people in the SOA / EA world think that principles are very important. So i… http://bit.ly/aBDgpy
• oscarberg: guiding principles help a lot when implementing ECM & collaboration strategies (my experience) // Blogged: Examples of guiding principles as components in an ECM strategy http://goo.gl/fb/vLNm
• malcolmmlowe: @chrisdpotts @pauljansen @richardveryard Principles have motivation and implications. Rules are created from the implications

At this point Chris Potts kindly sent an email which helped to sort out where everything had started:

Your blog on “EA and Strategy” triggered my original question, as the question was about strategic planning but your answer was about strategy. I was just wondering where you saw the differences between these, if any, as I am used to treating them as different (albeit related) disciplines, along the lines of Mintzberg’s “Crafting Strategy”.

This gave enough of an anchor for me to give an answer that could be more detailed than in a single 140-character tweet:

To me, ‘strategy planning’ is more of a follow-on from ‘strategic conversations’ and the like. Using the terms from my post, the distinction would be that strategy faces outward to the enterprise (i.e. beyond the organisation) whereas strategy-planning faces inward to the organisation. As Michael Porter and others (and you too, in FruITion) have pointed out, much so-called ‘strategy’ isn’t in any way worthy of the name: it’s actually very low-grade strategy-planning that grabs hold of a few really crass assumptions such as “shareholder-return = last year + 10%; costs = last year – 10%”, and builds a plan based on those assumptions, without any reference to the broader enterprise at all. In those examples, it’s isn’t even worthy of the term ‘strategy-plan’: it’s barely even ‘tactics-plan’, which in effect is the next level down (i.e. towards concrete reality).

Architecture is somewhat orthogonal to all of this. My sense of architecture in general, and EA especially, is that it is a custodian of a body-of-knowledge about enterprise structure and purpose (‘enterprise’ here extending at least two or three steps beyond the nominal boundaries of the organisation), combined with an artist’s sensibility about how all those factors interact. But as with any good building-architect or civil-architect etc, EA should not of itself aim to make strategic decisions on behalf of the organisation: instead, it should assist the client (i.e. the strategy-body, in this case) to make the respective decisions, and advise on the consequences of each option. The nearest that the architect should provide to ‘strategic decisions’ as such is a certain amount of personal ‘taste’ or ‘flavour’ in the ways that they guide the client towards a decision (hence each item of work by a given architect is usually identifiable as ‘by’ that architect – even though the underlying strategic decisions may be very different in each case).

EA tends to be lumbered with strategic decisions that it probably shouldn’t make. My opinion that EA shouldn’t make those decisions is mainly because the two disciplines require somewhat different mindsets: the EA is probably competent to make them, given the EA knowledge-base, but the EA needs to be as impartial as possible, whereas the strategist shouldn’t – strategy should always keep the organisation itself at centre-stage of attention. (There’s actually a closer mapping between business-architecture and strategy than there is with enterprise-architecture – in fact EA should often end up as the ‘devil’s advocate’ on behalf of the ‘enterprise-beyond-the-organisation’, arguing against the organisation’s strategy because it doesn’t align well with the drivers of that broader enterprise.) To use your terms, the only ‘architect’ who should be making enterprise-scope strategic decisions is the CEO as ‘Chief Enterprise Architect’: every other architect is at most an advisor to strategy, not a strategic decision-maker – unless specifically assigned and authorised to that role, of course.

Chris emailed back a detailed response on three different themes, first on crafting strategy:

Mintzberg’s work of this title was an HBR article, not a book.  http://hbr.org/product/crafting-strategy/an/87407-PDF-ENG .  He wrote it over 20 years ago and as far as I can tell really upset the strategic planning community, who thought they did strategy.  He asked the reader to ‘imagine someone planning strategy’ and characterised it as ‘orderly thinking…formulating a course of action that someone else will implement on schedule’.  He then asks us to imagine someone ‘crafting’ strategy – characterised by ‘…involvement, a feeling of intimacy and harmony with the materials at hand, developed through long experience and commitment.’  His thesis was that ‘the crafting image better captures the process by which effective strategies come to be’.  His observation that strategy is fundamentally a pattern of behaviour, is the definition I have chosen to work with (therefore a Corporate Strategy for IT that is ‘not to have one’ is inferring a deliberate pattern of behaviour rather than the absence of a pattern –  and why it is therefore different from having no strategy for IT).

To which thesis – ‘strategy as a pattern of behaviour’ – I can only concur. (Chris’s distinction between “a strategy not to have a strategy” and “to have no strategy” is subtle but important.) The classic ‘strategy as plan’ metaphor completely misses the point, even though that’s pretty much all that anyone had been doing up to that period (and, all too often still do).

Chris then commented about the direction in which strategy faces:

I think you’re absolutely right to say that a strategy needs to ‘face’ the subject it is primarily about, but I don’t agree it has to be ‘outwards’.  So a Corporate Strategy For IT ‘faces’ IT from the perspective of being a corporation.  That is very different from an IT strategy which tends to face the corporation from the perspective of being IT.  Similarly, a Corporate Strategy for EA ‘faces’ EA.  The principle seems to be that to have the best strategy ‘for’ something means taking a detached view of it (outside-in, to use your metaphor) even if – indeed especially if – you are actually the main proponent of that subject in your corporation.  So the head of EA for a corporation must be leading a strategy (a pattern of behaviour), that faces EA and guides it to make the most valuable contribution possible.  That is very different from many heads of EA who trying to lead a corporate strategy for EA but are being ‘EA facing the corporation’ rather than ‘the corporation facing EA’.  The strategy question they are trying to address is ‘how can we truly get the corporation to behave in a way that implements the EA design’.  A better question would be ‘how can we, the corporation, truly enhance our value because formalised EA exists?’

I sort-of agree with the point about “strategy ‘for’ something”, especially in terms of the commonsense view of it. But actually it’s the wrong way round, because although the group ‘above’ would request the strategy, the strategy itself does need to be developed by people who have the requisite domain-specific knowledge – which would usually not be the people asking ‘for’ the strategy. The ‘need for strategy’ request goes downward, the actual strategy-development looks upward – rather like the relationship between Systems-3/4/5 and System-1 in the Viable System Model.

In the EA context, one point I’ve been pushing for a while is that EA is a generalist architecture-discipline which exists to link together all the other domain-specific architectures (business-architecture, IT-architecture, process-architecture, capabilities-architecture, security-architecture etc). In that sense, using Chris’ model above, EA would ask for a strategy in each of those architecture-domains, using the whole-of-enterprise view to provide context for each of those domains, but would not create that domain-strategy itself. Strategically, EA looks upward/outward to the extended-enterprise; its typical strategic-plan is to ask for and integrate the various domain-strategies; and tactically will assist in promulgating the identified domain-specific strategic-drivers across the enterprise. (More on that in a moment.)

Chris’ last set of comments were on EA accountabilities:

A pattern of behaviour in some organisations is to avoid accountability.  When this is true, some people will manage to avoid it altogether while others seem to be able to avoid the thing they should be accountable for but end up being apparently accountable for something else instead.  For example, Enterprise Architects are not currently accountable for the ultimate success of the enterprise designs they produce, but if they are to be valued as fully-fledged professional architects then one day they will need to be.  Meanwhile, I agree many do seem to be taking on strategic decisions and actions that they are not accountable for.

If we put aside the future fully-professionalised architect role for now, then I believe the primary accountability of a corporation’s Enterprise Architects today is simply to make sure they successfully enhance the corporation’s business outcomes (both strategic and operational) through their influence over others.  That means they do have to make strategic decisions that they are accountable for, but these decisions are specifically about how the corporation gets the most value out of the specialist subject area they represent.

A good question to ask an Enterprise Architect is ‘what is the corporate strategy for Enterprise Architecture?’, to see which way that strategy appears to be facing, and what it means the Enterprise Architect’s true accountabilities are.

I agree on the need for accountability (and likewise note the tendency to shy away from it!). What I’m still not happy about is inciting architects to do strategy, because it really is not their job at all: the architecture role is one of strategy-like decision-support, but not strategic decision-making – another of these subtle-but-important distinctions. That others shy away from making high-level strategic decisions should not be an excuse for architects to leap into the breach, unless they really do know what they’re jumping into – which for most IT-architects doing so-called ‘enterprise’-architecture is probably not the case!

Before finishing this, I’d better summarise what I mean by various key terms:

• Enterprise: a mutual shared commitment – “to collaborate and share resources towards a common mission or set of related missions” – bounded and defined by a implied or explicit ‘vision‘ (see ‘What is an enterprise?‘)
• Organisation: a collective entity – such as a corporation, a government agency, a sports-club – bounded by explicit rules and/or laws
• Vision: a brief summary of the unchanging ‘guiding star’ for an enterprise, shared by all participants in that enterprise – usually expressed in emotive terms to underpin the shared commitment to that vision
• Role: a segment or cluster of activities within a vision, undertaken by an organisation or other individual or collective participant in that vision – usually but not always explicitly declared – which identify what contribution the participant will make towards the vision of the enterprise, and what it will do or not do (the ‘not-do’ thus identifying spaces for collaboration with other participants – i.e. other roles – within the vision)
• Strategy: a participant’s current ‘outward-facing’ choices for its present-to-future relationships with the enterprise and with other participants in the enterprise
• Strategy-plan: an ‘inward-facing’ breakdown of actions to enact the current strategic choices, usually structured in the form of new or revised missions (capabilities) to implement, and explicit objectives or goals – provides the initial stage of transcription from abstract strategy to implementable tactics to real-time operations

Hope this makes some degree of sense, anyway – and apologies again for running on so long about this!