Home > The Lean Post> Smitten Engineers or Love at First Sight of a Solution?
The Lean Post
Sharing how the world is making things better through lean.

Smitten Engineers or Love at First Sight of a Solution?

by Chet Marchwinski & Tyler Schilling
October 4, 2019

Smitten Engineers or Love at First Sight of a Solution?

by Chet Marchwinski & Tyler Schilling
October 4, 2019 | Comments (0)

Entrepreneur Tyler Schilling knows the pain of engineering heartbreak – falling in love early with a solution only to realize later in the project – after lots of time and money -- that the idea you are wedded to is fundamentally flawed.

The co-founder and recently retired president of TechnipFMC Schilling Robotics, noticed early on in his company, which designs and builds advanced remotely operated vehicles and manipulator arms for deep ocean work, that engineers “had this tendency to fall in love early with a particular solution … much to my embarrassment, I was one of those engineers.”

The cure for developing an early crush on a solution is set-based design, he explained to LEI’s Communications Director Chet Marchwinski during a recent product development conference. Implementing it took a change in company culture, a challenge that he shares here along with the practical lessons he learned.

Q: Your plenary presentation here at the annual Designing the Future Summit on lean product and process development was titled, “How to create a great company culture on purpose.” What does that mean?

Tyler: It's a strong belief of ours that culture is so important that you can't let it happen by accident. Like designing anything, you have to engage in things to teach people within your enterprise, what kinds of behaviors are expected of each other.

Q: One of the behaviors you mentioned that was very interesting was that engineers and engineering teams have an urgency to get to a solution. The problem is that the solution might be flawed so the team doesn’t realize it until it’s well down the road, and now fixing it is going to cost time and money. But you found a counter-measure for that?

Tyler: Yeah, and I suspect that this is a trait that's common to many people who are in problem-solving roles in their professions. I think it stems from the fact that people tend to identify themselves with the problems or the solutions that they propose to problems. And, for some reason, they like to come up with solutions as quickly as possible, and I would continually urge them to choose very, very carefully because whatever solution you choose, you're going to be wedded to it for the duration of whatever the project is. And so I noticed this tendency to fall in love early with a particular solution and then keep it on life-support throughout the balance of the project. 
I was introduced to a practice known as set-based design. The real power of it is that it requires  problem-solvers to produce a multitude of viable potential solutions. 

So, several years ago, I was introduced to a practice known as set-based design. The real power of it is that it requires problem-solvers to produce a multitude of viable potential solutions. They then go through a logical fact-based deselection process to end up with the final solution to implement.

Q: Doesn't that delay the product development process?

Tyler: You know, it feels like delay on the front end because the alternative is to think [of a solution] and choose it. And that can happen in a matter of minutes when you're presented with a problem. So the front end can seem like it takes longer, but over the life-cycle of the project, it's fabulously shorter to not fix problems that you created yourself.

Q: Good point. That sounds like it's a lot different from working in a traditional culture. So how -- in a lean product and process development culture -- is it a different way of working for executives and product developers? You've been in both roles and probably have a perspective.

Tyler: Back when I was directly engaged in product development myself and was authoring solutions, much to my embarrassment, I was one of those engineers who fell in love with [solutions] early. But, because my name was on the building, I could also change my mind.

And so, with the introduction of LPPD, there was a huge difference, and I think this is true whether you're in that authorship role or you're an executive -- it really stresses a  people-first approach based on transparency. So it fosters people being really open with the status of what they're doing and sharing, which is crucial to both quality and speed.

Q: And how is problem-solving different in making mistakes in a traditional culture and a lean product and process development culture?

Tyler: I think a really critical element of LPPD is to teach people that it's okay to declare that you have a problem. That you've run into a problem. It's just not okay to remain in that state for an extended period of time. So you should surface that you have a problem, ask for help, and all of those things are encouraged. And so this is very different from some other cultures, where if you have a problem it somehow reflects on your competency. So people have a tendency to harbor those things, and they show up later when it's way more expensive and problematic.

Q: You're an entrepreneur and I know you're passionate about advising young entrepreneurs, so if you could give them some advice now about creating and sustaining a great culture what would it be?

Tyler: I think that the number one thing would be to decide explicitly what the elements of the culture are that you're interested in. And, in our particular case, a really important cultural element that we decided on early was that you really have to demonstrate respect for everybody, and it doesn't matter whether it's your co-workers, or vendors, or customers, or whoever it is. It's extremely important to behave in a very respectful fashion towards one another. The quickest way to get terminated at Schilling robotics was to be disrespectful.


Was this post... Click all that apply
7 people say YES
6 people say YES
6 people say YES
6 people say YES
Related Posts
0 Comments | Post a Comment
Frontloading Product Development
The Designer's Dilemma
Please include links as plain text URLs only. Do not copy and paste directly from a web page or other document. Doing so may pick up additional HTML that will not function here.
URLs will be converted to functioning links when your comment is displayed on the site.
Here's an example:
See this article for more details: https://www.lean.org/whatslean