Last week I shared this principle quoted from an unexpected source, the U.S. Marine Leadership Manual: “An individual’s responsibility for leadership is not dependent on authority.” I’ll use that as our point of departure this week to continue with my thesis that the deep-rooted assumption that authority should equal responsibility is the root of much organizational evil. I believe misunderstanding around this issue is rampant, problematic, and runs so deep in our consciousness that we don’t even realize it.
The quote from the Marines draws fascinating parallels with the way I saw the dynamics of responsibility and authority work at Toyota in Japan in the 1980s, which we’ve discussed here before, will again today, and again in the future (it may become clear that I think this is an important matter).
The clearest place to see how this works in the Toyota organization – or anywhere I know of – is embodied in the role of the Toyota Chief Engineer (or CE), Toyota’s product development “shusa system”. Let’s take a look at what Toyota’s traditional Chief Engineer system looks like (there have been changes over the past 15 years, but the essence of how it works surely remains the same).
As you can see, it looks like a matrix. It is a matrix. But, the “software” or organizational operating system behind it is radically different.
Across the bottom you see the various operating functions. Silos. Stovepipes. These function as vital storehouses of deep technical knowledge and competence (thus many companies call these “centers of excellence”). Cutting across, are the product lines or value streams, creating value from the perspective of the customer, while ensuring profitability for the company, for the product line. When I encountered this (as I mentioned, there have been changes since then) there were about 15 functional engineering departments and, coincidentally (?) about 15 vehicle programs going on at any time. For a given program, a CE would need to direct the efforts of about 10 major functional departments.
Conversely, a functional department general manager would have to support the work of all 15 programs, but only about half of which would require intense support at any one time. (See chapter 8 of Toyota’s Product Development System by James Morgan and Jeff Liker from Productivity Press for a great description of how Toyota’s Chief Engineer system works. See Chasing the Rabbit by Steven Spear from McGraw Hill for an enlightening discussion of the reality that modern matrix systems now have too many silos that are too deep in specialization for any one person to manage in a traditional way.)
What’s structurally unique about Toyota’s product development matrix is that almost no one reports directly to the Chief Engineers (just a small support team). All the headcount lies in the functional silos. The performance appraisals of the engineers doing the work is conducted by the functional managers (with input, however, from the Chief Engineer).
And the point is … ?
At issue here is a very fundamental matter: how decisions get made. In a traditional functional/hierarchical organization:
– Position establishes (or seems to) authority to make decisions.
But, in cross-functional organizations – where almost all of us reside – this mental model will cause confusion, frustration, and breakdown of the decision-making process. That thinking will cause precisely the frustration and confusion that so many of us experience everyday in our organizations.
In a value-stream or lean-learning organization:
– Position establishes responsibility to get decisions made.
Discovery
Working at Toyota frequently exposed me to things that seemed simple enough on the surface but upon deeper reflection revealed profound insights into how organizations and processes work. In 1991, I was transferred from Toyota Japan to become general manager of administration for the just-expanding Toyota Technical Center U.S.A. in Ann Arbor, MI. My new assignment required a crash course in understanding Toyota’s product development world, which was quite different from the Toyota I knew. So I began my new journey with a deep dip inside the technical centers in Toyota City and Higashi Fuji.
One thing I thought I knew about Toyota’s product development was that Chief Engineers were kings. Toyota is remarkably egalitarian once you get inside. There is hierarchy, to be sure. But Toyota’s promotion process rewarded experience, ensuring that almost everyone would eventually achieve a rank with substantial stripes. All in all, much effort was expended to ensure that we all knew we were in the same boat. Chief Engineers, though, were surely different. Or so I thought. (Speaking of “egalitarian”, by the way, glamorous Chief Engineers received roughly the same pay as the lowly foremen on the assembly lines that built their cars.)
So, imagine my surprise the first time I heard a Chief Engineer say, “I have no power.” I heard it a second time and considered that it might actually be true – I was already familiar with how the “responsibility versus authority” dynamic worked out in other parts of the company. But, at the same time, the Chief Engineer was surely the most powerful person in the company. The third time I heard it was from a functional department manager who stated, “We can say ‘no’ to the Chief Engineer if we think he is heading in the wrong direction.” This was fascinating – a real archetype of the dynamic of leading with no power, of clear responsibility without simple positional-based authority.
So the Chief Engineer has no choice but to lead by the soft skills of true leadership. By soft skills, I am referring to the suite of skills written of in books about leadership or management books and taught in leadership training – characteristics such as “leading through influence” or “servant leadership” or “win-win negotiating”. Choose your favorite. For the CE, those characteristics and skills are not optional. He is unable to simply pull rank, to put his foot down and demand that the functions do as he demands. Functional resources can and do tell him “no” if and when they have a good reason. He can only lead by being knowledgeable, proposing good ideas, expertly negotiating multiple priorities and wishes, and being very strong. In short, he has to lead by exercising true leadership skills, not relying on the authority vested in him by virtue of his position on an organizational chart.
Wow. Sounds like a tough lie, yet Toyota vehicle programs at least up to that time almost always came in on time and with desired profitability and market performance. How did this come about?
Creating a Process
Toyota’s first Chief Engineer, who led the development of the company’s first true passenger car, the 1966 Crown, was a remarkable man named Kenya Nakamura. By all counts, he was as irascible and demanding as the much more famous Taiichi Ohno was in manufacturing. Also like Ohno, he was sponsored by Eiji Toyoda – both Ohno and Nakamura stated on numerous occasions that they never would have been successful without Eiji’s full support.
Also, like Ohno, others around him were not necessarily so enamored with his demanding and unconventional ideas. Nakamura once angered a board member so greatly (accusing the executive, in front of other board members, of having “no dreams” for the company) that he was demoted, which made him a member of the union. As a union member he promptly accused union leadership of trying to destroy the company because “all you do is complain”. The union leaders responded by ordering membership to refuse to talk to Nakamura, so for a time no one in the company was even sure if Nakamura was union or management! A passionate leader, to be sure.
But, it was his lieutenant Tatsuro Hasegawa who codified the behaviors, the leadership characteristics and practices that make a good Chief Engineer, the enabling x-factor of a system in which the leader has no real power, no “authority.”
Hasegawa had joined Toyota from the aerospace industry, where he had learned a “chief engineer” process that was similar to that which Toyota eventually adopted (though he observed that Toyota eventually took the process even further than did the aerospace companies). From a combination of his previous experience combined with his observations of Nakamura’s success (and, I hazard a guess, his failings), Hasegawa gives us yet another list of what we might call “management principles” or traits (my translation from old Toyota Japanese language documents):
- Gain broad knowledge and point of view
- Develop a clear vision
- Conduct research that is broad and deep
- Apply knowledge and skill toward achieving concrete results
- Persistently repeat each task as necessary – never give up
- Have confidence, believe in yourself
- Never delegate responsibility
- Create alignment with lieutenants and other key people
- Never take the easy route to make it easy for yourself
- And possess these characteristics: i. have right knowledge, skill experience; ii. be decisive with good judgment, iii. have generous spirit and think big, iv. be composed, not overly emotional, v. be vigorous, vi. be tenacious, vii. be a leader who others wish to follow, viii. possess strong skills of communication and persuasion, ix. be flexible, x. exhibit unselfish dedication to success.
CE Hasegawa, in addition to giving us the 10 principles of a Chief Engineer, was also CE of the first Corolla, regarding which he famously declared the company’s goal to:
“Utilize the Corolla for the happiness and well being of everyone on Earth.”
It’s my belief, by the way, that Eiji Toyoda knew exactly what he was doing when he structured things this way, giving overwhelming responsibility to the Chief Engineer yet maintaining the essential autonomy of the functions. Eiji created the new position, called “Shusa” at that time (the term was officially changed to the English Chief Engineer about a year before I joined the product development organization in 1991), just for Nakamura, a position “outside the organization” as Hasegawa later described it. This framework provided tremendous flexibility and also instilled beautiful checks and balances to ensure that programs or the company would not go off the deep end due to too much influence from any one person or function or department.
So what?
So here’s a caution. Remember that the Chief Engineer system – just like all Toyota processes – is a solution to a problem. To understand them properly it’s necessary to go back and consider what problem Toyota was trying to solve? That’s how we can all always develop appropriate solutions to our own problems. At issue is not just how to copy Toyota’s solution to its problem (sometimes copying is a fine way to get started, however – more on that in a future column) but to consider how Toyota’s solution to its problem can inform our solution to ours.
First, let’s review the problem. If the focus of a lean organization is the horizontal flow of value, as overseen by a responsible person, yet there are strong functions, how do those doing the actual work avoid the dreaded “two boss” problem?
Organizational Structure – Choose your poison
- Functional Organization
- Invented by GM (with much borrowing from DuPont, and no doubt some others)
- Provides functional excellence
- Encourages silo “dysfunctional” operation
- Business Unit Structure
- Aligns resources under one responsible individual
- Provides alignment and direction around the product
- Also results in silos of its own
- Results in redundancy of resources and loss of functional excellence
We all hate the organizational matrix. And our usual response is to wish it would somehow just … disappear. Or, if we can garner the clout, to try to make it disappear. So, we reorganize, perhaps turning the organization on its side, placing resources along the flow of work of product or service lines.
But, in the end, such organizational fixes are just band aids or short-term fixes that lead to their own problems. Instead of a reorganization, perhaps a better countermeasure might lie in the software of how we get our organizations to operate.
In closing, lest you protest, “Sure, Toyota can do that, but it would never work here…” please recall the quote we began with from the U.S. Marines: “An individual’s responsibility for leadership is not dependent on authority.” I think the issues are only (1) the recognition of the need, (2) the decision to try, and (3) the will to make it work.
