Egineering Innovation:
What Seven Patents and 30+ Years Taught Me About Execution

Engineering innovation is not a solitary flash of inspiration; it is a disciplined process that connects curiosity, learning, disagreement, experimentation, and execution. More than 30 years in engineering can sound like a story about accumulating technical knowledge. My experience has taught me something different: useful innovation is neither a solitary event nor an idea-generation contest. It is a disciplined team process that connects curiosity, learning, disagreement, experimentation, and execution.

My work has crossed automotive and heavy-vehicle product development, embedded hardware and software, systems engineering, testing and verification, manufacturing, project leadership, and organizational transformation. The patents on which I am named—including work involving multiplexing systems, human-machine interfaces, telemetry, operator guidance, and connected-vehicle technologies—represent only visible milestones. Behind each milestone were requirements, constraints, competing perspectives, technical risks, tests, revisions, and decisions.

That experience shaped my view of engineering innovation: the idea matters, but the system that turns the idea into demonstrated value matters more.  From experience, intellectual property begins with conflict, the approach to the destination is severely constrained, and we are too persistent to disengage.  Also from experience, the entire path is full of conflict.  Successfully harnessing these conflicts- physical and interpersonal- is personally fulfilling (IMHO).  It is creativity.

Innovation without execution remains potential. Execution without learning merely repeats what an organization already knows. Sustainable value comes from linking lateral thinking with continuous learning and harnessing conflict so that it improves the solution instead of damaging the team.

The Smoking Area

I am not a smoker; not a judgment, just facts.  I used to smoke, but my time in sports (football, track, and baseball) deterred me from developing the habit.  The coaches frowned on smoking when we were working so hard to build up the capabilities of the body, and I terminated my impulse to smoke.  I have, however, worked with engineers who were smokers.  We would work in the lab, and they would take a break and go outside to the smoking area.  I would go there also, to discuss the difficulties we were having in the lab.  I found that these discussions out in the smoking area produced some interesting results. Time just far enough away from the workload, produced interesting results – at least maybe, in part by the number of patents that seem to have originated from these discussions.

Engineering Innovation Requires More Than a Good Idea

A patent documents a novel invention. It does not, by itself, prove that the invention can be integrated, manufactured, verified, supported, or used to produce value. Those are execution questions.

In engineering, a promising concept must survive contact with reality. It must address a meaningful problem, fit within system interfaces, operate under expected and unexpected conditions, and must be testable. It must fit within cost, timing, production capability, regulatory requirements, service, and the people who will use it.

This is where many innovation efforts struggle. Organizations often separate “creative” work from “execution” work as though one group invents and another group simply implements. The handoff becomes a risk because essential knowledge, assumptions, and unresolved contradictions travel poorly across organizational boundaries.

Effective engineering innovation keeps invention and execution connected. Manufacturing, quality, supply chain, testing, software, hardware, service, project management, and the customer perspective need to influence the solution early enough to change it. Cross-functional participation is not an administrative burden. It is part of the design.

The goal is not to eliminate constraints. Constraints tell us what the solution must survive. The goal is to prevent familiar constraints from limiting the range of ideas before the team has examined the problem from several directions.

Lateral Thinking Expands Creative Problem Solving

Engineering education and experience build strong analytical habits. We learn to decompose a system, identify causes, calculate effects, compare alternatives, and converge on an answer. Those habits are essential, but they can also keep us inside the boundaries of the first problem definition.

Lateral thinking deliberately changes the frame. Instead of asking only, “How can we improve this design?” we might ask:

• What assumption makes the current design seem necessary?
• What would happen if we removed the component, step, or interface entirely?
• How would another industry solve the same functional problem?
• What if the apparent constraint became a design input?
• Are we solving the failure, or only controlling its symptoms?
• What would make the opposite approach work?

These questions create movement. They interrupt the reflex to optimize the existing answer and reopen the underlying problem.

Lateral thinking is not a rejection of analysis. It is a way to generate better alternatives for analysis. Divergent thinking expands the option space; convergent thinking uses evidence, constraints, and judgment to select and refine a solution. Teams need both.

Lateral Thinking Tools for Engineering Teams

Simple tools can help teams think “outside the box.”  Many of you may have been part of brainstorming events to open the space for possible solutions.  There are several other practical problem-solving tools that can make lateral thinking repeatable:

1. Assumption mapping: Write down what the team believes must be true. Classify each assumption as known, testable, uncertain, or inherited. An inherited assumption deserves special attention because it may have outlived its original context.
2. Reversal: State the conventional approach, then reverse it. If the normal question is how to make an operator respond to the system, ask how the system could respond to the operator. The reversed idea may be impractical, but it exposes possibilities hidden by the original frame.
3. SCAMPER: Explore what could be substituted, combined, adapted, modified, put to another use, eliminated, or reversed. This gives a team structured prompts when “be creative” produces silence.
4. Six Thinking Hats: Temporarily separate facts, risks, benefits, emotions, creative alternatives, and process control. This helps prevent one forceful perspective from dominating every stage of the discussion.
5. TRIZ contradictions: Identify where improving one characteristic appears to worsen another. Rather than accepting the tradeoff immediately, ask whether the contradiction can be removed through separation, a different physical principle, or a change in architecture.
6. Analogical thinking: Look for systems in other products, industries, or natural processes that perform a similar function. The objective is not to copy a solution but to transfer a useful principle.
7. Premortems and FMEA: Imagine that the concept has failed and work backward to identify why. Lateral thinking finds possibilities; structured risk analysis exposes how those possibilities could break.

The tool is not the innovation. A tool creates a useful interruption in the team’s normal pattern of thought. Its value depends on the quality of the question, the diversity of the participants, and what the team does with the resulting ideas.

Continuous Learning Turns Ideas Into Capability

Innovation is a learning process before it is a delivery process. An idea begins with incomplete knowledge. The team must discover what is true, what is possible, and what customers or users will value.

That discovery should not be left to chance. The best engineering teams make learning visible. They translate uncertainty into questions, questions into hypotheses, hypotheses into tests, and test results into decisions.

This changes the purpose of an early prototype. It is not a small version of the finished product created to reassure leadership. It is a learning instrument. A useful prototype attacks an important uncertainty. A useful test produces evidence that changes or strengthens a decision.

Continuous learning also means learning across time. Teams lose value when a test result remains in an individual notebook, a decision loses its rationale, or a launch lesson never reaches the next program. The organization then pays to relearn what it once knew.

Research on team learning reinforces the importance of the working environment. Amy Edmondson’s study of work teams defined psychological safety around interpersonal risk-taking and found it associated with team learning behavior. For engineering leaders, the practical implication is direct: people must be able to ask an uncomfortable question, report a mistake, or challenge an assumption without expecting personal punishment. Psychological safety does not mean an absence of standards or accountability. It makes candid learning possible.

Learning Tools That Improve Project Execution

Useful learning practices include:

• Decision journals: Record the decision, assumptions, evidence, alternatives, owner, and expected outcome. Review the entry when new evidence arrives.
• Decision matrix: Compare alternatives against agreed-upon, weighted criteria such as customer value, technical feasibility, risk, cost, timing, and learning potential. Document the evidence behind each score so the team can expose assumptions, resolve constructive conflict, and make a transparent, defensible decision.
• Hypothesis-driven tests: State what the team expects to learn before running a test. Define what result would support, weaken, or overturn the current direction.
• After-action reviews: Ask what was expected, what happened, why the difference occurred, and what should change.
• Knowledge pull at project start: Search previous lessons, failure modes, warranty data, and validation results before building a new plan.
• Short learning cycles: Reduce the time between a question, an experiment, and a decision. Fast feedback is more valuable than fast activity.
• Requirements traceability: Connect what is learned to requirements, risks, architecture, verification, and change control so that learning affects the product and the plan.

Learning becomes capability only when it changes future behavior. A lesson that is captured but not applied is an archive, not an improvement.

Constructive Conflict Can Drive Better Solutions

Innovation creates conflict because it brings together different knowledge, incentives, risks, and interpretations. A software engineer, manufacturing engineer, test engineer, program manager, supplier, and customer can examine the same proposal and see different problems. That difference is valuable.

Conflict can reveal a hidden assumption. It can expose a weak interface, an unrealistic schedule, an untestable requirement, or an overlooked failure mode. It can prevent premature agreement and force the team to examine evidence more carefully. A team in which nobody disagrees may be unusually aligned—or it may have learned that disagreement is unwelcome.

However, conflict is not automatically productive. A meta-analysis by Carsten De Dreu and Laurie Weingart found negative overall relationships between both relationship conflict and task conflict and team outcomes. The research also highlights an important nuance: disagreement can stimulate information processing, but more intense or personal conflict can reduce cognitive flexibility and performance. The benefit does not come from conflict alone. It comes from how leaders and teams structure it.

Constructive conflict keeps the tension focused on the work. Destructive conflict attaches the disagreement to identity, status, motive, or personality. Once the issue becomes “your group versus my group,” technical evidence has difficulty getting heard.

How Engineering Leaders Harness Conflict Successfully

Leaders can turn disagreement into better problem solving by creating explicit operating rules:

1. Begin with shared purpose. Define the value to be created, the problem to be solved, and the decision that must be made. Shared purpose gives different functions a common reference point.
2. Separate positions from assumptions. Ask each participant what must be true for their preferred option to succeed. Teams can test assumptions more effectively than they can debate preferences.
3. Make evidence visible. Put requirements, risk data, test results, cost, timing, and constraints where everyone can examine them. Do not let authority substitute for evidence.
4. Challenge ideas without diminishing people. Use language such as “What risk do you see?” or “What evidence would change our decision?” Avoid questioning competence or motives.
5. Invite dissent before commitment. Assign a devil’s advocate, conduct a premortem, or ask the least-heard function to speak first. Deliberate dissent reduces the chance that status will create false consensus.
6. Time-box divergence and define convergence. Teams need room to explore, but they also need a decision rule, a decision owner, and a deadline. Endless debate is not rigor.
7. Document the decision and rationale. People can support a decision they did not prefer when they understand how it was reached and what evidence will trigger reconsideration.
8. Watch for relationship conflict. If language becomes personal, pause. Reframe the issue, restate the common objective, and return to observable facts and testable claims.

Harnessed successfully, conflict becomes a form of design review. It increases the number of perspectives applied to the problem while preserving the team’s capacity to act. This requires all team members and a project manager, if there is one for this effort, to wrestle with these conflicts, not suppress or dismiss.

A Practical Innovation and Execution Cycle

Over time, I have come to see innovation and execution as a connected learning cycle:

1. Define the value. Who benefits, what problem changes, and how will the result be measured?
2. Frame the problem. Identify requirements, interfaces, constraints, risks, and stakeholders.
3. Surface assumptions. Separate what is known from what is believed.
4. Generate alternatives. Use lateral thinking and cross-functional knowledge to expand the option space.
5. Create constructive conflict. Challenge the alternatives, search for contradictions, and expose failure modes.
6. Select with discipline. Use explicit criteria and assign decision ownership.
7. Prototype and test. Attack the most consequential uncertainty first.
8. Capture the learning. Update requirements, risks, models, plans, and decision records.
9. Execute and validate. Confirm that the solution works in its intended operational context—not only under controlled development conditions.
10. Sustain and improve. Monitor results, transfer knowledge, and feed operational learning into the next cycle.

This cycle prevents two common failures. The first is uncontrolled creativity: many ideas, little evidence, and no path to value. The second is premature execution: a team commits early, treats questions as resistance, and discovers major assumptions after change becomes expensive.

Good engineering innovation moves repeatedly between exploration and proof. It expands possibilities when the frame is too narrow and converges when evidence supports action.

Seven Lessons From Seven Patents and 30+ Years of Engineering

I would summarize what innovation has taught me about execution in seven lessons:

1. Start with the problem, not the technology. A technically interesting answer can still solve the wrong problem.
2. Requirements should focus creativity, not suffocate it. Clear outcomes and constraints give the team a target while leaving room to discover a better method.
3. The most important assumption is often the one nobody remembers making. Make assumptions and critique them before they become architecture, cost, and schedule.
4. Diversity of expertise creates productive tension. Different perspectives increase the chance that the team will see the whole lifecycle, but leaders must keep the tension focused on the work.
5. Don’t exclude prematurely.  Create an environment that encourages many potential ideas.
6. Testing is a learning activity, not a ceremonial gate. Test early enough that the result can still change the decision.
7. A decision is incomplete without its rationale. Capturing why the team chose a direction improves traceability, change control, and future learning.
8. Innovation creates value only through execution. The solution must move from idea to integrated system, from prototype to validation, and from launch to sustained performance.

These lessons are not confined to patents or automotive technology. They apply whenever people must create something new under uncertainty: product development, process improvement, cost reduction, organizational change, manufacturing transformation, and complex project recovery.

Engineering Innovation Creates Value Through Execution

Seven patents are evidence that ideas made it through a demanding process. More than three decades of engineering have shown me why some ideas survive that process, and others do not.

The differentiator is rarely creativity alone. It is the ability to connect creativity to disciplined execution: to reframe the problem through lateral thinking, turn uncertainty into continuous learning, use constructive conflict to improve the solution, and translate decisions into verified operational results.

That is the real work of engineering innovation. It is not eliminating disagreement, uncertainty, or constraints. It is the successful use of all three.

Leaders who want more innovation should not ask only, “How do we generate more ideas?” They should also ask:

• Can our people challenge assumptions without making the conflict personal?
• Do our processes turn questions into tests and tests into decisions?
• Are we learning quickly enough to change direction before the cost of change rises?
• Can we trace a promising idea all the way to measurable customer and operational value?

The answers reveal whether innovation is an aspiration, an activity, or a repeatable organizational capability.

At Value Transformation LLC, my focus is helping organizations connect product development, risk management, testing, operational readiness, manufacturing, and project execution so that good ideas become sustainable value.

Editorial references

• Amy C. Edmondson, “Psychological Safety and Learning Behavior in Work Teams,” Administrative Science Quarterly, 1999: https://web.mit.edu/curhan/www/docs/Articles/15341_Readings/Leadership/Edmondson_1999_Psychological_safety.pdf
• Carsten K. W. De Dreu and Laurie R. Weingart, “Task Versus Relationship Conflict, Team Performance, and Team Member Satisfaction: A Meta-Analysis,” Journal of Applied Psychology, 2003: https://web.mit.edu/curhan/www/docs/Articles/15341_Readings/Group_Performance/DeDreu_%26_Weingart_2003_Task_versus_Relationship_Conflict.pdf

 

 

For more information, contact us:

The Value Transformation LLC store.

Follow us on social media at:

Amazon Author Central https://www.amazon.com/-/e/B002A56N5E

Follow us on LinkedIn: https://www.linkedin.com/in/jonmquigley/

https://www.linkedin.com/company/value-transformation-llc

Follow us on Google Scholar: https://scholar.google.com/citations?user=dAApL1kAAAAJ