Dear Gemba Coach,
Should A3s be used for solving organizational or technical problems?
Both. Neither. I’m not sure A3s are about solving problems as much as communicating your solution or investigation to other stakeholders. I think it’s preferable to think of the A3 as an A3 report – reporting the problem-solving process, from the framing of the context, to the analysis to the root cause, to the envisaged countermeasures, to the implementation plan, to the check, to what is needed to standardize the answer.
Let’s backtrack a bit. A natural reaction, when confronted with a mistake, is to ask “who made that mistake?” – and then blame the person for either poor thinking or dubious intention. If I remember correctly what Isao Yoshino told me, (I could be re-interpreting) Toyota wanted to move their managers away from blame to assuming that people were trying their best but their thinking was off. If you want to figure that out, you need to know where they took a wrong turn in their reasoning (however, when people refuse to share their reasoning, the question of intentions remains open). It’s logical to then ask: “what is the main cause of the problem?”
The point of A3 reports were as regular presentations to department heads having question-and-answer sessions with their direct reports to train those managers in logical thinking. The best reports were those presenting mistakes or reporting bad news, a key part of Toyota’s culture so that it is okay to present unfavorable information and challenge the thinking, both up and down the chain.
No problem gets solved by one person alone is an important insight underlying A3 reports. Problems, particularly in complex organizations, need people to cooperate on countermeasures and a good A3 report that demonstrates that we seek clear gains through a persuasive logic is key to getting other people on board. It was also much better than discussion as a way to draw out objections and correct misconceptions. For instance, this is how I use these Gemba Coach columns – I listen carefully when people tell me that I’m wrong about this or that and try to figure out what this person knows that I don’t or sees what I don’t see.
Quite naturally, when hearing about what someone wants to do, you try to figure out:
- What are they after?
- Where do they expect to find the gain?
- What method do they think will do the trick?
- How they’re going to implement it and with whom?
- How will they know if it’s working?
- What else needs to change if we want to standardize their solution in the future?
Which is what the A3 eight steps get you to clarify:
- What indicator are we looking to change and in what context?
- Where does the current process go wrong?
- What is our target for improvement?
- What do we think is the root cause of the problem?
- What are the various countermeasures that we have explored?
- What is the implementation plan?
- What results are we seeing?
- What conclusions do we draw and how could we standardize this learning?
Winners and Losers
Obviously, it’s tempting to use this logic for any complex problem and in particular for organizational problems. This is a mistake I’ve made myself several times. I’m slow to take the lesson, but I’ve been caught off guard repeatedly by how things go from bad to worse as you try to clarify an organizational problem with an organizational solution. With any organization change, there are people who see themselves as winners and others as losers, and, well, things often get sticky.This is something that is appearing in all the research about engaged teams: people need to feel they are safe to disagree with what is being asked of them or the analysis they are shown, so they can think for themselves.
Looking back, here’s what I’ve learned:
- Most organizational problems are caused by working around a technical problem. There’s something we don’t know how to do technically, so, being busy bees, we invent creative solutions to organize around that – which tends to code our non-competence into the system. What was a bug becomes a feature.
- When you do solve the technical problem, if you do, you then indeed need to change the organization to make this solution sustainable. If you don’t the elastic forces of status quo will smother your new solutions, and we can read in the press every day where that leads – the Kodak/Nokia syndrome.
- Addressing the organizational problem first tends to blow up in your face, as you often get people face to face with the technical problem they don’t know how to solve, and hence outline solutions which they won’t know how to implement. They really don’t like that, and won’t like you.
The learning point, I guess, is to solve the technical problem first, which often needs political backing, and we’re back to the organizational problem – nothing is ever easy. But certainly, without understanding in detail the mistakes in the current technical process, it’s really dangerous to wade into the organizational mess.
Ultimately, the really, really difficult part is “problems first,” or “bad news first.” I was once told by an ex-Toyota manager that the culture was really about going to the source to listen directly to employees, visualizing issues, and asking why in order to seek root causes and countermeasures and – most difficult – make it easy to convey unfavorable information to management. This is something that is appearing in all the research about engaged teams: people need to feel they are safe to disagree with what is being asked of them or the analysis they are shown, so they can think for themselves.
As I understand it, using A3 systematically in the early days in Toyota was about creating such an atmosphere by refocusing on technical problems (a typical A3 was “why does this machine break down so often?” or “why do we get 2% scrap with this process when we get 2 per thousand on other similar operations?”) and then move on to change middle-management thinking and procedures to enhance management’s overall level. This process will, in the end, strengthen the whole organization by building its human capital.
But it starts by solving the technical problems first.
