JUST SAY THE WORD - Michael Ballé explains why front-loading engineering means planning product renewal years ahead, and how Toyota's Chief Engineer role balances business, design, and technical expertise through influence, not hierarchy.

Words: Michael Ballé

Roberto Priolo: Front-loading engineering asks teams to invest more time learning before making decisions, but in today's world many organizations feel pressure to move as fast as they can. How do we convince leaders that slowing down at the beginning is actually the fastest way to develop successful products?

Michael Ballé: The secret is in product planning, not product design. Most companies push engineering work forward: they see a product weakening on the marketplace, imagine its replacement and, of course, are now in a hurry to bring it to the market to support revenue. Everyone knows new product development is difficult and that decisions need to be made, so leadership takes an interest and gets involved in design decisions without fully understanding the consequences. I remember the CEO of a company making fuel dispensers in gas stations (the pumps we stopped at to fill your car in the days of ICE cars), who one day came back from a trade show convinced the look of the entire machine had to be redesigned to give it a rounder, more fluid appearance. (Picture a fuel pump. Now imagine it with a plastic rounded shell and see how people will use it daily to fuel their cars… you’ve got the picture). This created a major redesign project for the company that in then end went nowhere. However, in the meantime, engineers weren’t working on fixing issues with actual pumps already on the market, being used by actual customers.

In Lean, product planning means deciding at what rhythm you will renew your existing products. Toyota will launch a new version of a car every four years. Apple will launch a new phone model every year, with a cheaper “e” version mid-year. With this in mind, you can look at your product line-up and plan when the next version of each product will be launched. If you start from a firm date for the next product launch, say in four years for the next version and in eight for version n+1, and that is written in stone — nothing barring world catastrophes will change that — then you can start planning.

Say we’re going with a new product every four years. We can think in terms of:

• One year after launch to iron out the kinks and see how the new product fares on the market.
• Name a chief engineer for the next version three years before launch and give them time to explore the next version’s concept, on the gemba with customers, with new technologies and so on.
• Explore design issues for one to two years until most problems are solved upstream of producing detailed engineering drawings and leading to design freeze (what the product will look like and what will be inside it).
• One to two years of producing the actual engineering drawings both on the product and process fronts that lead to start of production.

This is more a way of thinking than a set process, of course. We’re talking about engineering here, not production — but it gives you a rough outline of how to think about a product release. It’s very similar to the writing process of authoring a book: you mull on the topic for years, then you spend a year or two clarifying the issues you want to speak of and you think people will be interested in, then comes the actual writing and finally the preparation for printing and launch.

The point is this is intellectual work: having firm deadlines for key milestones is very useful, but pressure on getting upstream work done quicker is counterproductive, as issues remain whether you solve them or not. You don’t “invest” time in upstream exploration and decision; you set it up as part of your full product schedule from one model to the next.

Design moves fastest when it is driven by good product planning rather than last-minute design decisions. Instead of waiting for a product to struggle in the market and then rushing into a redesign, lean companies plan product renewals on a predictable schedule and work backwards from fixed launch dates. This gives teams time to learn from customers, explore new technologies, solve key design challenges early, and complete engineering work without unnecessary pressure. Thinking, exploration, and clarification happen long before the final decisions are made. This is much faster than having to fix the mess created from poor understanding upstream and nonsensical decisions made under time pressure.

To answer the question simply, you don’t “invest” in front-loading time. You plan it in to reach the launch deadline with the right product and the right production methods for it to be a success.

RP: The loudest voice in the room often outweighs technical knowledge. How does front-loading engineering create a process where customer needs and engineering facts carry more weight than hierarchy?

MB: The boss might not always be right, but the boss is always the boss. That’s a fact of life. So yes, in most meetings, HIPPOs (Highest Paid Person’s Opinion) count and will influence design decisions, whether we like it or not. Toyota’s unusual solution is to create the role of Chief Engineer, the person who puts the whole product together and is ultimately responsible for its success or failure. A Chief Engineer is the “CEO of the product.” Unlike a traditional project manager, the Chief Engineer has overall responsibility for the success of the product from the customer’s point of view. They define the product vision, understand customer needs, make key trade-offs between performance, cost, quality, and design, and coordinate the work of many different engineering teams. However, they do not directly manage all the people involved, they are accountable for ensuring that the final product delivers value to customers and achieves its business goals.

One of the most interesting aspects of Toyota’s Chief Engineer system is that the Chief Engineer does not have direct authority over the functional specialists working on the product. Engineers, designers, and other experts still report to their functional managers, who are responsible for developing technical expertise and allocating resources. The Chief Engineer leads through respect of his vision, experience, and influence rather than hierarchy. To move the product forward, they must build trust, deeply understand customer needs, and convince specialists that their proposed solutions are the right ones. In this sense, the role is less about giving orders and more about aligning people around a shared product vision, making “leadership through persuasion” a critical part of the job.

Senior management will intervene at the product-planning level and review the project at a few important decision gates, such as concept approval, design freeze, and launch readiness. Between those checkpoints, they do not step into every technical debate. Instead, they trust the Chief Engineer to wrangle it out with the heads of the design and engineering functions, balance different priorities, and find solutions that support the overall product vision. This keeps leadership focused on major business decisions while giving the people closest to the work the space to resolve problems properly.

The smart thing here is seeking a healthy balance between leadership authority, specialist expertise, and a clear product vision. Senior management decides which products to develop, approves major milestones, and ensures resources are available, but avoids getting involved in day-to-day technical decisions. The Chief Engineer owns the product vision and is responsible for making sure the final product delivers value to customers but has very little formal authority over the specialists working on it. Those specialists remain under the leadership of their functional managers, who are responsible for maintaining deep technical expertise. As a result, the Chief Engineer cannot simply give orders; they must persuade, build consensus, and demonstrate why a particular solution is best for the product. This prevents senior leaders from imposing uninformed decisions, protects the quality of technical expertise, and ensures that all functions are aligned around a single product vision rather than optimizing only their own departmental goals.

The balance between authority and influence is always tricky, as well as between technical expertise and business know-how. In many SMEs, for instance, we get the reverse situation in which the “chief engineer” (the guy who knows all about the product and the technology) is the boss. These companies then fall on the other side of the issue and create excellent products (just the way the CEO wants them) that don’t sell, because little thought has been given to market, distribution, marketing and every other job needed to create a successful, profitable product.

The genius of Toyota’s approach is seeking to balance natural opposites — such as business-driven decision, market-smart design and nitty-gritty technical details — to make it all work. Business leaders focus on strategy, finance, and market opportunities. The Chief Engineer focuses on customer value, product vision and product architecture. Functional specialists focus on the technical details needed to make the product work reliably and efficiently. Each perspective is necessary, but each can also become a problem if it dominates the others. A product driven only by business considerations may sell quickly but disappoint customers. A product driven only by design may look great but be too expensive or difficult to manufacture. A product driven only by engineering may be technically brilliant but fail in the market. Toyota’s insight is that great products emerge when these different viewpoints are forced to work together, challenge each other, and find practical compromises. I once asked a Toyota chief engineer the secret to a successful product. He thought about it and then answered: "Lots of conflict". Rather than work around unresolved issues and disagreements, the idea is to use conflict productively so that business needs, market understanding, design choices, and technical realities all come together in a product that customers actually want and that the company can profitably build and sell.

The funny thing is that none of this works if your engineers are brilliant technically but impossible to work with. Toyota’s system depends on developing engineers who are confident enough in their expertise to defend their ideas, but mature enough to listen when others have a point. A Chief Engineer cannot just pull rank, and a functional specialist cannot simply say “that’s not my problem.” People need to negotiate, influence, argue constructively, and manage conflicts without turning every disagreement into a turf war. The goal is to make better decisions rather than win arguments. In a way, Toyota is not just building cars; it is building engineers who can balance competing viewpoints, respect different expertise, and find solutions everyone can live with. The technical challenge is not always the hardest part; the real challenge is getting smart people with different priorities to agree on what to do next.

_THE AUTHOR