I generally really enjoy working with engineers. Most I’ve collaborated with think carefully about problems, embrace failure and care deeply about their craft and coworkers.
That being said, sometimes collaboration goes wrong, and folks I talk to— engineers and non-engineers alike, can have past experiences that make them apprehensive of working with their technical peers.
In this post I’ll address some of the common misconceptions about collaboration with engineers. I’ll also include some tips, as someone who’s worked both with and as an engineer, for how to deal with the challenging situations that can arise.
Misconception 1: Engineering can only be understood by engineers.
“How are we going to generate all these recommendations for each user?”
“I’m sure the engineers will figure it out.”
Your engineers are knowledgeable professionals, like anyone else in your company. They will know how to do some things that non-engineers don’t, but nothing they do should be incomprehensible to an outsider.
Just as lawyers need to be able to explain legal situations to non-lawyers, engineers should be able to explain their work to non-engineers. In fact, if you don’t understand something technical, asking your eng team for clarification will not only help you, but them as well.
Recently on an engagement I had to explain to the CEO why we weren’t able to provide a certain search feature. Her questions helped me realize that while our current architecture couldn’t support the use case she wanted, there was a far easier solution that would. Both of us emerged from the collaboration with more thorough understanding and a simpler product.
Misconception 2: Engineers don’t like questions.
When I worked at Twitter there was a more senior engineer who had designed a system I needed to work on. One day I visited his desk to ask a question and I got a gruff response: “I don’t have time right now, send me an email”.
As a young engineer I took this to mean “Don’t bother me”. Two weeks later I still hadn’t followed up on the question and my manager kindly told me that gruff-team-lead was actually really nice, and that I should try sending an email. It took me an hour to craft that email, and I got a single line response— “Please come by my desk at 2PM tomorrow”
That meeting was wonderful. The team lead in question was very patient, and excited to answer my questions. In fact he became a friend and mentor for the rest of my career at Twitter.
Engineers tend to protect their time carefully. Engineering work requires solo time to be productive. This doesn’t excuse engineers being rude or impatient. However, they will be more averse to interruptions than people who get most of their work done in meetings. If an engineer appears impatient when asked a question, check in later and see if it’s a better time. Like me, you may be surprised.
Misconception 3: Engineers know more than everyone else.
When I was an engineer, I really enjoyed non-engineering conversations. I loved brainstorming sales strategy or learning about hairy legal issues. Maybe this is why I later became a founder.
Cross functional collaboration is awesome, and there can be a ton of value in bringing other departments into your meetings. Engineers are no different. However, I think people sometimes think of engineers as being generally “smart” or knowing a lot.
The reality is, engineers know a lot about what they work on, and they’re really good at seeming like they know a lot about other things. Software engineering involves more uncertainty than other fields I’ve worked in. It’s a relatively nascent domain that evolves super fast, and it’s rarely clear how to implement a feature. Engineers learn how to move confidently through uncertainty and they bring this confidence to other domains as well.
For instance, if an engineer were a doctor, patients would be advised to try 10 different medications and a surgery, then come back the next day.
While engineers probably aren’t great collaborators for medical diagnoses, they can be real assets in cross functional environments, even when they don’t know anything. That being said, though they may seem confident, engineers know as much about optimizing Customer Acquisition Cost as non-engineers know about optimizing databases. Which is to say, bring engineers into your CAC discussions, join the database discussions as a non-engineer and know that everyone is learning and bringing a unique perspective in the process.
Conclusion
There are many stereotypes about engineers, including the misconceptions listed above. However, these arise from the unfortunate homogeneity of the field not because they are in any way related to engineering skill. Good engineers explain their work, love questions, and are mostly same as other employees at a tech company. They also don’t need to like math, don’t have to be male, white or asian, don’t need a college degree and don’t even need to like technology. I know excellent engineers who have the above traits and I know excellent engineers who couldn’t be further from the stereotype portrayed in movies, TV and books.
“Engineer” is not a personality. On a collaborative team engineers and non-engineers assume the same things about each other— they are human beings excited to do their best work. They are curious when expectations aren’t met and assume discrepancies are specific to the individuals they’re working with, not reflective of a role in general.
As always, if you have questions or ideas you want to explore related to a technical topic, write in and we’ll feature them in this blog! See you then!
**Thanks to my co-blogger, the other David AKA David Chanin as well as Katherine Caniff, Michael Shafer, Charlene Wang, Jeremiah Lee and Joel Christansen from Foster for the excellent feedback on this post.**