13
Sep/09
0

Making continuous-improvement visible

Continuous-improvement is the cornerstone of many recent innovations in the business world – Shewhart/Deming quality-management, Six-Sigma, Agile software-development, kaizen process-improvement and lean-manufacturing, to name just a few. The mantra of “release early, release often” has been a factor in the success of many Open Source software projects. And there many other important advantages to continuous change: improvements take effect much quicker, feedback-cycles are faster, there’s better engagement on the shop-floor, and so on. When applied well, such improvements echo all the way down to a much-improved bottom-line – whatever the ‘bottom-line’ may take for that enterprise.

Yet though we may need to think side-wise somewhat to spot it, there’s also one important catch to continuous-change. Continuous improvement depends on large numbers of small incremental changes; the smaller the change, the faster that all-important feedback/improvement cycle can run. But in perceptual psychology, small changes are invisible – a change has to be of significant size or occur at a significant before it becomes noticeable In a well-designed continuous-improvement process, often the whole point is that each change should be almost invisible, because it can reduce the stress of change, and allows potentially-challenging changes to be introduced by respectful ’stealth’ rather than in a single overwhelming ‘big-bang’. But the more that the improvement-process succeeds in that task, the less anyone will notice each change – which means that the change-team may appear to be doing no work at all. Which is not a good career-move…

Worse, if no-one notices the change, and no-one seems to notice it, then perceptions of product or service may be stuck at first-impressions – which may be long out of date. As ITWorld columnist Esther Schindler put it, in her perceptive article “Why Users Dumped Your Open Source App for Proprietary Software“:

One thing that became apparent is that the lack of features is a perception that may have dated from a previous version. That is, “I tried it a few years ago, and it didn’t do what I needed then, so I chose something else… and haven’t thought about adopting the [software program] since.” If someone tried your app three years ago, back when it was all raw edges and bare metal, how will she know that it might be time to re-evaluate the options? … [She] may not realize that the version she can download today is far improved. Unless she goes out of her way to look, how likely is she to find out?

Sometimes the classic ‘big-bang’ Waterfall-style projects seem successful because their long release-cycles mean that the step-change introduced with each new release is large to be noticed. To quote Esther Schindler again:

One attribute of commercial releases is that major feature upgrades are announced with a lot of fanfare. That happens with open source applications that are household names (assuming an appropriately-geek household), but it’s rare.

…which means that some proprietary projects look better because they use a less-effective change-process. Not exactly a desirable outcome…

Part of this is marketing, of course: a big step-change gives a good excuse for an ‘event’ that’s much more noticeable than a quiet, continuous, stolid, ’steady as she goes’. Yet that is a tactic that’s worth adopting in continuous-improvement processes: invent an ‘event’ of your own, to celebrate change and advertise the improvements that have been implemented since the last ‘event’. That way you’ll make the work more noticeable – and more valued.

There’s a subtle trade-off here. You’ll want every change to be noticed, but if you set the spacing of ‘events’ too close together, not only will the events blur together too much to be noticeable, but you actually run the risk of increasing people’s ‘change-fatigue’. A common practice in open-source software-development is set formal ‘release-events’ at six-monthly or yearly intervals, even though there’ll often be many ‘point-releases’ in the intervening period. Another useful tactic there is to use names rather than numbers to designate each major change.

Some typical themes in a ‘release-event’ might include:

  • Summary of key groups of changes – keep this list short, no more than 5-7 items
  • Acknowledgement of key people involved in inventing or implementing significant changes
  • Linking process-enhancements to key performance indicators at the whole-of-enterprise level
  • Celebration of the value of change itself

Keep each change and each change-cycle small enough to enhance improve effectiveness every day; yet also ensure that overall change is large enough to be visible and valued. That’s the balance we aim to achieve here.

Why Users Dumped Your Open Source App for Proprietary Software

24
Aug/09
3

The rise of the business anarchist

If you work in a large organisation, no doubt you’ll have analysts everywhere; you may well be one yourself. You know who they are, what they do, what part they play: financial analysts, business analysts, process analysts, quality analysts and the like, keeping track of activity, performance, change.

But what about your business anarchists? Do you know who they are, what they do, what part they play, in managing the overall needs of the business? And how much your business depends on them?

And no, I’m not joking: every business does have a real need for its anarchists, every bit as much as its need for its analysts. For example, take a look at the list of ‘Six Essential Skills for Exponential Times‘, by brand consultant and social-media strategist Michelle Tripp (and also expanded on by Burton Group consultant Mike Rollings in his post ‘What to do when waking out of an EA induced coma‘):

  • Skill #1: Rule-breaking – “Rule breakers will be ready to consider possibilities that others are told ‘don’t make sense’ or ‘aren’t the way things are done around here.’”
  • Skill #2: Entrepreneurial – “Seeking out new opportunities and new ways of connecting and creating … finding them even when there isn’t an available mentor or an established path.”
  • Skill #3: Self-Educating – “More proactive than ever in learning independently and not relying on structured programs … don’t sit back and wait to be taught … searching for information and charting their own educational course.”
  • Skill #4: Bonding – “Bonding will be a matter of how much value you can provide to the people you’ve promised it to. … Those bonds can be through adding value to people’s lives through technology, information, guidance, validation, or friendship.”
  • Skill #5: Revolutionary – “Revolutionaries are at the forefront, creating the future. … Brains that thrive on change, innovation and invention, high information uptake, and leveraging technologies are geared for the future.”
  • Skill #6: Visionary – “Everything is changing faster than ever. … Having the skill of vision allows you to imagine what’s possible, imagine what’s next, and predict the needs and values of tomorrow.”

In short, the skills of thinking side-wise.

These aren’t the skills that we would expect from an analyst: far from it, in fact. In Cynefin terms, the tasks of an analyst sit squarely in the squarely in the domain of the ‘Complicated’ – calm, calculated, everything according to the rules. Which works just fine as long as everything stays much the same. But when the world changes, becomes uncertain – when we move into the Cynefin domain of the ‘Chaotic’, where the assumptions that underpin the analyst’s so-certain rules no longer apply – those analyst-skills may well be worse than useless, giving us nominal ‘right answers’ to what turn out in practice to be the wrong questions. That’s when we need a very different set of skills, to find out what questions we really need to ask. That’s when we need those skills above; that’s when we need people who are comfortable with the chaos and confusion of change. That, in short, is when we need our business-anarchists.

Don’t worry: we’re not talking about ‘kiddies-anarchy’ here – pointless disruption for disruption’s sake, or the classic student stupidity of “all property must be liberated, but don’t you dare touch my stuff!”. There’s no discipline there, no awareness of personal responsibility in a complex social context. Instead, each of those skills above have their own distinct disciplines, and, like the analysts’ skills, will rely on many years’-worth of experience to do well. The catch is that, as the Cynefin model demonstrates, the business-anarchist’s disciplines and experience are structurally different from those of the analyst – so if we try to measure them in the same terms as for the analyst, we’ll be in deep trouble straight away.

What we need from an analyst is depth of experience, in what marketers would call a vertical domain. Analysts are specialists – many years of practice in a single domain, steadily developing their skills and, especially, their speed at the work. As Cynefin shows, the core tactic is ’sense / analyse / respond’, and the key driver is a kind of ‘outer truth’, with that ‘truth’ identifiable in concrete, repeatable terms. In that sense, the analyst’s performance is relatively easy to measure, and the tasks easy to monitor, too.

But what we need from an anarchist is breadth of experience – horizontal rather than vertical. Anarchists are generalists – many years of practice at connecting across multiple domains, cross-fertilising, creating conversations between them, linking different ideas and experiences via analogy and metaphor. Yet here the key drivers are principles or values, and, as Cynefin shows, the core tactic is ‘act / sense / respond’ – we have to do something to shake things up enough to sense what’s going on and which way to go. So performance is hard to measure, because there are no clear rules to measure against; and tasks are difficult to predefine, too, because by its nature much of the work deals with inherent uncertainty. Tricky…

Generalists are the ‘glue’ that hold the organisation together: without them, there would be no end-to-end processes, nothing of practical use towards the organisation’s aims. But another problem here is that the generalist’s experience in any single domain will necessarily be less than those of an equivalent specialist who’s worked only within that one domain: so the generalist will almost always come off worst in any single skill-for-skill comparison – often leading to some very misleading performance measures. Worse, if most of our measures are ‘vertical’ (as they usually are in large organisations), then, according to those measures, the more that generalists do their real work of ‘horizontal’ connection, the less they’ll appear to do – which again can lead to some very misleading ideas about performance, with less-skilled generalists appearing to do more work than the most experienced ones. Tricky indeed…

So when do you need those business-anarchists? Who on your existing staff would be good at this kind of role – or already is? How can you tell the good from the not-so-good? And what support would they need from you to do that role well?

When do you need business-anarchists, and for what purpose?

When the world is certain, you don’t need an anarchist shaking things up: that’s when you’d be better to stick to plain ol’ everyday analysis. But fact is that the business world is not certain – especially not at the present time, where stability is more the exception than the norm, and where the roller-coaster-ness of the ride sometimes seems to get rougher by the day. Whether you like it or not, you’re going to need people who thrive on coping with chaos – the business-anarchists.

The trick here is to identify what changes, and what doesn’t – which is where business-architecture and enterprise-architecture would come into the picture, because those are key tools to help you tell the difference. Where things don’t change, or don’t change much – and there’s still a lot of those, even in the most innovative business – stick to the analysis: don’t rock the boat just for the sake of doing so. Efficiency will always matter; so will operations excellence. Use statistics and the rest wherever appropriate. But remember that statistical analysis only works well when you’re dealing with large numbers of things that are exactly the same – or supposed to be the same: for example, by definition, Six Sigma makes little sense unless you’re dealing with literally millions of identical events. If the products or tasks have a high degree of inherent variance, or have any significant ‘one-off’ elements, you’ll need to apply anarchist-like approaches to those parts that change.

Who would do this work well?

Look for the natural generalists on your staff: the people who can get interested in anything, and like making connections between different domains, different levels of abstraction, different professions, different people. You need people with both breadth and depth, and intimate knowledge of your industry and context: outside consultants may help, but experienced ‘insiders’ usually have the most to offer.

Natural talents and tendencies  may help: for example, people with Myers-Briggs xNxP ‘types’ may tend to think and act in an anarchist mode by nature. But much more important is experience: people need to know ‘the rules’, and know them well, in order to understand how and when and why to bend them to make things work better.

What are the critical success factors?

Analysis depends on the quality of algorithms and data. By contrast, the business-anarchist depends on the clarity of the organisation’s principles and values, to act as the beacon or ‘guiding star’ in conditions of inherent uncertainty. Use a structured framework such as vision, role, mission, goal to aid in anchoring those principles into everyday practice.

As above, experience is a key factor here – especially experience across a wide range of domains, and at every different level of those domains. Unlike analysis, theory alone is not enough here: it also needs to be grounded in practice, in hands-on experience, yet also with enough awareness to be able to break out of the “do it the way we’ve always done it” trap.

And there also needs to be discipline in moving between the domains: a dilettante ’scattergun’ approach to new ideas will not be enough, especially in developing sustainable business-anarchist skills over the longer term. (See here for a ‘cheat-sheet’ on moving between disciplines in a rather different set of skills: the domains may seem strange at first, but the same principles do apply even in everyday business.)

What support do your business-anarchists need from you?

In a context where things are inherently uncertain, we need to make it safe to fail, or at least safe to seem to ‘not-succeed’ in the expected way. Where ‘command and control’ would require everything to be ‘fail-safe’, here we need to allow for safe-fail – for ‘graceful failure’, for practice-space, for fallback to a known recovery condition, and so on. The purpose of an experiment is to learn, to probe into the unknown (the ‘emergent’ domain, in Cynefin terms) so as to arrive at some new understanding – so if we only allow so-called ‘experiments’ that will tell us what we already know, we fail before we start.

You will only get appropriate innovation happening within the business if you make it safe for people to ‘fail’. Simple as that.

Your business-anarchists also need protection in several different senses, often right up at the executive levels:

  • business-anarchists must necessarily break the rules: to do their work, they will need official sanction to ‘break the rules’ appropriately
  • business-anarchists and other generalists must often bridge across the silos, necessarily breaking through bureacractic boundaries: they’ll often need formal authority to do this
  • by definition, cross-functional generalists will usually have multiple reporting-relationships, often skipping over or sidestepping the ‘normal’ hierarchies: they’ll need protection from possibly-disgruntled managers in order to do this

Hence another clear, simple point: you will only gain business value from your business-anarchists and other generalists if you make it safe for them to do their work.

And in the same way that, in Six Sigma and the like, everyone is an analyst, everyone needs to be an anarchist in their own way too. Many innovative companies allocate work-time for everyone to explore their own new ideas and new business practices: India’s Tata Group, for example, allot everyone an hour a day for personal experiments, whilst at Google and 3M it’s the equivalent of a full day each week. Sure, most experiments may well go nowhere: but those that do succeed bring huge returns that repay that ‘wasted’ work-time many, many times over – and it took a real ‘anarchist’ mindset to turned a ‘failed’ experimental glue at 3M into the almost immeasurable business success that is the ubiquitous Post-It® note.

So who are your business-anarchists? And how can you help them do their work, to help create your company’s success? A question that’s worth pondering in practice, perhaps…?

12
Jul/09
2

10, 100, 1000, 10000

10, 100, 1000, 10000. A lot of things those numbers could apply to, of course, but in this case they’re ballpark figures for the number of hours it takes to develop specific levels of skill.

The thousand-hour level is quite well-known – the point at which we recognise the skill as skill. It should be obvious that it’s part of a continuum; what’s not so obvious, perhaps, is how that continuum works and what each level means in practice.

Skill-levels in part determine how we deal with an unknown world, so it’s useful to compare skill-levels against the Cynefin framework for sensemaking, as used in business and elsewhere:

Cynefin framework and skills-levels

Cynefin framework and skills-levels

In some ways, Cynefin’s four ‘domains’ also represent a classic two-axis matrix: a horizontal axis of unordered or ‘value’-based versus ordered or ‘truth’-based; and a vertical axis of available time for response, from real-time to assessment and response at one’s leisure. But it’s not quite as simple as that, because it’s also a hierarchy – cross-mapped to the layers of the ISO-9000 quality-system, for example – or a cyclic process such as the scientific-development sequence idea / hypothesis / theory / law. Each domain is also structurally different from the others in what is seen and observed, the way that decisions are made.

10 hours: Trainee: ‘learn by rote’, the typical outcome of a day’s-worth of training, or a weekend workshop – knowledge of at least the basic terminology of a skill, plus competence to at least do something useful in that context. Since there’s no real skill here – it’s just actions in response to given assumptions – this skill-level will always need to be supervised by someone or something that does have a higher skill-level, in order to ensure that what is done will actually work as intended in real-world practice. (That supervising ’someone’ can be the same person, by the way – and often is, for real people in everyday business practice.)

  • decision-making: rule-based – rapid real-time decisions on simple basis of true/false or either/or
  • decision-process: sense / categorise / respond
  • driver for development: unconscious incompetence – the need for competent action
  • ISO-9000 layer: work-instruction
  • emphasis on: physical action
  • suited to: machines or IT; real people can work at this level, but usually become less reliable the more often the task is repeated

This skill-level solves a single defined problem by a single predefined method in response to a single set of narrowly-constrained assumptions. We use this level wherever conscious decision-making is either unnecessary or undesirable, or there’s no time to think about what to do: stick to the rules, ‘the law’, keep the focus only on the task at hand, just do it, and do it fast. This is the basis of all real-world action: everyone will have thousands of competencies of at least this level by the time they leave school, and many thousands more over a working lifetime, but will develop only selected competencies to higher levels of skill.

100 hours: Apprentice: the typical outcome of a two-week training-course combined with real-world practice, or working one’s way through the whole of an instruction-book – there’s awareness of some or most of the key factors in the context, and what the trade-offs are between them. It describes and operates within an analytic ‘theory’ or interlinked set of predefined algorithms and assumptions about how some aspect of the world works.

It’s crucially important to understand, though, that this type of skill depends on its assumptions: it is reliable only where those assumptions are valid, but it has no means within itself to test the validity those assumptions. Typical business software application encapsulate this level of skill, but in practice is suitable only for easily repeatable processesnot for true complexity.

Hence, as in the old fable of the Sorcerer’s Apprentice, this is perhaps the most dangerous of skill-levels: just enough knowledge to give oneself the delusion of competence and ‘control’, but not enough awareness of its real-world limitations – enough knowledge to get into serious trouble but not enough to get back out of it – hence it’s essential for there to be ‘practice-fields’ where the inevitable mistakes may be safely made. Further skills-development should also be supported by some form of cyclical review-process such as the Deming/Shewhart ‘plan / do / check / act’ sequence – often including structured feedback such as the After Action Review – or, for skills embedded within ‘intelligent’ machines or IT-systems, an iterative ‘Agile‘-style development process.

  • decision-making: analytic – decision by ’scientific’-type analysis using calculated algorithm or true/false comparison across many factors
  • decision-process: sense / analyse / respond
  • driver for development: conscious incompetence – realistic appraisal of current skill
  • ISO-9000 layer: procedure
  • emphasis on: calculation, analysis, thought
  • suited to: IT systems and real people, also some types of machines with IT or algorithmic support

Over a working lifetime, most people will develop dozens or even hundreds of competencies at this level. Specialists will tend to collect competencies within a specific domain – system-developers, for example, will learn and use many different programming languages over time – whilst generalists will be more eclectic, often learning just sufficient about each skill to be able to converse meaningfully with the specialists yet build bridges between them.

1000 hours: Journeyman: the skills developed in a semester subject at university, a longer technical study, or just through routine practice over many months. By this stage there’s sufficient skill to work with the complexities of the real world – rather than only the abstract assumptions of IT-type logic – and to understand how to use guidelines and patterns, developing and testing hypotheses to interpret the inherent uncertainties and sheer messiness of most business practice. Unlike the ‘apprentice’ level, the ‘journeyman’ will be capable of doing unsupervised work – though there is still much to learn in terms of adaptability, ingenuity, precision and, especially, speed.

  • decision-making: emergent – decisions based on experimentation, patterns and heuristics
  • decision-process: probe / sense / respond
  • driver for development: conscious competence – the need to challenge and extend one’s skill
  • ISO-9000 layer: policy
  • emphasis on: relationships, interconnections
  • suited to: real people, also certain (expensive) types of ’semi-autonomous’ IT-systems, and specific ’self-adjusting’ components in certain types of machines (e.g. governor in steam-engine); IT usually only in a decision-support rather than decision-making role

Most people will develop a fair handful of these, as the secondary-level skills of working life: for example, the old office classics such as typing, shorthand and bookkeeping – or more updated versions such as spreadsheet design. As before, generalists will tend to collect more of these, across a broader, more eclectic scope; specialists will tend to keep their focus on a central skillset.

10000 hours: Master: the skills developed during the entire of a university course to pre-doctorate level, or of a full trade-apprenticeship – the latter traditionally ending with a skills-demonstration referred to formally as a ‘master-piece’. The knowledge and experience here is sufficient to know exactly how and when and why to bend or even break ‘the rules’, though this has now returned full-circle to working with the real world again in real-time. The classic description of this is the Chief Engineer in CS Forester’s novel The Ship: he stands on the deckplate, feet astride, hands behind his back, a still point in the centre of the action, silently watching everything going on, apparently doing nothing – yet takes action instantly when something crucial has been missed by others.

  • decision-making: principle-based – real-time decisions from intuitive grasp of the whole context
  • decision-process: act / sense / respond
  • driver for development: unconscious competence – the need to apply skill in real-time
  • ISO-9000 layer: vision
  • emphasis on: principles and overall purpose
  • suited to: real people only

Some people never reach this stage with any skill; and whilst many may have more than one – reflecting a change in career, perhaps – the number of such depth-skills for each person will always be few.

In principle at least, there is also the 100000 hours level, representing fifty years’ full-time commitment to a single skill. Almost by definition, this would be relatively rare, but certainly does occur, especially amongst artists, musicians and scientists. One business example would be Peter Drucker, who spent a working lifetime of more than 70 years observing and commenting on the social structure of business organisations.

10, 100, 1000, 10000 hours; a couple of days, a couple of weeks, half a year, five years; trainee, apprentice, journeyman, master. A useful rule-of-thumb to describe four different and distinct layers of skill.

[Article-topic suggested by Shawn Callahan of Australian narrative-knowledge consultancy Anecdote.]

9
Jul/09
2

The reverse-test

Through the marketing looking-glass“: brilliantly pithy insight from Fiona Czerniawska of SourceForConsulting.com. She notes that most of the marketing material from consulting firms has a stultifying sameness to it, the same puffery that says nothing different, nothing distinctive.

Bad marketing consists of saying things which should be taken for granted (“We are talented and innovative”) none of which stands up to the test of being reversed.

To illustrate the point – and perhaps even get a generation of marketing people to “think outside the box”, we’d like to demonstrate what happens when you say the opposite of what most firms put in their marketing literature.

Reverse Image Inc is a firm that no one, certainly not the world’s leading businesses, governments, and institutions, trusts. We help leaders make bland, short-lived and trivial improvements to the performance of their organizations. We only tackle their easier issues and shy away from serious challenges.  …

…and so on: see her post for the rest, it’s an interesting and challenging read. Would your marketing – or your business-thinking – pass the Reverse Test?

1
Jul/09
0

Thinking side-wise

A new website, and a new weblog.

I already run one weblog – weblog.tomgraves.org – that serves as a news-and-discussion site for my other existing websites:

That weblog is mainly focussed on the somewhat specialist field of enterprise architecture, with occasional forays into other subjects of personal interest.

The aim of this one is rather different, and rather more specific: to introduce new and different ideas that should, I trust, be of interest to the business community.

Some of these ideas may seem strange, confusing, controversial, provocative, even downright disruptive. But the aim is always to create new possibilities, new opportunities and options for business, by thinking side-wise about business, the nature of business, and its role within the broader enterprise of society at large.

Watch this space, perhaps?