The Science-Engineering Interface
5 Lessons From Being a Translator Between Scientists and Engineers
For the first 8 years of my career, I worked at the interface of science and engineering. I ended up at this interface accidentally and found myself in a perpetual identity crisis (some things never change).1 Scientists thought I was an engineer. Engineers thought I was a scientist. I was rejected by both communities yet simultaneously became a partner to both, because I could speak their language well enough to translate it into the language of the other.
I worked in instrument systems, which means I worked closely with scientists to understand the questions they were pursuing and the measurements they needed to answer those questions. I then translated those needs into engineering requirements that would enable the design, development, and deployment of instruments, sensors, and/or spacecraft payloads that could make those scientific measurements. Once the systems were engineered, I would conduct characterization and calibration of them, so that the engineering data generated by the systems could be converted into scientifically interpretable data.
I conducted this type of work at three different academic institutions and a venture-backed startup. It resulted in an award-winning calibration device for cosmology experiments, a biomedical device for testing DNA for HIV resistance that was later adopted by cancer researchers, a set of suborbital balloon-borne telescopes for studying the origins of the universe, a space medical device concept for improve astronaut bone health, a set of sample return mission concepts to search for life in our solar system, the first spaced-based commercial mid-wave infrared instrument, and the first mission design to conduct asteroid mineral resource exploration and proof-of-concept extraction.
Throughout those 8 years,2 I worked with a wide variety of scientists: astrophysicists, cosmologists, physical chemists, biochemists, isotope geochemists, microbiologists, medical doctors, planetary scientists, geologists, and even the occasional agronomist. I worked with nearly every type of engineer: mechanical, electrical, software, computer, optical, systems, signal processing, modeling & simulation, nuclear, and industrial. This is what I learned:
1. Never Assume Scientists and Engineers Think Alike
When reading the news, policy documents, and many other publications, I often see scientists and engineers lumped together into a single category, as if they are interchangeable. While there is common foundational knowledge between the two disciplines, they represent two fundamentally different approaches to the world, nearly opposite of each other in many respects. In the case of scientists, they are often focused on targeted, esoteric measurements or experiments, which they then connect back to big overarching questions about how the world works. In the case of engineers, they are met with a huge array of possible designs to choose from and narrow down to the one design they will build. One focuses on the small and connects it to the larger world. The other starts with the larger world and narrows from there.
Therefore, they tend to think in opposite directions. The scientists may continue to think of new measurements they want to make, while the engineer needs to figure out which design to pick, so they can start development. Those managing the interface between them will work with both to figure out the optimal design (within any budgetary, schedule, or other constraints), that enables the highest value measurement(s) the scientist wants to make. However, in many cases, no one is managing the interface, which means either the scientist or engineer may attempt to do so (which may be successful, depending on the individual), or design decisions get made that lead to misalignment between the measurements needed and what the resulting system can do. In either case, assuming that scientists and engineers are going to be aligned on goals is rarely a valid assumption.
2. Never Assume Scientists and Engineers Are Logical
Due to the portrayal of scientists and engineers in popular culture, as a society we tend to think of both groups as highly logical thinkers, rarely driven by emotion. The reality is that emotions and ego play a major role in the decision making of scientists and engineers. Many of the scientists with whom I have interacted, genuinely think they are superior to engineers. Many of the engineers with whom I have worked, will actively look for opportunities to show-off how smart they are. Every system failure analysis I have conducted was ultimately traceable back to an interpersonal conflict, such as a breakdown of communication because two people who did not like each other, so they minimized speaking to each other. Logic may be an important skill involved in both science and engineering, but emotions and ego are what determine success and failure.
Those at the interface of science and engineering also have an ego and emotions that need to be managed. In fact, success at the interface often means being comfortable as the “dumb” one in the room, the one asking questions to understand the perspective of each side, and the one willing to ask the “stupid” questions that no one else wants to ask, out of fear of looking inferior. Successfully operating at the interface means finding comfort in being uncomfortable, while still maintaining enough confidence to be taken seriously by the egos in the room. Thus, those at the interface must manage their own ego and emotions, while also understanding how the egos and emotions of those around them are influencing decision making.
3. Scientists May Overlook The How
Scientists tend to be good at keeping track of the “why.” This is because they must put their research into a larger context and connect it back to big overarching questions, in order to convince funding entities to fund their research. However, many scientists, though not all, are not good at understanding the “how.” Scientists who rely on data collected by major systems, often take for granted the effort required to create the major system in the first place. They do not actually understand where the data they are using comes from, how difficult it is to attain, and how much money, labor, and difficult decisions went into creating it. This is not true of all scientists, as some create their own systems for data collection. But those who do not, those who rely on the systems of others, tend to overlook the “how,” which means they will struggle the most when interacting with engineers.
Those at the interface should take time to understand, which scientists have an understanding and appreciation for the “how,” and which do not. For those that do not, it’s useful to ask leading questions that force them to think about (1) where their data comes from, (2) how their ability to analyze data and the conclusions they can draw from it would change, if the system collecting the data changed, and (3) what data that does not currently exist would improve their research. These kinds of questions can help scientists understand that they can, and should, influence the “how,” which is the first step to getting them to better interface with engineers to improve decision making.
4. Engineers May Overlook The Why
Engineers tend to be good at keeping track of the “how.” This is because their core responsibility is figuring out how to create a particular system and how it should work. However, many engineers, though not all, are not good at understanding the “why.” In many cases, engineers are given a specific objective, or a list of requirements, and expected to design a system according to the objective and/or requirements. They do not necessarily need to understand where the objective or requirements came from, or why it was chosen, in order to be successful at their job. Due to this, engineers are more likely to overlook the “why.” Often engineers focus so much on building the best system, they may not stop to understand why the system is being built in the first place.
I have seen this behavior many times in my career. In one case, an engineer spent $100,000 buying components for a measurement system without ever talking to the scientists who understood the measurement that needed to be made. Once the conversation between the engineer and scientists was facilitated, it was revealed that the wrong components had been purchased, meaning $100,000 and 2 weeks of time had been wasted. Similarly, I come across technical founders in the entrepreneurial community, who have developed a new technology or product, but have a build-it-and-they-will-come attitude, as they have done no customer discovery, or other work, to understand why someone might use their technology or product. For those operating at the interface, help engineers stop and ask “why,” because understanding the “why” will make them better engineers, help them avoid costly mistakes, and make them better entrepreneurs, if they ever want to start their own company.
5. Ground Yourself In Curiosity
Whether you are someone who specializes at the interface, a scientist who wants to work better with engineers, or an engineer who wants to work better with scientists, ground yourself in curiosity. Don’t let your ego or fear of feeling stupid prevent you from asking questions. As simple as it sounds, asking questions is the best way to manage the challenges that emerge from the four prior observations in this post: (1) Asking questions can help you reveal how those around you think differently than you. (2) Asking questions can help you manage the egos and emotions of others, because it can be a tool for both diffusing tense situations and stroking the ego of those that need it to function. (3) Asking questions can help you understand the “how” you may be taking for granted. And (4) asking questions can help you understand the “why,” so you can make better decisions about the “how.”
The above are observations from my own experience. They involve generalizations that cannot be applied to any one individual, but instead are intended to represent general trends I have observed. They are not universally true, as there are always exceptions and different contexts, outside of my experience, where they are not true. In fact, the biggest takeaway from this article should NOT be “I can now make sweeping generalizations about scientists and engineers.” The real takeaway should be “Don’t make sweeping generalizations about scientists and engineers. Instead take the time to understand where a given scientist or engineer is coming from, in order to understand how best to work with them.”
I ended up as an awkward inbetweener, because I started my career in astrophysics, but quickly discovered through a series of internships, that I hated the day-to-day life of an astrophysicist. I loved the questions, curiosity, and desire to explore and discover that underpinned science. So I wanted to stay connected to it, but I knew I would be miserable in a career as a scientist. As an undergraduate at the time, I was writing and directing plays as an extracurricular activity. I found far more satisfaction in those creative processes, than I did in my astrophysics research experience. What I loved about playwriting and directing was the process of going from an idea in my head, to building a team that believed in the idea, to working with that team to turn an idea into something real and tangible.
Once I realized the type of work I found satisfying, it was easy to identify an analog in the space technology world, as I knew from a young age I wanted to work in space. I realized I wanted to be an engineer, not a scientist. However, I was so far into my astrophysics degree it would have been too costly to switch. Thus, I decided to focus my remaining research as an undergraduate on opportunities in scientific instrument development, so that I could learn how to engineer things, but with the purpose of conducting science. Interestingly, when I was applying to join the research lab (that would become my second home for nearly 2 years), they asked me if I had any experience working in a machine shop. I said, “Well I’ve built sets for plays, so yes, but in a very different context.” They immediately responded, “Perfect! That’s how we all learned too!” That’s when I knew I had found where I belonged.
I greatly enjoyed my time working in instrument systems and I thought I would do it for my entire career. But its funny how career trajectories work. After my venture-backed startup experience, working as an instrument systems engineer, I joined the Aerospace Corporation, thinking that it would be an opportunity to further hone my instrument skill set. It was not. I worked on one small project that involved instrument systems. Instead, I discovered my venture-backed startup experience was more valuable than I realized, because it gave me a context for the shifting commercial space ecosystem, that few others at Aerospace or within the government had at the time.
Therefore, rather than getting pulled intro instrument projects, I kept getting pulled into market, economic, and venture-backed startup studies. It led to me leave instrument systems behind and leave Aerospace to pursue an opportunity that would expand my market, economic, and venture capital knowledge even further. Regardless, my time in instrument systems was foundational for me, because what I learned working at the interface of science and engineering is broadly applicable to working at any interface (more on that in the future).