Power-issues in EA – tread carefully…

Continuing with the series on power and politics in enterprise-architecture, a brief summary-so-far, some practical suggestions on modelling of power-issues, and a very important warning…

The quick summary is as follows:

• the practice of enterprise-architecture is often ‘relentlessly political’
• one of the key practical concerns of enterprise-architecture is efficiency and effectiveness across the enterprise
• one of the key factors and metrics in efficiency and effectiveness is power, in the broadest sense of the term
• to keep things simple and symmetrical, we can use a flat physics-based definition of power as ‘the ability to do work‘, in the broadest sense of ‘work’
• we can summarise dysfunctional application of ‘power’ – power that acts against efficiency and effectiveness – as derived from a social-definition that power is ‘the ability to avoid work’
• by contrasting these two definitions, and how they play out across the enterprise, we can derive clear indications of how power-problems in the enterprise will impact on availability of ‘ability to do work, and hence on efficiency and effectiveness of the enterprise
• the only way to maximise efficiency and effective across the enterprise is to ensure that ‘everybody wins’

So far, so straightforward: in many ways it’s just a routine modelling task, much like many other aspects of enterprise-architecture. But the danger for enterprise-architects – and why it merits a special and specific warning – comes back to that first bullet-point above: the practice of enterprise-architecture is often ‘relentlessly political’. We ignore this fact at our peril…

The point is illustrated well in a Tweet by Martin Howitt, in response to the previous post on this:

RT @MartinHowitt: RT @tetradian Power and politics in #entarch http://bit.ly/Ra2C9o < promising. But assumes we want win-win! Machiavelli might disagree

In terms of the blunt realism of everyday organisational politics, Martin is entirely right – which can make this type of analysis very dangerous for us if we’re not careful about how we do it, and especially in terms of how we describe it in the architecture.

Yet from an architectural perspective, what I’d said in the last bullet-above is also entirely true: the effort of making someone/something else ‘lose’ has to come from somewhere – and even the most basic of physics would insist that every scrap of energy expended in doing so must be subtracted from the overall effectiveness of the system. Which means that power-issues are an architectural-issue that at some point we must address, because they’re factors that do impact on our remit and responsibility to identify and mitigate enterprise risk and to enhance enterprise-effectiveness.

Which puts us in a bit of a quandary: the classic “damned if we don’t, damned if we do”…

To which the only practical answer is: do it anyway, but be careful to do it ‘by stealth’.

Do it it as an architecture exercise – and a very necessary architecture-exercise at that. But do it in a way that’s non-threatening, non-challenging, and mostly held within architecture itself. (We’ll come back later about how to use the outcomes of this exercise.)

To model power-issues in enterprise-architectures, the simplest method is to use the contrast between those two definitions – power as the ability to do work, versus the perceived ability to avoid work – as a guide for assessment of interactions in the context.

Before we can identify what work is either being done or avoided in a context, and hence the effectiveness of that aspect of the enterprise, we first need a clear understanding of ‘work’. For this I generally use the tetradian-dimensions:

• physical dimension: moving things, making things, lifting things, dismantling things – anything to do with tangible ‘things’
• mental (‘virtual’) dimension: solving a problem, calculating a solution, compare-and-contrast – anything to do with ideas or abstracts
• relational dimension: creating, building and maintaining connections between people – anything to do with person-to-person relations
• aspirational dimension: creating a sense of meaning and purpose, a sense of self and of relation with that which is greater than self – anything to do with aim, intent, motivation and other person-to-abstract relations

Most real-world work is a dynamic composite of any or all of those dimensions – and we do need to note how those dimensions interweave with each other in work, because power-problems most often arise when that interweaving is blocked, or when one or more of those dimensions is ignored in a context. For example, Taylorism assumes a rigid split between physical-dimension work (assigned exclusively to ‘the workers’) and mental-dimension work (assigned exclusively to ‘the managers’), uses predefined hierarchy as a means to avoid relational-dimension work, and all but explicitly ignores the aspirational dimension (motivation, or the purpose of work): hence it should be no surprise that whilst Taylorist-type structures can seem ‘efficient’ on the surface, they’re often very ineffective overall, and are notorious for deeply-entrenched and seemingly-irresolvable power-problems.

[For other notes on how this plays out in organisations and in society in general, see the ‘Manifesto’ reference-sheet from my book ‘Power and response-ability: the human side of systems‘.]

Note that in some ways this is nothing new: for example, thirty years ago, several of Deming’s ‘14 Points‘ explicitly addressed systemic power-problems in organisational work-cultures. What is different here is that this gives us a systematic approach to the issues that centres around work and effectiveness of the outcomes of that work – enabling us to sidestep ‘power’ itself, and tackle the issues from a much safer direction.

For the assessment itself, first select and identify some context within the enterprise, and then ask:

• What are the desired outcomes in this context? What work needs to be done, and by whom, to identify those outcomes, and to create and maintain engagement of all parties in those outcomes?
• What is the work to be done within this context? What are the dimensions of that work, and their dynamics over time?
• Who or what will do this work? From where and in what forms will the respective ‘ability do work’ arise? In what ways is this power-as-ability-to-do-work applied within the work itself?
• If different people or different entities do different parts of the work, how do the different aspects of work intersect? What work is needed to guide and coordinate each aspect of the work in relation to other aspects, and to keep on track to the intended outcomes and to overall enterprise-purpose? Who or what is responsible for that guidance-work?
• Is any work being avoided in this context? If so, what is the work, and the dimensions of that work, that’s being avoided? By what or whom is it avoided, and in what roles?
• In what ways can and must the work be shared, in various forms of collaboration? In what ways and forms is there avoidance of sharing of necessarily-mutual work?
• In what ways and forms are there attempts to ‘export’ inherently-personal work to others?

That last pair of questions are perhaps the real key to power-problems in organisations and elsewhere, yet perhaps also the hardest to understand and to apply in practice. These especially relate to relational-work and aspirational-work – crucial forms of work that are still barely even acknowledged as such in most current concepts of organisational and enterprise architectures.

That work is real, and crucially important in the enterprise. For example, if we consider current research on motivation and productivity, such as described in Daniel Pink’s Drive, then it seems somewhere between probable and proven that maximum enterprise-effectiveness is highly dependent upon aspirational-work – such as autonomy, mastery and purpose, to use Pink’s terms. Yet aspirational-work is always personal, and can only be done by each individual person – it’s a type of work that cannot be ‘exported’ to others, no matter how much we might want to do so.

Much the same applies to relational-work: almost all aspects of business are dependent somewhere upon person-to-person relations, and it takes real work to create and maintain those relationships. Yet those relationships cannot be transferred as such to others: they exist only between individuals, and are the exclusive responsibility of those respective individuals – a responsibility that cannot be ‘exported’ to others.

In essence, that’s the metaphoric ‘physics’ of those types of work, and – exactly as with everyday physics – if we try to ignore or override the realities and constraints of that ‘physics’, things tend not to work very well…

What we can do in architectures is provide conditions under which those kinds of work can happen, and happen well, in terms both of collective and individual outcomes. As mentioned in the previous post, the only way that works well in the longer term is ‘win/win’: every other alternative – including so-called ‘win/lose’ – will inevitably lead to an outcome in which, overall, everyone will lose.

However, as Martin Howitt puts it in his note above, “Machiavelli might disagree”. And Machiavelli would not be alone: ‘win/lose’ is an extremely popular idea, and its usage runs rampant throughout many organisations. It’s even required in some organisational cultures, such as ‘up or out’, or ‘fire the lowest 10% each year’. The catch is that it doesn’t actually work: it’s little better than a personal and/or institutionalised attempt to ‘export’ relational and/or aspirational work to others, of which the only likely outcome is severe damage to motivation and morale all round. All it does is reduce the ‘ability to do work’, not only in the person to whom the work is believed to be ‘exported’, but also of the person attempting the ‘export’. The latter applies because they’re putting significant energy into avoiding work rather than doing work, and it’s usually work that can only be done by the would-be ‘exporter’ in any case.

Worse, it’s a classic addiction-cycle: it looks like it will work, especially to the ‘exporter’, because they gain the impression that they’ve ‘exported’ the work to someone else. But wherever it is work that can only be done by the individual – relational-work and/or aspirational-work – the consequences of failing to do that work will always come back to bite once more: the fears that lead to the ‘need’ to ‘control’ others is example of this. Since the only apparently-available method for ‘doing’ the work consist of attempting to ‘export’ the work to others, this leads to ever-more-strenuous yet always ultimately-futile attempts to do so – each time further reducing overall effectiveness, and causing more and more damage all round.

In short, Machiavelli may be popular, but in terms of overall effectiveness he’s just plain wrong. Machiavelli may seem like good politics, but it’s definitely bad architecture for an enterprise: there can be no doubt whatsoever about that, especially over the longer term.

The catch for us, as enterprise-architects, is that he’s popular… very popular. Which is why, when we do this type of power-analysis in an enterprise-architecture, we’ll see his acolytes’ fingerprints just about everywhere we look. It’s inherent in Taylorism, for example; it’s also inherent in most current management structures. Once we fully open our eyes to this, it can get real scary for a while…

So what do we do about it?

The short answer is that we treat it like any other architecture problem:

• assess the risk and concomitant opportunity
• evaluate it – such as in terms of implied ‘Enterprise Debt‘
• document it
• develop systemic-designs to mitigate the risk and/or leverage the opportunity
• where no change is possible, register the issue as an ‘architectural dispensation’
• review dispensations regularly and/or whenever otherwise appropriate, to assess whether changes in the context might enable the dispensation to be resolved

Often the only practical way to deal with ‘protected’ embedded-dysfunctionality is to regard it as just another ‘gold-plated’ requirement – a pseudo-requirement that exists only to satisfy someone’s personal agenda. Document it as such in a dispensation, and move on: eventually there’ll be an opportunity to resolve the resultant mess, but for now that’s all we can do. The crucial skill and responsibility here is to know when the problem can be addressed, and what to do when that happens.

It’s also important to view existing power-structures solely as ‘solutions’ to power-relationships and other power-problems – in exactly the same sense as for IT-‘solutions’ in the IT-space. In other words, don’t view them as requirements in their own right: always assess the underlying requirements in terms of work to be done, and mutual-responsibilities (‘response-abilities’) in doing that work, before looking for any ‘solutions’ that could address those requirements. In many cases the existing power-structures may be the only ‘solutions’ currently available: but again, we need to review them on a regular basis, we need to be ready at any moment for a change that could enable a redesign that would serve the real requirements better than at present.

Yet here lies a crucial warning: in most cases, do not challenge people directly on power-issues, unless they’re already willing and able to take it on. If they’re not, the challenge will usually be experienced as an existential threat, triggering a survival-response – which in business-practice results either in a full-on fight or, worse, driving the power-problem deeper underground where it becomes even harder to address.

If we challenge anyone directly, we are the ones who’ll usually wear the brunt of it. In a business-context, if we don’t have the full imprimatur of the CEO and executive behind us, a direct challenge to someone fairly senior will risk getting us fired, or worse. (When the person who needs to be challenged is the CEO, things definitely get tricky: I speak from first-hand experience there… 😐 )

In short, if there’s any practical alternative to challenging someone directly on power-issues, take it. And to resolve power-problems, always aim to use systemic design-changes – changes of system, not person, or personal-behaviour as such.

More on this in later posts, but I’d better stop there for now. Over to you for comment, perhaps?