Competition-against or competition-with?

What’s the point of competition, in a business-context? Perhaps more to the point, what is competition in a business-context? And why?

Another of those ‘obvious’ question-themes that turn out to be not so obvious at all… And the answers are very important in enterprise-architecture, business-architecture and business-model design: not least because if we get it wrong – as too many people still seem to do, in business and elsewhere – then we’ll likely find ourselves on a guaranteed path to business failure.

Was reminded of this by two Tweets earlier today, both from Swedish social-business specialist Oscar Berg:

  • oscarberg: RT @letterpress_se: In war, there can be only one winner. Not so in business – Stop Competing to Be the Best
  • oscarberg: Apple, Samsung, Motorola, Nokia et al…please fight your wars in the marketplace, not in courts

The HBR article, by Joan Magretta, that’s referenced in that first Tweet, describes the key part of the point I want to make here. The second Tweet illustrates what happens when people don’t get that point: business-energy gets wasted on things that don’t actually matter, until all the players in that ‘game’ get so wasted, in various senses, that none of them can survive.

[There’s one subtle yet crucial disagreement I’d have with that comment above from Joan Magretta’s article, that “In war, there can only be one winner”. I know it’s a popular belief, but it’s wrong – lethally wrong, often in an all too literal sense. No-one wins from being involved in a war: the only ‘winners’ are those who take care not to be involved, and the parasites who profit from picking up the pieces afterwards – and who often set up the war in the first place, for exactly that reason. No-one wins from a war: everyone loses. We’ll see why that’s so in a moment – and also why that fact matters a very great deal in business.]

So is competition good, or not good? For that matter, should we cooperate with others, or not? In all of those questions, the obvious answer is “It all depends…” – but what it most depends on in each case is what we understand as the nature and purpose of competition, and its apparent counterpart in cooperation. And that, in turn, depends on what we understand as the nature and purpose of power.

What’s the purpose of competition? Is it to win? If so, win what?

Is it to beat the other guy? If so, what happens next?

Or is it less about winning as such, but more about not having to face the feeling of failure, of being labelled ‘the loser’, and everything else that goes with that label in so many societies?

Yeah, that last one starts to hit a bit closer to home, doesn’t it? Oops…

Behind most of the myths of competition is a hugely tangled mess of mostly-unacknowledged feelings and fears. The details change from culture to culture, and I won’t go into much of that detail here, but the real core of it is a really simple set of mistakes about the nature of power in the workplace and elsewhere. Again, I won’t go into the detail – see my book Power and Response-ability, if you’re interested, or the associated brief ‘manifesto‘ – but in essence what it comes down to is this:

— the physics definition is that power is the ability to do work

— most social definitions are closer to the notion that power is the ability to avoid work

Therein lie the roots of some serious problems for business…

In the myths around ‘winning’ and ‘losing’, most of the work being avoided is relational and aspirational: in other words, work that can only be personal, not collective. On one side, it’s often a failure to grasp that, on a finite world, we are always in a closed, finite context where ultimately there is no convenient-scapegoat ‘Them’, but only ‘Us’ – hence there is no-one that we can ‘win’ against. On the other side, we actually can’t force others to face our own feelings for us – no matter how much we would want that to happen – because they’re actually our feelings. And in reality there’s no way to win, in any real sense, unless we find the courage to turn round and face that work – rather than wasting what little energy we have in futilely trying and, by definition, failing to ‘export’ it to everyone else.

Do we really think we can ‘win’ by making someone else ‘lose’? The reality is that the most we could achieve is a temporary respite from that ‘feeling-work’, at the cost of actually increasing the damage and the load across the overall system. At best, we gain a short-lived ‘high’ – exactly like any other form of addiction. Which is why most of the myths about ‘winning’, and most of the myths about ‘beating the competition’, are a literally deadly delusion.

[There are plenty of people who would promote such myths, of course – especially the parasites who profit from the ever-popular ‘game‘ of ‘let’s you and him fight’. The point here is that those myths don’t help you – even (or perhaps especially) in a business-context.]

Competition is good: we need competition if we’re to improve our skills, our competencies, our overall game.

But it’s only good – is only successful, in the longer term – if we compete with others. Not ‘against’ others.

Cooperation is good: we need cooperation if we’re to do anything that we cannot do solely on our own.

But although cooperation is always going to mean working with others in some sense or other, it’s only good – is only successful, in the longer term – if the overall aim of the cooperation is with all others. Not ‘against’ others.

There are only two choices here: either everyone wins, in some way; or everyone loses. There is no ‘win/lose’: it’s a delusory form of ‘lose/lose’, in which an apparent gain for one party masks a greater overall loss for everyone – including the nominal ‘winner’.

If we compete with others, and with ourselves, everyone wins. Sometimes one player is ‘the winner’, sometimes another: but overall, over time, everyone wins in one sense or another – and the overall ‘competing’ is a key part of what helps everyone win.

If we compete against others… – well, in short, everyone loses. No matter what it looks like in the shorter-term, everyone loses.

[Except for the scavengers and parasites, of course. And yes, we all know who they are in business. Except we’re so often required to pretend that we don’t, and that they’re not. Oh well.]

And there’s no way round any of that: all of that comes from the real nature of power itself.

So if we’re going to compete – and in business, we’re going to want to compete, and also often have to compete – then we have to compete with others, not against them. Because if we don’t, we’re going lose – even, or perhaps most, when we seem most to ‘win’.

Which is no doubt somewhat different from what we’d hear in most everyday ideas about ‘business as usual’. But it’s also the only way that works. Which can be kinda tricky – especially in enterprise-architectures and the like, where we do need to deliver something that actually does work. Hmm…

Implications in business-architecture and enterprise-architecture

In architectural terms, what all of this comes down to is one very simple fact:

  • every instance of ‘competition-against’, in any form whatsoever, represents an active source for loss of overall effectiveness, and a potential point for catastrophic-collapse of the overall architecture

That applies right up to an overall business-model, onward through design of performance-bonuses of sales, or managers’ resource-allocation, right down to real-time relationships between web-services and code-level conflicts. Competition-with is (usually) good: no doubt about that. Yet every time we allow some form of competition-against to slip through and become embedded in the system-structures, we increase the risk of total system-failure.

Which leads us to one very simple test:

  • wherever the architecture includes some form of competition, is it competition-with, or competition-against?

In many cases, perhaps most, we’ll want our architecture to encourage competition-with.

Yet we must eliminate every form of competition-against – otherwise we’re designing an architecture that, by definition, is designed to fail.

And yes, this kind of design is all doable – despite all those conventional delusions about power and the like in ‘business as usual’. We just need to be rigorous about it, that’s all.

There are plenty of examples of how and why this works, at every level of the architecture. For business-architecture, see Joan Magretta’s HBR article referenced above, or Michael Porter’s work on strategy, or Tony Hsieh on customer-service. (For an interesting real-world example, see the small Welsh-border town of Hay-on-Wye, whose core business is built around a ‘competition-with’ web of specialist bookstores.) In the mid-range, see Dan Pink’s work on motivation, perhaps, or John Seddon on service-design. On the factory floor, see Deming’s classic ‘14 Points‘. I’ll admit I don’t know enough current code-level IT to give detailed examples there, but I know plenty of people who could.

It’s all doable. None of this is new, as such; and in itself, none of it is especially difficult, either.

[What is difficult is shifting the mindset – the usual myths of competition, the delusion that we can only ‘win’ by making others lose. That’s hard, true: but it’s also the only way that works.]

Architecturally, the only thing that makes it hard is artificial boundaries between segments of the overall system. This is one area where we need a whole-of-system perspective, and where the obsessive IT-centrism of conventional ‘enterprise’-architecture would be far more of a hindrance than a help. For much the same reasons, we need regular business-folk to understand that the overall enterprise runs on a great deal more than just money. But again, all of this is doable.

More to the point, it’s all been done – and proven in practice, too. And since overall it’s quite easy to prove that competition-with is more efficient and effective than competition-against – as can be seen in the bitter farce of the current fights between cellphone-manufacturers, as in Oscar Berg’s first Tweet above – there’s an interesting point that those who don’t ‘get’ the value of competition-with stand to lose ground against their nominal competitors… 🙂

There is, however, one serious structural problem of which we need to become very much aware. Competition-with is the only way that works, but sadly a lot of people still believe that they can be ‘the winner’ in any game of competition-against. (And there are plenty of parasites and predators who’ll prop them up in that belief, too. For a while, at least…) There are plenty of businesses that operate that way – as we all know all too well.

Yet unfortunately the game is naturally weighted in a way that props up those delusions. We know that win/win is the only way that works; we know that we can only win if others win too. But if they believe in win/lose, then they’ll be certain that they can only win by ‘making’ others seem to lose. In other words, whenever we come across someone like that, we want them to win, but they want us to lose – which is not a good place for us to be…

In those circumstances – to quote the old children’s-film War Games – “the only way to win is to not play”. So once we do get properly onto competition-with, we cannot engage with anyone who indulges in competition-against – because we will always lose, in one sense or another, whenever that occurs.

[In fact everyone will lose whenever that occurs – but it’s our organisation for which we’re designing the architecture, hence that’s what needs to be our focus here.]

So that test – explicitly excluding any interaction with any form of competition-against – needs to be embedded right the way through every aspect of the architecture, without exception. And yes, that’s hard. But essential. Seriously.

And that’s what’s actually implied, in architectural terms, from those two Tweets above. Interesting, I trust?

Anyway, enough for now, I guess. Comments, anyone?

4 Comments on “Competition-against or competition-with?

  1. Tom,

    Two comments (I am refusing to nap – which may be a form of Power (?))
    1. I have misplaced a project management book which has this quote, so I am without an earned reference: The first principle of business is not to beat the competition, but to create a quality product for the customer. //Here are two others from the book: 1) The purpose of planning is to facilitate future accomplishment, 2) The principle responsibility of a project manager is to conserve corporate resources [I find the concept of conservation, when applied to enterprise, to be extremely interesting].//
    2. When considering Power as the ability to raise somebody from the dead, all other Power seems to become boring and trite. Therefore, I would suggest that what may be considered as power for humans acting against humans is actually the exercise of (with apologies to Tom Graves) anti-dominion. Whereas, humans acting with humans promoting Humanity’s Enterprise (with conservation?) exercises dominion. Somewhat awkward…

    • Hi Myron – good to hear from you again!

      On 1), yeah, nice quotes. 🙂 “Create a quality product for the customer” becomes problematic if one doesn’t know who the real customers are, or how (if at all) they would determine quality… which is certainly the case in many business-contexts, let alone government or NGO contexts! Will admit I’m a little worried by the ‘conserve resources’ quote: it kinda suggests that the narrow-focus project-manager would take that as a directive to ‘conserve resources’ by making sure that nothing happens so that nothing is used… 🙂

      On 2), I’m guessing that this is US-Christian terminology, about the Biblical “Powers and Dominions” and suchlike? Will have to apologise, because it’s not a worldview that’s familiar to me, and hence definitely can’t and shouldn’t comment. (FWIW, my background is Quaker, which has a somewhat different notion of relationship with ‘powers and dominions’.) I do take your point, though, about respecting that there are layers at which simple interpersonal notions of competition (and even cooperation) will turn out to be, well, a bit naive? :wry-grin: Again, apologies if any possible foot-in-mouth on my part there: well aware that religion is very personal, visceral matter, and definitely no disrespect intended.

      Many thanks, and do keep in touch!

  2. Tom. Here’s some rather random thoughts inspired by what you’ve written. Take it as a starting point that I agree with the main thrust of everything you’re saying – at least as something we should strive for.
    Random thought #1. It may be true that the winner in a winning-against situation also loses but his (let’s regard him as male) pain is less sudden and acute than that of the “loser”. I mean the loser often isn’t around to see the winner get his. Which means that anything we can do (however limited) to keep him out of the game, is worth doing. You address this. I’m just stressing it. Probably more work needed here too, if only because these types (at least the “successful” ones) are damn good at subverting attempts to exclude them.
    Random thought #2. Our role as EA’s is surely somewhat limited. The EA does not determine strategy and usually has no direct authority over forms of organization. In that sense we surely can only be advocates of win-win and supporters of other who seek to achieve that. But we can’t document an architecture that is only what we’d like the enterprise to be and not what it actually is. Perhaps organization would have been a better word than enterprise in my last sentence.
    Random thought #3. In the chapter, A Problem Of Power in Real Enterprise Architecture, you describe several forms of organizational behaviour. In both the Actively and Passively Dysfunctional forms you point out that the behaviour relies on the “loser” being complicit in her/his own exploitation. That’s something else that will need to be tackled – getting the self-appointed losers to stand up for themselves.

    That’ll do for now.

  3. @Stuart Boardman – many thanks!

    On #1: “anything we can do .. to keep [them] out of the game, is worth doing”, yet “these types .. are damn good at subverting attempts to exclude them” – yes, exactly. More to the point, they are often very skilled at ‘rigging the system’ so that it becomes all-but-impossible – or even illegal – to exclude them: hence the infamous ‘unholy alliance’ between business-parasites, lawyer-parasites, politician-parasites and other literally-‘privileged’ ‘rent-seekers’. And yes, there’s a huge amount of work to be done to break that all-too-literal stranglehold – both within organisations and beyond them.

    On #2: “Our role as EA’s is surely somewhat limited”: yes, it is. Yet a key part of that role is identification of risk, and identification of options, trade-offs and priorities for mitigating such risk – and these types of risk are some of the most organisation-lethal that exist, so they’re well within our overall remit. (In principle, at least. As per your #1, there will be a fair few people who will be very keen to prevent any such enquiry – in fact following this theme is one of the best ways to bring them out of the woodwork and expose the behaviour for what it really is. But personally risky at times, of course…)

    If we stop and think about it for a moment, this is a really classic EA problem, almost exactly the same in structure as a conventional TOGAF8-style ‘tidy up the IT-mess’:
    — We have the as-is: a system that is tangled, confused, startlingly inefficient, not because it’s inherently ‘bad’ but because most things get that way after a while if they’re not continuously maintained.
    — We identify the desirable traits, content, structure for a workable ‘fit-for-purpose’ to-be.
    — We identify the key factors that must be included and excluded.
    — We build a vision for the transition, and we identify tasks and intermediate steps towards the intended to-be.
    — We design-in resilience by focussing on development of capabilities that can be re-used and re-purposed – we design specific services that use those capabilities, but expect that the service-requirements are likely to have changed by the time we reach the ‘to-be’ point.
    — We develop a roadmap for the transitions, identifying tasks, change-projects and the like.
    — We engage the sponsors in those ‘business-transformation’ efforts.
    — And then watch the sparks fly as the reality of intended change starts to hit home… 🙂

    The detail is different between IT-issues and power-issues, of course, but the architectural methods we use are almost identical.

    (Re “perhaps organization would have been a better word than enterprise”, it actually applies to both, but in different ways. [We’d perhaps better point out to others that we’re using the terms ‘organisation’ and ‘enterprise’ in a specific sense here – one in which they’re not the same.] The organisation is defined by rules, and responsibilities, so a lot of the design-work and structural-work would happen there. The broader shared-enterprise is beyond our direct reach, but can be accessed and addressed indirectly, in part via structural means such as interfaces, protocols and contractual/etc tests and requirements, but also via story. The latter is an area I’m exploring more and more these days.)

    On #3: “the ‘loser’ being complicit in his.her own exploitation. That’s something else that will need to be tackled – getting the self-appointed losers to stand up for themselves.” – yes, very much so: the power-problems go both ways here, and likewise the ‘response-ability’ issues that need to be addressed. Perhaps take a look at earlier work on violence-resolution (from almost two decades ago – yikes…), on my old personal-website, at (intro at ). It explicitly rejects arbitrary labels such as ‘perpetrator’ and ‘victim’ (and explains why it does so), and applies the same challenges on ‘response-ability’ to all players in the context. It’s a somewhat different context than an organisation (though not as much so as many people might like to think…), but essentially the principles and processes are much the same: and designing and delivering appropriate support for those principles and processes is, yes, just another architecture problem.

    Hope it’s useful, anyway.

Leave a Reply

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