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?

8 Comments on “Power-issues in EA – tread carefully…

  1. Somewhat like Demings “Drive out fear” I also like to quote Yoda (George Lucas?) when referring to power and politics “Fear is the path to the dark side (or in this instance the gold plated requirement :)). Fear leads to anger, Anger leads to hate. Hate leads to suffering.”

    • Thanks, Peter – very true.

      “Fear leads to anger, Anger leads to hate. Hate leads to suffering” – that’s a line I need particularly to remember at the moment. 🙁 Oh well.

  2. I haven’t had time to dig out my copy of The Prince yet to see if there’s a confirming quote, but my impression is that Niccolo would have advocated win-wins in most cases. I remember admonitions against making enemies unnecessarily, and win-lose runs that risk (unless it’s win-annihilate, and even then there’s the negative PR to consider).

    • Thanks, Gene – I admit to not having read ‘The Prince’ in anything more than a surface skim-read: it’s more that I’ve suffered too much the joyous attentions of his would-be acolytes, which has kinda put me off. Seems like it’s time I went back there again?

      From what you’re saying, it seems like Machiavelli might paraphrase that old quote attributed to Marx: “personally”, says Machiavelli, “I’m not a Machiavellian”. :wry-grin: Those were all good points you listed: glad to hear that there is a lot of real sense in ‘The Prince’, much as there is in that other much-misused classic, ‘The Art of War’.

      (By the way, Jorgen Dahlberg (@greblhad) has done a really interesting adaptation of ‘The Art of War’ as ‘The Art of Enterprise Architecture’ – see his website at http://enklare.wordpress.com/ )

      • I love the quote…I’d hate to tally all the authors who find their ideas unrecognizable when echoed back through the filter of others.

        It’s definitely worth the read (of course, I’m something of a history geek). On the plus side, it’s a short read (+/- 80 pages if I remember correctly). The downside is that there are plenty of asides about current events, current being the Renaissance. A translation with good notes is helpful there.

        Jorgen’s site is now bookmarked in my “check out” folder.

        • Gene: “I’d hate to tally all the authors who find their ideas unrecognizable when echoed back through the filter of others.” – too true. A few decades back, some idiot misread a phrase from one of my books and built a whole religion on it. Literally. :sigh:…

          Will definitely follow through on ‘The Prince’, though – many thanks for that.

  3. Tom,

    Another great post! I have so many comments/thoughts here but not enough time.

    1) Fantastic definition of “work”!

    2) How is “exporting” work different from the common delegation of work from manager to subordinate? What is the difference between the two? Clearly you can’t export relationships and aspirations but at the same time one person can’t do all work. I can see why exporting can be bad if ONLY one person in the organization can perform a task – but still, make sure to have a backup. If only one person can truly do the work – and they avoid that work by exporting/delegating it to someone – then organization effectiveness and efficiency takes a hit. In the real world, however, people tend to have back-ups in case.

    The case of NOT having a backup and truly being the only person who can get something done seems like a small “corner case” in the over-all power-problems of an enterprise.

    That’s just my thoughts – I have feeling it’s just my small mind attempting to grasp your complex concepts.

    3) “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.” Can you give an example of a “systemic design change” in this context?


    • Hi Eric – thanks for the comments!

      1) I’m glad you find the definition of ‘work’ useful. It’s a lot broader than most people use, and probably quite a lot more structured, too, but I’ve found it the most useful way to describe the drivers for an entire architecture. If you explore those dimensions a bit more deeply over time, I think you’ll see what I mean there?

      2) In essence, what I’m terming ‘export’ is any attempt to offload onto others, work that should or can only be done by the self. Common examples include the work needed to learn something, to stay fit and healthy, to maintain relationships, to face fears, and so on: people routinely try to ‘export’ that work to others, even though it’s inherently impossible that doing so could actually succeed. (The ‘other’ can also be self in some past or future sense – such as in “if only I had done…” and “I’ll leave it until later…”.)

      You’re right, though: this needs a lot more explanation, but I’ll do so in another post so as to make it more generally visible. Thanks for the reminder on that.

      3) ‘Systemic design change’: probably the master on this would be Deming, and his work on how to tackle one of his ’14 Points’, “Drive out fear”.

      A simple example of a systemic change would be to look for anywhere in a system that explicitly and/or inherently places two or more entities in direct oppositional conflict, and then place other architectural elements to deflect the conflict ‘sideways’ such that it actually ends up being mutually-supportive. See the section ‘Conflict: Engineers versus scientists’ in my post ‘Unbreaking‘ for a real-world example from my own work.

      Perhaps the best example of a simple systemic change to resolve real-time power-struggles is a brilliant solution to prevent the (very dangerous) problem of stampede-crush at emergency-exits for sports-stadiums and other large venues. In an emergency, everyone rushes straight for the exit, which causes a jam. The design-change is to insert a waist-height, body-width pillar at about three metres straight inward from the exit. This doesn’t block the view to the exit – hence people do still know where to get out – but it splits the straight-to-the-exit flow just enough that people come to the exit at intersecting diagonals rather than head-on to the exit, which allows a much smoother flow and higher effective throughput.

      I’ll give more examples in that upcoming post, anyway, but I hope this gives you enough to work with for now?

Leave a Reply

Your email address will not be published. Required fields are marked *