15 years ago Compaq & DEC (now Hewlett-Packard) setup its Europe, Middle East & Africa centralised Technical Support Centre (naturally it wasn’t called that – it had to be called by a TLA – so it was known as TSC). The TSC had high ambitions of solving many of the intractable problems associated with 14 different countries having 14 different ways of doing the same thing – fixing product and process failures for 25 million customers.

Unfortunately, and somewhat predictably, what it initially did was spend millions of dollars industrialising the existing mess while simultaneously disenfranchising the local subsidiaries – time to hire a new sheriff! – Or could this be a case for distributed cognition?

What do you do when every technician needs to be able to resolve any problem on any of the following: Intel based PCs/servers; DEC Alpha servers; VMS, UNIX or Windows operating systems, Tandem NSK super computers (DAX & NYSE); from customers calling from home; from the London Stock Exchange; from Daimler Benz; from CERN; from ABB; in fact from literally thousands of possibilities, and nobody knew until they picked up the phone who would be calling nor about what.

The key to this level of expertise was not to try to have super-hero technicians, instead what was needed was a way to share knowledge between domain experts, i.e. distributed cognition. Interestingly, the key guru on NSK lived in a log cabin in Sweden and the main VMS guru lived in rural Vermont in an almost equally inaccessible location (15 years ago cell phone coverage was probably 1% of today’s). Also, by design the problem solving system had to be built around a single dominant objective: to minimise the time to solution. Given this it had to be accepted that product or environment complexity were not considered in distributing work (no IVR) – any technician had to be able to do it, well actually had to be able to orchestrate doing it.

 

Distributed Cognition

The inspiration for centralisation and consolidation came in large part from The Knowledge-CreatingCompany: How Japanese Companies Create the Dynamics of Innovation (1995) by Ikujiro Nonaka and Hirotaka Takeuchi. This work was topical in the Tech industry at the time (1998) particularly its challenging assertion that: “…a company is not a machine, but a living organism…” At the time there was still the pervasive view that Japanese companies had cracked sustainable innovation, and this book seemed to offer American leaders a way to emulate that success. However, there was a huge cultural dimension to the Japanese worker which was poorly understood in the West. US companies had little time for any culture that wasn’t outcome-oriented, i.e. there was a strong tendency to measure performance by what was achieved without due regard to how it was achieved.

Nowadays “how” gets a lot more focus and it is typically written into most goals, however in the end good results = good performance, which is great when all is going well because sustainability isn’t the problem, at this stage capacity trumps capability. By the time an organisation moves from the frenzy of innovation to the drudgery of mass delivery, for example when there’s nothing really compelling about version 5 and the cheaper Korean look-alike is just as good, then everything is about efficiency, repeatable high quality and cost cutting. That means consolidation of back-office functions and relocating the work to cheaper locations such as Fargo, or Dublin, or Bangalore, or Bratislava, etc. and maybe some combination of all these. Cutting cost is relatively easy, what’s not at all easy is cutting cost while improving performance – that was the job I was given.

 

Building a Knowledge-creating Organisation

“We can know more than we cantell” (The Tacit Dimension, Michael Polanyi) as I recently discovered when I tried to explain to my nine-year-old daughter how the eToll on the East-link Bridge works. Compaq’s TSC is the authority whose sole purpose is the transmission of knowledge from the informed to the naïve. As defined by Polanyi this authority is both general and specific: general authority creates the proper structures for managing knowledge and specific authority empowers individuals to add to, or to modify existing tenets. This authority structure is the very antithesis of script-led customer support. From a technician’s perspective, provision of a meaningful answer is much easier when it is allowed to emerge in a controlled way guided by expert feedback.

 

Intuitively it seems rational to believe that if technicians pool their knowledge and stop solving the same problem from scratch a thousand times every day, that’s an improvement that everyone could buy into. Eventually that was proven to be true, however unlocking that truth involved a three year culture metamorphous – going from the caterpillar of “I am what I know” to butterfly of “I can know so much more when I share my knowledge”. The two states are as different as caterpillar and butterfly and the transformation is almost as mysterious. The role of the knowledge worker is converting know-how from the tacit to the explicit for customers who then re-form it to tacit for themselves. During this process pertinent individual knowledge is discovered, packaged and verified for future consumption at the group, organisation or inter-organisation level. This explicit knowledge has been filtered from the corporate body of tacit knowledge under the guidance of the consumer to create the corpus of Compaq-specific solutions. In this process the unit of analysis moves from the level of the employee to the business unit (TSC) – very reminiscent of Hutchens’ cockpit but on a much grander scale.

 

“…In particular, one asks how information is represented in the cognitive system and how representations are transformed, combined, and propagated through the system (Simon, 1981). Cognitive science thus concerns itself with the nature of knowledge structures and the processes that operate on them. The properties of these representations inside the system and the processes that operate on representations are assumed to cause or explain the observed performance of the cognitive system as a whole…”

The true implications of this would take a further three years to materialise. By far the most important was the concept of documenting solutions in the workflow in order to add the richness of context to the solution and especially to have the key insight(s) validated by real customer requirements as opposed to those conceived by specialists in the absence of a real user (Hutchins’ processes that operate on knowledge structures). The background to this approach comes from Craik’s somewhat academic, but highly applicable: The Nature of Explanation, 1943, for example:

“…if an organism carries a “small-scale model” of external reality and of its possible actions within its head, it is able to try out various alternatives, conclude which is best of them, react to future situations before they arise, utilize the knowledge of past events in dealing with present and future, and in every way to react in a much fuller, safer, and more competent manner to the emergencies which face it…”

This is exactly the desired approach in the TSC where each solution becomes part of the “small-scale model” whose reality is validated by the conscious inclusion of context in the knowledge article. The reuse process where actual customer requirements identify the “various alternatives” is the mechanism whereby the best alternative is identified and used to “react to future situations before they arise”.

 

Starting Again

As the year 2000 dawned Compaq’s TSC could be best summarised as follows: a well-informed strategic decision had been made, investment followed, mistakes were made and recognised, and a belief existed that creating a knowledge centre was a worthy ambition. Going from the original 14 KPIs to 3 was a good first step, and having a design philosophy of creating an organisation that’s optimised to minimizing time to solution was a good second step, the third step would be to build the work systems.

There was (and still is in many organisations) a belief that a knowledge-creating organisation could be created by combining people, training and systems. The fact that culture was largely ignored was to be near fatal. As Nitobe put it in Bushido: Knowledge is acquired when it is integrated into one’s “personal character”. The journey to bushido got underway in 2000.

In my experience, what gets documented in case management tools is generally worthless. But even more importantly people allow themselves to be driven by the tools. This unnatural style prevents effective problem solving. The answer to this problem was to escape from the tools-driven trap to what we would eventually call Knowledge Centred Support or KCS. We had to develop a structured and disciplined standard operating model to ensure knowledge articles created in one group could be reused or enhanced by any other. In KCS everyone had a responsibility to use an existing solution where ever possible, but when necessary an existing solution could be modified as new information became available or a new problem was encountered. This might result in an improved existing solution or a new one. This creates the processes and prepares the culture where representations can be consistently and effectively transformed, combined and propagated.

Cognitive Artefacts – The Knowledge Article

Once again referring to Polanyi. “…how a problem gets posed…” is half way to solving it. In the KCS architecture the capture and representation of knowledge was reduced to six parameters:

1. Targets – what is the customer trying to do or achieve

2. Facts – get over the emotion, what are the facts – system, version, configuration, etc.

3. Symptoms – how is it behaving or failing to behave

4. Changes – last known good state, upgrades, outside connections, etc.

5. Cause – upgrade, new users, environment, etc.

6. Fix – probably most important item but often omitted because the problem is resolved!

Keeping to this discipline for knowledge structures (known a ‘knowledge articles’ in the Compaq system) meant that all solutions had the same basic form and were amenable to transformation, combination and propagation throughout the system.

Knowledge Transformation & Combination

The idea of codifying and capturing the knowledge of the technical community was initially viewed with extreme scepticism. It was assumed that this was simply the big bad capitalist stealing the know-how of the lowly technician. The most common response was: “…if I cooperate with this I’ll give away the very thing that makes me valuable in the marketplace – my technical knowledge…” followed by “…why should I help **** team…” etc. The retort that by handing over the answers that you know, to free you to develop ones that you don’t yet know, fell on very deaf and sceptical ears. There was far more involved than representing information in a knowledge system.

It took a further six months to work through the emotional side of creating a new cognitive model. Initially technicians spent hours documenting the customer issue and solution after the call, or often after the day’s work. They took great pride in their work and the more complex the issue the better. The result was a problem-solution pair that was so closely matched that it was almost unique – so impossible to reuse. There are two problems here: 1. only documenting complex/interesting issues, and 2. documenting the solution after the event. Technicians were working in a new system in the old way – they were high performing individuals but the system was not. As noted above the key to both was to document the solution in the workflow. The transition from reactive, on the fly, problem resolution to embodying the full customer-machine-problem-objective in a reusable knowledge article required the technician to internalise the full context and to see the technical solution as a minor (but critical) component of getting the customer up and running again. According to The Knowledge-Creating Company (pp69): “Internalization is a process of embodying explicit knowledge into tacit knowledge”, the tacit knowledge that is so hard to expose. Once exposed, this tacit knowledge is once again made explicit in combination with the full problem context to create massively reusable solutions. Within months a unique and incredibly efficient problem solving organisation would emerge, one that’s still there despite intense off-shore competition.

Embodied Cognition

At the early stages embodiment was not a concept that was top of mind for most of us, but it would find its way to the top as we saw a remarkable transformation in technicians’ working practise: they embodied the product in their customer interaction. A technician would literally be on the ground looking up at a real or imaginary cabinet release lever of a mass storage device as he guided the customer, or she would build an imaginary TFS as she guided a developer through creation of a sprint build. The antics were often hilarious and people felt totally immersed in the situation and were often emotionally exhausted after interaction.

Not only that, customer satisfaction also improved due to the technicians’ level of emotional engagement (previous work had established that empathy was the third key to success in a support centre). The key point is that there was a known discipline for transformation of representations. This discipline was very reassuring for customers and the very high solution hit-rate meant their problem was resolved much faster.

Accepting this guiding principle meant accepting that the support technician had to be able to integrate knowledge from multiple sources at will. Interestingly, it also meant that that same technician had to be able present specialised knowledge to colleagues so that they could then present it to their customers. To facilitate this, all knowledge articles were independently reviewed, proofed and had the language standardised to technical English.

Once again, a very strange outcome emerged at a team level: each team used its own solutions more frequently than any others’. The reuse rates for the UK/Irl team and the French team demonstrate this (the exact same phenomenon was observed for Dutch, German, Finish, etc.) What’s remarkable is that there’s no way of knowing the origin of a solution since its structure, language and nuances are all independently standardised – so why would own-team reuse be so pronounced?

A general assumption of the distributed cognition approach is that cognitive systems consisting of more than one individual have cognitive properties that differ from those individuals that participate in those systems. Through the adoption of KCS the cognitive properties of the language-focused support team emerged.

“…one can adopt different units of analysis, to describe a range of cognitive systems, whereby some subsume others (Hutchins, 1995). One can focus on the processes of an individual, on an individual in coordination with a set of tools or on a group of individuals in interaction with each other and a set of tools. At each level of description of a cognitive system, a set of cognitive properties can be identified; these properties can be explained by reference to processes that transform states inside the system…”

A Brief Introduction to Distributed Cognition©

Yvonne Roger

The particular characteristics of both the problem solvers and the incoming problems differed significantly from team to team – it seems a French problem-solution pair is characteristically different from any other pair. On page 97 of The Harvard Business Review of Nov-Dec 91, Nonaka explained this, he says: “At the same time, tacit knowledge has an important cognitive dimension. It consists of mental models, beliefs and perspectives so ingrained that we take them for granted and cannot easily articulate them. For this very reason these mental models profoundly shape how we perceive the world around us”, i.e. the French beliefs and perspectives matter even in the dry technical arena of IT.

How representations are transformed and propagated through the system

Before the introduction of KCS we created thousands of solutions (articles) every day, after KCS that reduced to 10 to 20 per month, but with about 16,000 reuses of existing solutions. The graph shows the remarkable take off in reuse after a full year of practically no progress. Why did reuse go from about 200/month to 14,000/month in just six months? The implementation of KCS was planned and deployed firstly in a pilot group to hone the principles and processes and to work out how best to manage the change. The pilot explains the first six months, when reuse actually dropped due to the effort to seed the database with representative solutions. The second six months is much more interesting. This is the centre-wide transformation from reactive individual call centre agent to knowledge creating teams. There is a slow adoption phase where the reuse rate goes from about 2:1 to 5:1. As this happens the whole dynamic changes and both employees and customers experience the impact of distributed cognition – the result is remarkable, reuse rockets to 1,000:1.

Two years into the project the Dublin TSC merged its database with the North America TSC and began to reuse their solutions. At the same time the US technicians had access to EMEA solutions. The Dublin teams were immediately able to consume knowledge articles from NA but the US team was not able to reuse the EMEA content despite its being 100% English language and the user base being identical. The reason: KCS in the US never elevated from the technician level to the team level.
 

These four graphs represent the culmination of a four year journey from chaos to a sustainable innovative system that gave the best balance of cost, customer satisfaction, productivity and speed. Fifteen years on and the centre is still in Dublin despite competition from Bangalore, Dalian and Costa Rica. The workforce has increased to 1,000 and it still continues to amaze with its low staff turnover, record levels of productivity, high customer satisfaction and lowest cost per event in HP.

Looking back on performance of the system after a number of years it was interesting to see how knowledge harvested by various technicians had remained in the system after their departure. The image shows the names of a number of technicians and the date they left the organisation.  The blue column shows the number of solutions they created and the row after their name shows the number of reuses after they left. In effect the system, i.e. TSC, carried on using their knowledge long after they left it. This is evidence that we had transcended the individual and achieved the sustainable innovation system that was the design goal.