Does authority in an organization line up neatly with responsibility?

Not according to the U.S. Marine Corps Manual, which states, “An individual’s responsibility for leadership is not dependent on authority.” Not in in my book Managing to Learn, either; for I believe that the deep-rooted (and largely flawed) assumption that authority should equal responsibility is the root of much organizational evil. 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. The clearest example of how this works at Toyota–or anywhere else I’ve seen–is 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 5 of Designing the Future by James Morgan and Jeff Liker for a great description of how Toyota’s Chief Engineer system works. See also The High-Velocity Edge 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 are conducted by the functional managers (with input, however, from the Chief Engineer).

How Do Decisions Get Made?

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.

Discovering Who Has Power (Or Not)

"The Chief Engineer can only lead by being knowledgeable, proposing good ideas, expertly negotiating multiple priorities and wishes, and being very strong. In short, they must lead by exercising true leadership skills, not relying on the authority vested in them by virtue of their position on an organizational chart."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 processeswork. 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, Michigan. 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. They are unable to simply pull rank, to put their foot down and demand that the functions do as they demand. Functional resources can and do tell them “no” if and when they have a good reason. The CE can only lead by being knowledgeable, proposing good ideas, expertly negotiating multiple priorities and wishes, and being very strong. In short, they must lead by exercising true leadership skills, not relying on the authority vested in them by virtue of their position on an organizational chart.

Wow. Sounds like a tough lie, yet Toyota vehicle programs at least up till then 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 1955 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: have right knowledge, skill experience; be decisive with good judgment, have generous spirit and think big, be composed, not overly emotional, be vigorous, be tenacious, be a leader who others wish to follow, possess strong skills of communication and persuasion, be flexible, exhibit unselfish dedication to success.

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 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.

And this solution applies...how?

"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?" 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) 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.

The deeper question is whether Toyota’s exemplary system design, the CE being a case in point, can provide lessons for other companies. It’s worth noting two more things regarding all this.

Technical skills and social skills – equally important

The challenges to establishing the CE way of working are two-fold (more, really, but these two in addition to all the usual challenges associated with fundamental change in the way we work). The important takeaway from Hasegawa’s list of characteristics of successful CEs was the need to possess a set of equally important technical and social skills. Let me repeat, the technical and social skills are equally important. Not an easy balance for an individual to attain. But, the real challenge in implementing the CE system doesn’t end there. The bigger challenge is twofold:

Finding or/and developing individuals with that critical combination of technical AND social (including business) skills. Achieving recognition among your functional leaders about the both the role of the CE and their own role: The role of the CE is to provide the vision for the product, the vision for the company on behalf of the customer, The role of the functional manager is first to make the CE (the owner of the destiny of the product and customer) successful, Their role to create a work-class function must not preclude or interfere with their role of supporting the CE.

Engineering Chief Engineers

As I have seen organizations attempt and struggle with the CE concept, they have tended to focus on the first of those two, finding or developing individuals who could successfully possess the right set of skills. This is admittedly a formidable task. Toyota figures it takes 10 to 20 years to develop the full range of necessary skills.

"The important takeaway from Hasegawa’s list of characteristics of successful CEs was the need to possess a set of equally important technical and social skills."But, my experience shows that the second problem is actually the most difficult to overcome. You could call this organizational resistance. Part of the problem is simply that it is difficult to get people to agree to what they perceive as “giving up power”. Playing together can be difficult. Especially when the rules don’t encourage it. By “rules,” I’m talking the rules of engagement as measured by functional performance, not by value stream. If my bonus, as a functional manager, is determined by targets that are purely internal to the workings of my function, I can hardly be expected to change my behavior very much to accommodate the desires of a CE.

This takes us back to a fundamental question: what can you “rely” on, upon what is your basis of authority to lead, if not the authority of your position?

Many leadership discussions would now plug in a set of characteristics or skills, not unlike those of CE Hasegawa. While I won’t exactly disagree with the value of even ultimate necessity of those skills (such as the characteristics of servant leadership), I’d rather focus on identifying things that a person can try to do, rather than something to try to be.

I’ll suggest that the search for something simple and practical to do takes us immediately to…the gemba. After all, most of us aren’t going to be full-blown Chief Engineers. But, can the leadership styles and ways of working of the CE provide something of a roadmap for all of us?

All together, LPPD management as practiced by CE’s add up to what Al Ward called “management by science at the gemba.” (See Lean Product and Process Development by Al Ward and Durward Sobek for a discussion of the distinction between “scientific management” – often a simple search for the “one best way,” an approach that isn’t very “scientific” at all – from true “management by science.”)

And, together, they provide a means of escaping the management tailspin caused by belief that position provides authority and data substitutes for grasp of the true facts of the situation.

This relates to how we try to manage. We have very smart people in management here in the US or in companies anywhere. We are so smart, we think they can figure things out and determine direction from above, far removed in time and space from the gemba. At the same time, there is now a general acceptance – virtually NO ONE argues otherwise – that “command & control” is bad. Well, yes, command & control is the root of many evils. But, what is offered up as an alternative? (Managing To Learn, by the way, is my attempt to define an alternative.)

Another factor is our habitual beliefs and systems and actions around ‘measurement” (including incentive system design and bonus calculations) which continue to have us chasing our tails and focusing management time and attention on the WRONG THINGS. And I mean measurement at all levels. At the corporate level with an over-emphasis on quarterly returns, at the work level with a focus on narrow measures that lead to local optimization which HARMS system optimization, and at the individual level where will still pretend that money is the primary motivator of human behavior when we know from years of research that is not the case.

Instead of “command & control” - what??

Gemba-based leadership:

Not just laissez-faire – step out of the way, “it’s up to you”.

Not just MBWA – slapping backs and offering praise.

Not just MBO – okay, you’re empowered, get the numbers – I don’t care how you do it.

Rather, managers who say things like:

My job is to develop you, through coaching you on the job, so I need to hear your thinking.

I will give you expectations that are clear, challenging, and have a deadline.

I expect you to report out and seek counsel.

I will ask you what you think you need; I’ll observe to determine what I think you need and provide on-going support and coaching as required.

We will aim together for learning that is fast and deep.

“We’re all connected and nobody is in charge.”

That is Thomas Friedman’s way of describing the global “flat” economy characterized by money, goods and resources flowing freely from anywhere to anywhere. But, his phrase is also a good descriptor of how work flows – or doesn’t – in today’s complex organizations.



Everyone hates the “matrix”, as we explored above. Yet, having searched far and wide for many years, I have yet to find an organization of anycomplexity that does not need to achieve its most important outcomes through cross-functional collaboration.



The problem of managing organizations can be summed up simply:

One person – at the top of a pyramid – can’t tell 1000 (or 100 or 10,000) people what to do when.

Yet, equally true,no organization can simply let those 1000 people do what they want when they want.

From that simple conundrum comes virtually all complex organization and management theory, from Weber to Fayol to Schein to Sinek.

The shift from an “authority-based” to a “responsibility-based” (or “pull-based authority”) organization is a key underlying dynamic of the lean organization that can resolve that conundrum. Organizations are cross-functional in operation yet functional in structure, a fact that results in a matrix which typically leaves ownership unclear, decision-making stymied, and everyone frustrated. Leadership and the management system need to facilitate a shift:

From debate about who owns what (authority) to dialogue around the right thing to do.

That’s why lean managers avoid relying on their authority to instruct others, striving instead to lead by influence and example rather than simple command. As one of my boss/mentors at Toyota told me, “Avoid telling your staff exactly what to do; whenever you do that, you take responsibility away from them.”

"That’s why lean managers avoid relying on their authority to instruct others, striving instead to lead by influence and example rather than simple command."However, while good Toyota managers would rarely tell their people exactly what to do, it is equally true that they would never say, “I don’t care how you do it.” We see this all the time: “You are empowered. You are ‘empowered’, but you’re on your own. If you are successful, good for you – your bonus will reflect it. If you are not successful – your lack of a bonus will reflect that, too.” Contrast that with the lean manager who says, “I care deeply to hear what you want to do, and how you want to do it.” Avoidance of command and control does not have to mean laissez-faire abandonment.

We are all connected, no one is in charge and simple command & control doesn’t work, but we don’t see a viable way forward other than declare that “everyone is in charge” and essentially give up. We can refer to the Toyota Chief Engineer system, but that opens the door for the easy excuse of “...we’re not Toyota.” To that excuse, recall the quote 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.

(Learn more about the Chief Engineer system at the upcoming Designing the Future summit, which will be held on June 27-28 in Traverse City, MI.)