Scale Alone Does Not Create Better Vehicles

People often assume that the biggest organizations have the biggest advantage. More engineers, more departments, and more resources should naturally lead to better products. After spending many years working across technology and automotive companies, I have learned that it does not work that way.

Building a great vehicle is not a matter of adding more people to a project. It is about bringing together the right people, giving them a clear purpose, and creating an environment where they can make good decisions quickly.

As vehicles become more advanced, there is a temptation to respond by adding organizational layers. More complexity in the product seems to justify more complexity in the organization.

I think we should challenge that assumption.

Complex vehicles do not require complicated organizations. In many cases, the more sophisticated the product becomes, the more important it is to have simple structures, clear accountability, and teams that understand how their decisions affect the complete vehicle.

Every Discipline Has to Work Together

Modern vehicles bring together many different areas of expertise. Mechanical engineering, electrical engineering, software, design, manufacturing, safety, testing, quality, purchasing, supply chain, and product planning all play important roles.

None of these disciplines can succeed on its own.

A design change can influence manufacturing. A hardware decision can affect electronics and software. A customer feature may cross several systems before it is ready for production. Something that looks like a small decision within one team can create consequences somewhere else.

That is why collaboration has to begin early.

The strongest development teams ask difficult questions before decisions become expensive to change. They challenge assumptions respectfully and bring different disciplines into the conversation when those perspectives can still influence the outcome.

The goal is not to eliminate disagreement. Good engineering needs disagreement sometimes. The goal is to resolve it while there is still time to make the product better.

Accountability Has to Cross the Interfaces

One lesson I have carried throughout my career is that people perform at their best when they understand what they own and have the authority to move it forward.

Large organizations can make that surprisingly difficult. Responsibilities overlap. Decisions cross several functions. Everyone participates, but nobody is completely sure who has the final call.

That is where good intentions can turn into delay.

The highest-performing product organizations are built around end-to-end accountability. System architects and empowered product teams must own outcomes across interfaces, rather than passing problems from one function to another. Collaboration matters, but collaboration without decision rights can become another form of delay.

I think that distinction is important.

Cross-functional work does not mean every decision needs to be made by committee. Teams need input from different disciplines, but eventually someone must have the responsibility and authority to make the decision.

Clear ownership creates accountability. Clear decision rights create speed.

You need both.

Simplicity Helps Everyone Move Faster

As organizations grow, processes naturally increase. Some improve quality and consistency. Others remain because they have always been there.

I believe we should keep questioning the difference.

If a meeting does not create value, why does it exist?

If a process slows engineering without improving quality, what are we protecting?

If talented people spend more time navigating the organization than solving customer problems, have we designed the organization around the work or forced the work around the organization?

Those are questions leaders should be willing to ask.

Simplicity does not mean removing discipline. Vehicle development requires tremendous discipline. It means removing unnecessary barriers so people can spend more time making good products.

Technology Should Give Engineers More Time to Engineer

The tools available to development teams continue to improve.

Simulation allows us to explore alternatives earlier. Automation can remove repetitive tasks. Artificial intelligence can help engineers analyze information, identify patterns, and work through large amounts of data more efficiently. Digital development can reveal problems before they become expensive physical problems.

I see enormous value in that.

But technology should support engineering judgment, not become a substitute for it.

A tool can give us information. Experienced people still have to understand what that information means for the complete vehicle. They have to understand the tradeoffs and decide what should happen next.

The real opportunity is giving engineers more time for that kind of work.

If automation can remove hours of repetitive effort and allow someone to spend those hours solving a difficult system problem, that is meaningful progress.

Communication Needs a Purpose

Some of the best engineering conversations I have experienced were not about proving someone right. They were about understanding a problem from different perspectives before deciding what to do.

That kind of communication builds stronger teams.

People should be comfortable raising concerns early. Leaders should encourage direct discussions because hidden problems rarely become easier with time. Different technical backgrounds should be represented because the best answer often appears when someone sees a problem differently.

But communication cannot become an objective by itself.

More meetings do not automatically create better collaboration. More people copied on a decision do not necessarily improve the decision.

Good communication should lead somewhere. A problem is understood, a tradeoff is discussed, an owner makes a decision, and the team moves forward.

That rhythm matters.

Organize Around the Product, Not the Functions

Traditional organizations naturally create functional boundaries. That structure can build deep expertise, which is valuable.

The risk appears when those boundaries become walls.

A customer does not experience the mechanical engineering department, the electronics organization, or the software team. They experience one vehicle.

Our development organizations should reflect that reality.

When a problem crosses systems, the response cannot be to move it from one department to another until somebody accepts responsibility. The team has to look at the complete outcome and solve the problem where the systems meet.

This is another reason system architecture matters so much. Someone has to understand how the pieces fit together and have enough authority to make decisions across those interfaces.

Otherwise, each individual component can succeed while the overall experience still fails.

Keep the Customer at the Center

Engineering teams can easily become absorbed in technical details. That is understandable because every system contributes something important to the finished vehicle.

Customers see it differently.

They care that the vehicle is dependable. They expect different systems to work together naturally. They want confidence when they get behind the wheel.

Keeping that perspective changes the questions teams ask.

Instead of asking, “Which department owns this problem?” we should be asking, “Who needs to own the outcome?”

Instead of optimizing one component because it meets its individual target, we should ask whether the complete system is delivering what the customer needs.

That shift sounds small, but it changes how people work together.

Better Organizations Create Space for Better Engineering

Vehicle development will continue to become more demanding. Technologies will evolve. Regulations will change. Markets will move at different speeds. Customers will expect more from the products we build.

I do not think the answer is automatically more organizational structure.

The organizations that perform best will be the ones that combine deep expertise with clear ownership. They will give teams room to make decisions while holding them accountable for outcomes. They will use technology to remove low-value work and simplify processes that no longer serve a purpose.

Most importantly, they will understand that collaboration and accountability are not opposites.

You need people working across disciplines because modern vehicles are deeply integrated products. But you also need people who know when the discussion is finished and a decision has to be made.

At the end of a development program, customers do not see our organizational charts, meetings, reporting structures, or internal boundaries.

They experience the vehicle.

Our job is to make sure the complexity stays with us, not with them.