When I was preparing to leave academia for the tech industry, I found myself getting some strange advice.
My friends in Silicon Valley were dropping little tips like, “don’t include PhD after your name,” or, “bury your education experience at the bottom of your resume.” It’s an open secret that in Silicon Valley, having a PhD carries a heavy stigma. I’d heard this before, but standing at a career crossroads after having labored for my doctorate for so many years, I couldn’t quite get my brain around it.
Now that I’ve been working in the tech industry for five years, I get it. I’ve been able to observe up close how professional relationships between scientists and developers can break down and get lost in clouds of miscommunication. I’ve experienced firsthand the cultural divide between thought-based science and action-based development that insidiously breaks down collaboration.
At first glance it’s puzzling. Aren’t scientists and engineers basically the same thing? Aren’t these both disciplines that require extensive study and technical training? Why wouldn’t scientists and engineers just naturally work together well?
From what I’ve seen, I’d say it boils down to mainly two things: value systems, and measures of success.
***
It turns out that training in science and training in software engineering instill different, at times opposing, value systems. Scientific training values thought and aims to illuminate fundamental truths. Software engineering training values action and is principally concerned with the physical manifestation of things.
The longer one works in each of these fields, the further these value systems are reinforced. Scientists train for years to be experts in their field. Their currency is in labor-intensive peer-reviewed publications, their value based on how they have constructed their experiments and the extent to which their learnings advance the field of thought. Scientist idols tend to be historical figures like Einstein, Newton, and Pasteur, those who uncovered truths that serve as the foundation upon which future knowledge is built. An experiment that doesn’t turn out as you expect is often more valuable than the experiment that does, provided it was methodologically sound.
Software engineers, by contrast, often train only through undergrad or “boot camps,” under the prevailing wisdom that the best training is the kind you get working on a real-world problem. The content of their tech is fantastically complex, but they are ultimately evaluated based on how many people use their product and how much money it makes. Tech idols tend to be young and modern misfits, long-shots, and college drop-outs like Steve Jobs, Bill Gates, and Mark Zuckerberg. There’s currency in breaking the rules because the “rules” are the status quo.
In science, the rules are the delineation of what you should do based on the evidence that came before, while in tech, the rules are the outer limits of what has already been done.
Given these different models of training and mindsets, it’s easier to see how these groups might clash. Consider this diagram of how tensions arise:
***
One illustrative example of how this manifests is the polarizing reaction to Facebook’s long time motto “Move fast and break things.” This motto is simultaneously truly inspiring to a large fiery group of talented and deeply intelligent software engineers as well as truly horrifying and disturbing to pretty much any scientist. Of course, now that we’ve learned that moving fast and breaking things ultimately leads to breaking things like democracy, Silicon Valley is taking a bit of a pause to reflect—which isn’t exactly our strong suit.
What does this conflict look like in action? Often, it’s a communication breakdown that starts small, with little phrases like “We haven’t thought things through!” or “We aren’t moving fast enough!” While sometimes these statements are true, a lot of the time what we mean is, “I feel upset and unsettled and I don’t know why.”
A wave of unspoken reactions cascades from here. The scientist says, “We haven’t thought things through!” and the engineer thinks, “Of course we haven’t thought things through – we’re here to make things happen!” The engineer says, “We’re not getting enough done!” and the scientist thinks, “Of course we aren’t taking action – we need to understand things first.” This can be particularly agitating in the opposite direction—when it’s the engineer who says, “We haven’t thought things through,” the scientist might think, “I’ve … been studying this for two decades.” If the scientist laments, “We’re not getting enough done,” the engineer may well wonder, “Are you calling me lazy? These things are complicated.”
I’ve been impressed over the years by how understandable and often predictable these cascades of miscommunication can be, but how damaging, too, to both process and product. At best it gives rise to a lot of wasted energy of smart people. At its worst, it gives rise to chilling silos, toxic work culture, and dangerous products.
These cultural divides are holding progress back and this is particularly problematic in the area of Digital Health. Digital Health solutions demand that scientists, designers and engineers work collaboratively to build real solutions based on evidence that lead to meaningful impact.
…
So how do we bridge this divide? Looking straight into the eyes of conflict isn’t comfortable, but fortunately it’s instructive. If we can understand where these schisms form and how they play out, I mean really breathe it in, a few strategies reveal themselves.
1. Awareness and respect go a long way. If you can recognize your own values and biases, it can make a big difference in smoothing communication and making constructive conversations happen. It’s important to respect that each person and discipline brings something valuable to a project and a team. This might seem obvious, but it can be enormously hard to do. It’s hard to execute quickly and to implement compelling ideas. It’s hard to identify novel insights and learn truths about the world. People who do any of these things well are wizards. Appreciation is gold.
2. Constantly level up to your higher project mission and goals. If you are working on a team from diverse disciplines it’s because you are trying to accomplish something together. What is it you are trying to accomplish? Is that best served by high quality thought at the moment or high quality action? If you can trade off these mindsets effectively the team will learn how to adapt these values and roles in pursuit of the common goal.
3. Work with design thinkers. If we revisit the diagram from above, an interesting thing emerges in the middle. Designers have training that keeps them cycling from ideas to action and back again. This kind of designer (though designer isn’t always their title) is the kind of person who enjoys building things but only until they start feeling too far away from their purpose, asking “why am I doing this again?” This sends them over to the why and how corner until they start feeling the itch of “I want to be building things again!” Design thinking is iterative, and when done right, allows a project to evolve in an efficient and thoughtful way.
These are our next steps. We need each other, and we can do this.
Stephanie Greer, Hopelab’s former Research Lead, is a curious and creative thinker with a diverse skill set in behavioral neuroscience, design, and digital product development. Prior to Hopelab, Stephanie earned her Ph.D. in neuroscience studying health decision making (including sleep and dieting behavior) and was an early member of the Health Special Projects team at Apple. She is currently on sabbatical, gleaning knowledge from cultures around the world.
