In the world of engineering and system development, even the most technically proficient teams can stumble when translating vision into reality. The process of turning a desired function into a working design might seem linear on paper, but in practice, it's often disrupted by miscommunication, unspoken assumptions, and overlooked variables.
Despite best efforts, misalignment between what a system is supposed to do and how it's designed to do it remains a persistent challenge. Giving insight to these challenges and their solutions, we asked Michael Hoffman, Bailey International Engineering Manager, a few questions. His responses highlight common pitfalls, the importance of communication, and the nuanced balance between function-driven design and design-informed function.
Before I answer these questions, I think it’s important to clarify terms. For the purposes of this discussion, I am defining the terms as follows:
Functionality – What the system/machine does. How it works. Real-world behaviors.
Design – Specifications, calculations, simulations, and component selections to achieve the desired functionality.
In your experience, what are the most common causes of disconnect between design and functionality?
The most common disconnects occur because of missing information in the application definition on the front end. Whether it’s due to a failure to define the goals well or incorrect assumptions on the part of one or both of the parties, the design teams’ understanding of the functional goals is not the same as what the others have in mind.
Why do you think this gap persists even in well-resourced teams or organizations?
There can be many reasons. Sometimes it’s as simple as what I call the “unknown unknowns.” Also known as the factor that nobody anticipated or knew needed to be accounted for. This is most common when we are working on new or innovative approaches. These are hard to avoid because when you are clearing new ground, you discover new obstacles.
But most commonly it’s caused by assumptions. The team driving the functionality goals assumes that designers do not need certain information to achieve their goals, or that when they give certain specifications, other specs are implicit. This is very common in our business. Things that naturally go together in one industry are different in another. This is one of the reasons why it’s important to work with custom design teams that are knowledgeable in your industry, and to explicitly tell them what you are trying to do. On the other hand, the design teams sometimes assume they have all the key information when they really don’t.
I’m reminded of a custom manifold project from last year. The customer gave Sales a very straightforward spec, and Sales passed it on to my team. The spec didn’t include much application information, but we had almost all the technical information we needed to design a block. However, they were missing a piece of data that we needed to size the cooling correctly.
I don’t remember why we asked for a conference call with the customer’s engineering team instead of just asking for the missing data point, but I’m glad we did. In the meeting, the customer showed us their application more fully, and my team immediately recognized multiple critical factors that were missing from the spec provided, which are unique to that type of application.
From the data we had upfront, there was no way for us to know that we needed those specific data points. We were able to get the information needed and provide them with what they actually needed. We also advised them to send some additional info to other suppliers to ensure they were on the right track, too.
How can designers and engineers better understand each other’s constraints and objectives?
Communication. Give all of the information, make sure everyone is on the same page and fully understands the full scope of the project. Having the big picture is key for designers to be able to design the right solution.
Do you believe one should lead the other—functionality driving design, or design leading function? Or should it always be a balance?
In the end, there always needs to be a balance. But in general, function-first, always. Function is everything, it’s the target the designers shoot for. The issues tend to come down to lack of visibility to that target or practical limitations of technology and budget, which require shifting the target. But the target always comes first.
How early should cross-functional collaboration begin in a project’s life cycle?
This depends on the project scope, but touching base as early as possible is always a good idea. This allows both teams to get on the same page and allows major hurdles to be identified early on. Then the timelines for full involvement of design teams can be decided on collaboratively.
