Tag Archives: John Boyd

Observe, Orient, Decide, Act

OODA: Observe, Orient, Decide, Act
OODA: Observe, Orient, Decide, Act

It seems that I’ve shared this with four or five different groups of people over the last couple of weeks, so I thought it worthwhile putting it on the blog. Plus this is one of those instances where the Wikipedia page is not the best launching point.

Anyway, OODA (Observe, Orient, Decide, Act){{1}}, shown above, is a learning framework created by John Boyd{{2}}.

[[1]]John Boyd, The OODA LOOP, The Essence of Winning and Losing, slide 4 @ danford.net[[1]]

[[2]]A John Boyd Biography @ danford.net[[2]]

Colonel Boyd was an interesting bloke who had a huge influence on military tactics. One of his key insights was that success in a rapidly changing environment depends on your ability to adapt to the environment as it changes about you. The successful army is the one that can adapt as the world changes around it, and not necessarily the army with more resources at its disposal. This is interesting as the evidence is in and it shows that – for the vast majority of businesses – your competitors have very little influence on your success or failure; the largest factor is your ability to adapt and stay relevant as the market changes around you. Think Nokia, RIM and the iPhone. Or think in terms of high speed rail and point-to-point buses vs. discount air travel in Europe. The complication here is that today’s environment is changing so rapidly that your art – your product – might only have a shelf life of six months or so.

Continue reading Observe, Orient, Decide, Act

Three questions you need to ask

There's three questions you need to ask yourself before you invest a large chunk of cash in some enterprise application:

  • Can I use something, rather than configuring something, rather than customising something?
  • How will the solution support the (social) community who will use it?
  • Is there a reason why I can't buy the solution ‘on-demand’ via SaaS?

Continue reading Three questions you need to ask

Good advice

There’s a few bits of good advice that I’ve stumbled across during my time, and which I’ve sprinkled in some of my posts. I thought it might be worthwhile gathering them into one place.

On solving problems

If you don’t like the problem, then change it into one you do like.
— Dr K Pang

One of the best pieces of advice I picked up was from Dr. K. K. Pang1)Dr Pang unfortunately passed away in March 2009. at university some time ago. Dr Pang taught circuit theory, which can be quite a frustrating subject. It’s common to encounter a problem in circuit theory which you just can’t find a way into, making it seemingly impossible to solve. Dr. Pang’s brilliant, yet simple, advice was “If you don’t like the problem, then change it to one you do like.”. Just start messing with the problem, transforming bits of the circuit at random until you find a problem that you can solve.

The trick with overcoming many of the obstacles that life and work throws in front of you is to realize which problem you should be solving.

On creativity

It’s pointless to try and be original, as someone’s always done it before. Just focus on doing what you’re interested in.
—Tom Fryer

My guitar teacher of many years back, Tom Fryer,2)Greasy Boundaries by the Tom Fryer Quartet at Bar 303 Northcote, Melbourne Australia. had a bit of sage advice. It’s pointless to try to be original, as someone will always have had the idea before you. It’s a big world with a lot of history, and there’s not that many ideas. A more productive approach is to simply plow your own furrow; focus on the problems you want to solve, steal ideas shamelessly if they seem useful, and invent what you need to fill the gaps. It doesn’t matter if what you’re doing is original or not; it’s only a question of how useful and interesting the result is.

This is something that I’ve since seen from a few well known creative folk.

It’s not where you take things from, it’s where you take them to.
—Jean-Luc Godard

Innovation (a related topic) is not a question of having a great idea, or being the best at execution. Results count: what did you do with the opportunity to had?

On being the best

You’ll end up disappointed if you worry about being the best at what you do. It’s a big world and you’ll eventually run into someone has more skill. It’s more important to be happy with what you’ve done.
—Tom Fryer

Another from Tom; he’s a very wise man. No matter how much you practice, some day, probably in an armpit bar in the backwoods, there’ll be someone who blows you away as they have more skills than you. Winning awards or contests doesn’t mean you’re the best; it just means that you’re the most successful competitor at the time. (Or just the most popular, as many contests are actually fashion contests.) Some folk don’t choose to compete.

This ties back to John Kay’s concept of obliquity3)John Kay (Jan 2004), Obliquity, The Financial Times: the idea that your goals are often best approached obliquely. The most effective path up the hill is usually to weave our way up the slope, rather than directly attack the steepest path.

I call this paradox the principle of obliquity. It says that some objectives are best pursued indirectly. I owe the phrase to Sir James Black, the chemist, whose career illustrates the principle in action. Black made more money for British companies than anyone else in the history of British business, by inventing beta-blockers and anti-ulcerants. The first he discovered in the laboratories of ICI, the second in those of Smith Kline French after he had decided that ICI was more interested in profits than in chemistry. To quote Black ‘I used to tell my colleagues (at ICI) that if they were after profits there were easier routes than drug research. How wrong could one be?’ The attempt to pursue profit too earnestly is pharmaceutical research defeated its own objectives.
—John Kay

The path to sustained success is not to set some imaginary hurdle to jump over – being the biggest or best – but to focus on doing what it is you want to do. IBM – helping business make use of technology – has been successful for over one hundred years. Microsoft – the biggest application developer on the planet – is struggling after a few decades.4)The Economist (2011), Middle-aged blues: The software giant is grappling with a mid-life crisis

Apple’s journey over the last decade or so seems to bear this out.

We just want to make products that we’d love to own.
—Steve Jobs

On being somebody

“Tiger, one day you will come to a fork in the road,” he said. “And you’re going to have to make a decision about which direction you want to go.” He raised his hand and pointed. “If you go that way you can be somebody. You will have to make compromises and you will have to turn your back on your friends. But you will be a member of the club and you will get promoted and you will get good assignments.”

Then Boyd raised his other hand and pointed another direction. “Or you can go that way and you can do something – something for your country and for your Air Force and for yourself. If you decide you want to do something, you may not get promoted and you may not get the good assignments and you certainly will not be a favorite of your superiors. But you won’t have to compromise yourself. You will be true to your friends and to yourself. And your work might make a difference.”

He paused and stared into the officer’s eyes and heart. “To be somebody or to do something.” In life there is often a roll call. That’s when you will have to make a decision. To be or to do. Which way will you go?”

—John Boyd from Boyd: The fighter pilot who changed the art of war5)Robert Coram (2002), Boyd: The fighter pilot who changed the art of war, Back Bay Books

It’s a big choice, but one the career councillors at school seem to gloss over. You can either choose to be someone, to fulfil a specific role such as CEO or rock star, or to do something, such as feed the poor. If you’re lucky, doing something will also allow you to be someone (such as Mother Teresa), but it doesn’t work the other way around.


References   [ + ]

1. Dr Pang unfortunately passed away in March 2009.
2. Greasy Boundaries by the Tom Fryer Quartet at Bar 303 Northcote, Melbourne Australia.
3. John Kay (Jan 2004), Obliquity, The Financial Times
4. The Economist (2011), Middle-aged blues: The software giant is grappling with a mid-life crisis
5. Robert Coram (2002), Boyd: The fighter pilot who changed the art of war, Back Bay Books

The sun-shaped individual

(Yep, this is a cross post from Stuff I find interesting, but the missive grew to the point that I thought it worthwhile putting it on this blog as well.)

I stumbled across a rather interesting, and rather old (in internet terms), blog post today: T-Shaped + Sun-Shaped People by David Armano. I suppose you could say that it’s a build on the old idea of t-shaped people, folk with deep experience in one domain (their core discipline). As the post quotes, from Tim Brown at IDEO:

We look for people who are so inquisitive about the world that they’re willing to try to do what you do. We call them “T-shaped people.” They have a principal skill that describes the vertical leg of the T — they’re mechanical engineers or industrial designers. But they are so empathetic that they can branch out into other skills, such as anthropology, and do them as well. They are able to explore insights from many different perspectives and recognize patterns of behavior that point to a universal human need. That’s what you’re after at this point — patterns that yield ideas.

I’ve always found the concept of t-shaped people interesting and troubling at the same time. One the one hand their broader view provides them with some sensitivity for the problems and experience to be found in other domains. On the other, it reeks of dilettantism, as there is no rational behind their interest other than curiosity (what’s it like on the other side of the fence?). This leaves you a victim of the dogma of your core discipline, with the cross discipline stuff just window dressing.

For a while I’ve thought (and spoken) of then need to have some sort of coherent focus to our interests, something beyond the doctrine we learnt in our early twenties and which largely defines us. I think we need this focus for a few different reasons.

Firstly, it provides helps us identify the sort of problems we want to solve beyond the constraints of a well defined discipline. I’m interested in how people solve problems, which leads me to working in everything from (business) strategy down to workflow design.

Secondly, it provides you with a framework to identify and integrate new ideas and domains into your toolkit. It’s a bit like Bruce Lee’s ideas of “adopt what you can use” from Jeet Kyne Do. For years I’ve been finding, collecting, evaluating and then either integrating ideas from areas as diverse as logic and science, (bio-medical) engineering, history, philosophy (including the likes of Cicero), human factors, business theory (Michael Porter an the like) and even computer science (particularly AI). You don’t collect random ideas (a la TED), you find useful tools which integrate with and add value to your toolkit.

Thirdly, it provides you with a mechanism to cope with the deluge of information we live in today. There’s a lot of talk of the need for smart filters, which I’ve always had a problem with. Perhaps it’s my little internal John Boyd, but we shouldn’t be just throwing away valuable information. A more intelligent approach is to have a framework — a focus — which makes it easier to integrate the information into our world view. (There’s probably a whole post in this point alone.)

David’s post posited the concept of sun-shaped person, which sounds a lot like this idea of having a consistent focus.

Does this make us "sun-shaped people"?
Does this make us "sun-shaped people"?

Quoting David:

Most of us have some kind of passion in a specific area. For some—it’s a hobby or interest. For others, it’s directly related to our work. I fall into the latter category. If you were to ask me what my “passion is”—I would probably say that at the core, it’s creative problem solving. This is pretty broad and incorporates a lot of disciplines that can relate to it. But that’s the point. What if we start with our passions regardless of discipline, and look at the skills which radiate out from it the same way we think about how rays from the sun radiate warmth?

I think this makes a lot of sense, and fits in a lot more neatly with the direction the world is headed, than the concept of a t-shaped individual. Who doesn’t wear multiple hats these days? How much of your job is actually related to your job title? And don’t we all steal ideas from other disciplines?

Tying yourself to a single domain — I’m a supply chain person, I’m a techo, I do human factors — is committing yourself to doing the same thing that you did yesterday. Your marking yourself as a domain specialist. The challenge is that we seem to be entering an age where we need more generalists. Last year you worked in finance, this year your building robots, next year you might be in durable goods. Your focus, your passions, won’t have changed, but what you do day-to-day will have. That sounds a lot like the sun shaped individual to me.

Some new rules for IT

The other week I had a go at capturing the rules of enterprise IT{{1}}. The starting point was a few of those beery discussions we all have after work, where we came to wonder how the game of enterprise IT was changing. It’s the common refrain of big-to-small, the Sieble to Saleforce.com transition which sees the need for IT services (internal or external) change dramatically. The rules of IT are definitely changing. Now that I’ve had a go at old rules, I thought I’d have a go at seeing what the new rules might be.

As I mentioned before, enterprise IT has historically been seen as an asset management function, a production line for delivering large IT assets into the IT estate and then maintaining them. The rules are the therefore rules of business operations. My attempt at capturing 4 ± 2 rules (with friends) produced the following (in no particular order):

[[1]]The rules of Enterprise IT @ PEG[[1]]

  • Keep the lights on. Much like being a trucker, the trick is to keep the truck rolling (and avoid spending money on tyres). Otherwise known as smooth running applications are the ticket to the strategy table.
  • Save money. Business IT was born as a cost saving exercise (out with the rooms full of people, in with the punch card machines), and most IT business cases are little different.
  • Build what you need. I wouldn’t be surprised if the team building LEO{{2}} blew their own valve tubes. You couldn’t buy parts of the shelf so you had to make everything. This is still with us in some organisations’ strong desire to build – or at least heavily customise – solutions.
  • Keep the outside outside. We trust whatever’s inside our four walls, while deploying security measures to keep the evil outside. This creates an us (employees) and them (customers, partners, and everyone else) mentality.

[[2]]LEO: Lyons Electronic Office. The first business computer. @ Wikipedia[[2]]

Things have changed since these rules were first laid down. From another post of mine on a similar topic{{3}} (somewhat trimmed and edited):

[[3]]The IT department we have today is not the IT department we’ll need tomorrow @ PEG[[3]]

The recent global financial criss has fundamentally changed the business landscape, with many are even talking about the emergence of a new normal{{4}}. We’ve also seen the emergence of outsource, offshore, cloud computing, SaaS, Enterprise 2.0 and so much more.

Companies are becoming more focused, while leaning more heavily on partners and services companies (BPO, out-sourcers, consultants, and so on) to cover those areas of the business they don’t want to focus on. We can see this from the global companies who have effectively moved to a franchise model, though to the small end of town where startups are using on-line services such as Amazon S3, rather than building their own internal capabilities.

We’re also seeing more rapid business change: what used to take years now takes months, or even weeks. The constant value-chain optimisation we’ve been working on since the 70s has finally cumulated in product and regulatory life-cycles that change faster than we can keep up.

Money is also becoming (or has become) more expensive, causing companies and deals to operate with less leverage. This means that there is less capital available for major projects, pushing companies to favour renting over buying, as well as creating a preference for smaller, incremental change over the major business transformation of the past.

And finally, companies are starting to take a truly global outlook and operate as one cohesive business across the globe, rather than as a family of cloned business who operate more-or-less independently in each region.

[[4]]The new normal @ McKinsey Quarterly[[4]]

So what are the new 4 ± 2 rules? They’re not the old rules of asset management. We could argue that they’re the rules of modern manoeuvre warfare{{5}} (which would allow me to sneak in one of my regular John Boyd references{{6}}), but that would be have the tail wagging the dog as it’s business, and not IT that has that responsibility.

[[5]]Maneuver warfare @ Wikipedia[[5]]
[[6]]John Boyd @ Wikipedia[[6]]

I think that the new rules cast IT as something like that of a pit crew. IT doesn’t make the parts (though we might lash together something when in a pinch), nor do we steer the car. Our job is to swap the tyres, pump the fuel, and straighten the fender, all in that sliver of time available to us, so that the driver can focus on their race strategy and get back out on track as quickly as possible.

With that in mind, the following seems to be a fair (4 ± 2) minimum set to start with.

  • Timeliness. A late solution is often worse than no solution at all, as you’ve spent the money without realising any benefit. Or, as a wise sage once told me, management is the art of making a timely decision, and then making it work. Where before we could take the time to get it right (after all, the solution will be in the field for a long time and needs to support a lot of people, so better to discover problems early rather than later), now we just need to make sure the solution is good enough in the time available, and has the potential to grow to meet future demand. The large “productionisation” efforts of the past need to be broken into a series of incremental improvements (à la Gmail and the land of perpeputal beta), aligning investment with both opportunity and realised value.
  • Availability. Not just up time, but ensuring that all stakeholders (both in and outside the company, including partners and clients) can get access to the solutions and data they need. There’s little value in a sophisticated knowledge base solution if the sales team can’t use it in the field to answer customer questions in real time. Once they’ve had to fire up the laptop, and the 3G card, and the VPN, the moment has passed and the sale lost. Or worse, forcing them to head back to the bricks and mortar office. As I pointed out the other week, decisions are more important than data{{7}}, and success in this environment means empowering stakeholders to make the best possible decisions by ensuring that the have the data and functions they need, where they need, when they need it, and in a format that make it easy to consume.
  • Agility. Agility means creating an IT estate that meet the challenges we can see coming down the road. It doesn’t mean creating an infinitely flexible IT estate. Every bit of flexibility we create, every flex point we add, comes at a cost. Too much flexibility is a bad thing{{8}}, as it weighs us down. Think of formula one cars: they’re fast and they’re agile (which is why driving them tends to be a young mans game), and they’re very stiff. Agility comes from keeping the weight down and being prepared to act quickly. This means keeping things simple, ensuring that we have minimum set of moving parts required. The F1 crowd might have an eye for detail, such as putting nitrogen{{9}} in the tyres, but unnecessary moving parts that might reduce reliability or performance are eliminated. Agility is the cross product of weight, speed, reliability and flexibility, and we need to work to get them all into balance.
  • Sustainability. Business is not a sprint (ideally), and this means that cost and reliability remain important factors, but not the only factors. While timeliness, availability and agility might be what drive us forward, we need still need to ensure that IT is still a smooth running operation. The old rules saw cost and reliability as absolutes, and we strived to keep costs as low, and reliability as high, as possible. The new rules see us balancing sustainability with need, accepting (slightly) higher costs or lower reliability to provide a more timely, available or agile solution while still meeting business requirements. (I wonder if I should have called this one “balance”.)

[[7]]Decisions are more important than data @ PEG[[7]]
[[8]]Having too much SOA is a bad thing (and what we might do about it) @ PEG[[8]]
[[9]]Understanding the sport: Tyres @ formula1.com[[9]]

While by no mean complete or definitive, I think that’s a fair set of rules to start the discussion.

Innovation linkage

I gave a talk on innovation at Chisholm tonight in their Business Innovation Seminar Series, and promised to provide links to some of my references. Here they are:

Leave a comment if I’ve missed anything and I’ll try and find a reference.

BPM is not a programming challenge

Get a few beers into a group of developers these days and it’s not uncommon for the complaints to start flowing about BPM (Business Process Management). BPM, they usually conclude, is more pain than it’s worth. I don’t think that BPM is a bad technology, per se, but it does appear to be the wrong tool for the job. The root of the problem is that BPM is a handy tool for programming distributed systems, but the challenge of creating distributed systems is orthogonal to business process execution and management. We’re using a screw driver to belt in a nail. It’s more productive to think business process execution and management as a (realtime) planning problem.

Programming is the automation of the known. Take as stable, repeatable process and automate it; bake the process into silicone to make it go fast. This is the same tactic that I was using back in my image processing days (and that was a long time ago). We’d develop the algorithms in C, experiment and tweak until they were right, and once they were stable we’d burn them into an ASIC (Application-Specific Integrated Circuit) to provide a speed boost. The ASICs were a lot faster than the C version: more than an order of magnitude faster.

Programmers, and IT folk in general, have a habit of treating the problems we confront as programming challenges. This has been outstandingly successful to date; just try and find a home appliance or service that doesn’t have a programme buried in it somewhere. (It’s not an unmitigated success though, such as our tumble drier is driving us nuts if its overly frequent software errors.) It’s not surprising that we chose to treat business processes automation and management as a programming problem once it appeared on our radar.

Don’t get me wrong: BPM is a solid technology. A friend of mine once showed my how he’d used his BPM stack to test its BPEL engine. As side from being a nice example of eating your own dog food, it was a great example of using BPEL as a distributed programming tool to solve a small but complex problem.

So why do we see so many developers complaining about BPM? It’s not the technology itself: the technology works. The issue is that we’re using it to solve problems that it’s not suited for. The most obvious evidence of this is the current poor state of BPM support for business exception management. We’ve deployed a lot of technology to support exception management in business processes without really solving the problem.

Managing business exceptions is driving the developers nuts. I know of one example where managing a couple of not infrequent business exceptions was the major technical problem in a very significant project (well into eight figures). The problem is that business exceptions are not from the same family of beasts as programming exceptions. Programming exceptions are exceptional. Business exceptions are just a (slightly) different way to achieve the same goal. All our compensating actions and exception stacks just get in the way of solving the problem.

On PowerPoint, anything can look achievable. The BPMN diagram we shared with the business was extremely elegant: nice sharp angles and coloured bubbles. Everyone agreed that it was a good representation of what the business does. The devil is in the details though. The development team quickly becomes frustrated as they have to deal with the realities of implementing a dynamic and exception rich business processes. Exceptions pile up on top of exceptions, and soon that BPMN diagram covers a wall, littered as it is with branch and join operations. It’s not a complex process, but we’ve made it incredibly complicated.

Edward Tufte's take on explaining complex concepts with PowerPoint
A military parade explained, a la PowerPoint

We can’t program our way out of this box, trying to pile on more features and patches. We can rip the complications out – simplifying the process to the point that it becomes tractable with our programming tools (which is what happened in my example above). But this removes all the variation which which makes the processes so valuable. (This, of course, the dirty secret of LEAN et al: you’re trading flexibility for cost saving, making your processes very efficient but also very fragile.)

Or we can try solving the problem a different way.

Don’t treat the automation of a business processes as a programming task (and I by this I mean the capture of imperative instructions for a computer to execute, no matter how unstructured or parallel). Programming is the automation of the known. Business processes, however, are the management and anticipation of the unknown. Modelling business processes should be seen as a (realtime) planning problem.

Which comes back to one of my common themes: push vs pull models, or the importance of what over how. Or, as a friend of mine with a better turn of phrase puts it, we need to stop trying to invent new technologies and work out how to use what we already have more effectively. Rather than trying to invent new technologies to solve problems that are already well understood elsewhere, pushing the technology into the problem, a more pragmatic approach is to leverage that existing understanding and then pull in existing technologies as appropriate.

Planning and executing in a rapidly changing environment is a well understood problem. Just ask anyone who’s been involved with the military. If we view the management of a business processes as a realtime planning problem, then what were business exceptions are reduced to simply alternate routes to the same goal, rather than a problem which requires a compensating action.

Battle of Gaugamela (Arbela) (331BC)
Take that hill!

One key principle is to establish a clear goal – Take that hill!, or Find that lost shipment! – articulate the tactics, the courses of action we might use to achieve that goal, and then defer decisions on which course of action to take until the decision needs to be made. If we commit to a course of action too early, locking in a decision during design time, then it’s likely that we’ll be forced to manage the exception when we realise that we picked the wrong course of action. It’s better to wait until the moment when all relevant information and options are available to us, and then take decisive action.

From a modelling point of view, we need to establish where are the key events at which we need to make decisions in line with a larger strategy. The decisions at each of these events needs to weigh the available courses of action and select the most appropriate, much like using a set of business rules to identify applicable options. The course of action selected, a scenario or business process fragment, will be semi independent from the other in the applicable set, as it addresses a different business context. Nor can the scenario we pick cannot be predetermined, as it depends on the business context. Short and sharp, each scenario will be simple, general and flexible, enabling us to configure it for the specific circumstances at hand, as we can’t anticipate all possible scenarios. And finally, we need to ensure that the scenarios we provide cover the situations we can anticipate, including the provision of a manual escape hatch.

Goals, rules and process: in that order. Integrated rather than as standalone engines. Pull pull these established technologies into a single platform and we might just be closer to a BPM solution inline with what we really need. (And we know there is nothing new under the sun, as this essentially a build on Jim Sinurs rules-and-process argument, and borrows a lot from STRIPS, PRS, dMARS and even the work I did at Agentis.)

As I mentioned at the start of this missive, BPM as a product category makes sense and the current implementations are capable distributed programming tools. The problem is that business process management is not a distributed programming challenge. Business exceptions are not exceptional. I say steal a page from the military strategy book – they, after all, have been successfully working on this problem for some time – and build our solutions around ideas the military use to succeed in a rapidly changing environment. Goals, rules and processes. The trick is to be pragmatic, rather than dogmatic in our implementation, and focus on solving the problem rather then trying to create a new technology.

Is “agile enterprise IT” an oxymoron?

Have we managed to design agility out of enterprise IT? Are the two now incompatible? Our decision to measure IT purely in terms of cost (ROI) or stability (SLAs) means that we have put aside other desirable characteristics like responsiveness, making our IT estates more like the lumbering airships of the 1920s. While efficient and reliable (once we got the hydrogen out of them), they are neither exciting or responsive to the business. The business ends up going elsewhere for their thrills. What to do?

LZ-127 Graf Zeppelin
LZ-127 Graf Zeppelin

An interesting post on jugaad over at the Capgemini CTO blog got me thinking. The tension between the managed chaos that jugaad seems to represent and the stability we strive for in IT seems to nicely capture the current tensions between business and IT. Business finds that opportunities are blinking in and out of existence faster than ever before, providing dramatically reduced windows of opportunity leaving IT departments unable to respond in time, prompting the business to look outside the organisation for solutions.

The first rule of CIOs is “you only have a seat at the strategy table if you’re keeping the lights on”. The pressure is on to keep the transactions flowing, and we spend a lot of time and money (usually the vast majority of our budget) ensuring that transactions do indeed flow. We often complain that our entire focus seems to be on cost and operations, when there is so much more we can bring to the leadership team. We forget that all departments labour under a similar rule, and all these rules are really just localised versions of a single overarching rule: the first rule of business, which is to be in business (i.e. remain solvent). Sales needs to sell, manufacturing needs to manufacture, … By devoting so much of our energy on cost and stability, we seems to have dug ourselves into a bit of a hole.

There’s another rule that I like to quote from time-to-time: management is not the art of making the perfect decision, but making a timely decision and then making it work. This seems to be something we’ve forgotten in the West, and particularly in IT. Perfection is an unattainable ideal in the real world, and agility requires a little chaos/instability. What’s interesting about jugaad is the concept’s ability to embrace the chaos required to succeed when resource constraints prevent you for using the perfect (or even simply the best) solution.

Vickers F.B. 5 Gunbus
Vickers F.B.5. Gunbus

Consider a fighter plane. The other day I was watching a documentary on the history of aircraft which showed how the evolution of fighters is a progression from stability to instability The first fighters (and we’re talking the start of WWI here–all fabric and glue) were designed to float above the battlefield where the pilots could shoot down at soldiers, or even lob bombs at them. They were designed to be very stable, so stable that the pilot could ignore the controls for a while and the plane would fly itself. Or you could shoot out most of the control surfaces and still land safely. (Sounds a bit like a modern, bullet proof, IT application, eh?)

The Red Baron: NAME
The Red Baron: Manfred von Richthofen

The problem with these planes is that they are very stable. It’s hard to make them turn and dance about, and this makes them easy to shoot down. They needed to be more agile, harder to shoot down, and the solution was to make them less stable. The result, by the end of WWI, was the fairly unstable tri-planes we associate with the Red Baron. Yes, this made them harder to fly, and even harder to land, but it also made them harder to hit.

Wizz forward to the modern day, and we find that all modern fighters are unstable by design. They’re so unstable that they’re unflyable without modern fly-by-wire systems. Forget about landing: you couldn’t even get them off the ground without their fancy control systems. The governance of the fly-by-wire systems lets the pilot control the uncontrollable.

The problem with modern IT is that it is too stable. Not the parts, the individual applications, but the IT estate as a whole. We’ve designed agility out of it, focusing on creating a stable and efficient platform for lobbing bombs onto the enemy below. This is great is the landscape below us doesn’t change, and the enemy promises not to move or shoot back, but not so good in today’s rapidly changing business environment. We need to be able to rapidly turn and dance about, both to dodge bullets and pounce on opportunities. We need some instability as instability means that we’re poised for change.

Jugaad points out that we need to allow in a bit of chaos if we want to bring the agility back in. The chaos jugaad provides is the instability we need. This will require us to update our governance processes, evolving them beyond simply being a tool to stop the bad happening, transforming governance into a tool for harvesting the jugaad where it occurs. After all, the role of enterprise IT is to capture good ideas and automate them, allowing them to be leveraged across the entire enterprise.

Managing chaos has become something of a science in the aircraft world. Tools like Energy-Maneuverability theory are used during aircraft design to make informed tradeoffs between weight, weapons load, amount of wing (i.e. ability to turn), and so on. This goes well beyond most efforts to map and score business processes, which is inherently a static pieces/parts and cost driven approach. Our focus should be on using different technologies and delivery approaches to modify how our IT estate responds to business change; optimising our IT estate’s dynamic, change-driven characteristics as well as its cost-driven static characteristics.

This might be the root of some of the problems we’re seeing between business and IT. IT’s tendency to measure value in terms of cost and/or stability leads us to create IT estates optimised for a static environment, which are at odds with the dynamic nature of the modern business environment. We should be focusing on the overall dynamic business performance of the IT estate, its energy-maneuverability profile.

Innovation and the art of random

A little while ago I was invited to speak at an event, InnoFuture, which, for a mixture of reasons, didn’t end up happening. The theme for the event was Ahead of the trends — the random effect. My take on it was that innovation is not random, it’s just happening faster than you can process, and that ideas are commoditized making synthesis, the creation of new solutions to old problems, what drives innovation. I was pretty happy with the outline I put together for my talk, that I ended up reusing the content and breaking it into three blog posts, rather than letting it go to waste.

Innovation seems to be the topic of the day. Everyone seems to want some, thinking that it’s the secret sauce which will help them (or their company) bubble to the top of the heap. The self help and consulting communities have responded in force, trying to bottle lightening or package the silver bullet (whichever metaphor you prefer).

It was in this environment that I was quite taken by the topic of a recent InnoFuture event when I was asked to speak.

Ahead of trends — the random effect.
When a concept becomes a trend, you are a not the leader. How to tap into valuable ideas for products, services and communication before they are seen as trends, when they are just … random? Albert Einstein said that imagination is more important than knowledge. Let’s open the doors and let the imagination in for it seems that in the current crisis, the right brain is winning and we may be rationalized to death before things get better.

I’ve never seen the random effect, though I have been delightfully surprised when something unexpected pops up. Having been involved in a bunch of companies and projects that, I’m told, where innovative, I’ve always thought innovation was not so much random, as the result of obliquity. What makes it seem random is the simple fact that your are not aware of the intervening steps from interesting problem through to novel solution.

I figured I’d mash together a few ideas that capture this thought, and provide some (hopefully) sage advice based on what I do to deal with random. I ended up selecting:

  • John Boyd on why rapidly changing environments are confusing,
  • Peter Drucker‘s insight that insight (the tacit application of knowledge) is not a transferable good,
  • the struggle for fluency that we all go through as we learn to read,
  • John Boyd (again, but then he had a lot of good ideas) on the need for synthesis,
  • KK Pang (and old lecturer of mine) on the need to view problems from multiple contexts,
  • the need to follow a consistent theme of interest as the only tractable way of finding interesting problems to solve, and
  • my own experiences in leveraging a network of like and dissimilar minds as a way of effectivly out-sourcing analysis.

The result was called Of snow mobiles and childhood readers: why random isn’t, and how to make it work for you. I ended up having far to much content to fill my twenty minute slot, so it’s probably for the better that the event didn’t go ahead, as it would have taken a lot of time to cut it down.

Given that I had a fairly well developed outline, I decided to make it into a series of blog posts (plus my slides these days don’t have a lot of text on them, so if I just dropped the slides online they wouldn’t make any sense). The blog posts ended up breaking down this way:

  1. Innovation should not be the race for the new-new thing.
    Points out that innovation only seems random, unexpected, as you don’t see the intervening steps between a problem and new solution, and that innovation is the result of many small commoditized steps. This ties into one of my earlier posts of dealing with the speed of change.
  2. The role of snowmobiles in innovation.
    Argues that ideas are a common commodity, and that the real challenge with innovation is synthesis rather than ideation.
  3. Childhood readers and the art of random.
    Argues that the key to innovation is to find interesting problems to solve, and suggests that the best approach is to be fluent in a range of domains (sectors, geographies, activities, …) to provide a broader perspective, focus on a line of inquiry to provide some structure, and build a network of people with complimentary interests, providing you with the time, space and opportunity to focus on synthesis.

I expect that these are more productive if taken as a whole, rather than individual posts.

If you look at the path I’ve charted over my career then this is the approach I’ve taken, and my topic of choice is how people communicate and decide as a group, leading me to John Boyd, Cicero, human-computer interaction, agent technology, biology (my thesis was mathematically modelling nerves in a cat), and so on.

I still have the slides, so feel free to contact me it you’re interested in my presenting all or part of this topic.