How I used to feel talking to engineers
One of the unexpected benefits of joining an early-stage startup for me was having my own office. It was solely a function of how our space was laid out, but I loved it anyway. The only downside was that being barely a year out of college, sitting behind my big desk and having people knock on my door felt a little like wearing my dad’s suit. That feeling of being impostor was never more acute than when one of the senior engineers would come into my office to argue about something:
Grizzled Engineer: “Are you aware that you’re asking us to re-write a huge chunk of the back-end code? Are you telling me that’s what you want two engineers doing for two months?”
Me: “Um…yes?”
I was young and green, learning product management on the fly -- along with pretty much everything else. Debating with the engineers was often stressful, and it didn’t help that I hadn’t yet learned how to deal with abrasive personalities, of which we had a couple. They were usually right that I had missed some important detail or other, but plenty of other times I should have held firm but just didn’t know how to debate with developers about the software we were building.
People with “non-technical” backgrounds (i.e. those who aren’t engineers, data scientists, or similar) often have difficulty directing more technical subject matter experts. Even without directly managing them, people can find themselves managing projects or making decisions that impact what more technical resources have to do. Failure to communicate and establish trust can easily lead to conflict given the gap in shared context between the business and technical side. Some conflicts are inevitable, even desirable; conflicts born from mutual distrust aren’t.
I’d like to share a little of what I’ve learned about effectively steering technical resources as a (relatively) non-technical person. I approach this topic as a software product manager with no background as a developer, but the principles apply to any scenario in which you’re directing people whose technical knowledge far exceeds your own. Hopefully, your colleagues have learned themselves how to communicate technical concerns effectively, but let's assume they haven't and need an occasional reminder of the value that non-technical managers bring to them.
The Source of Conflict
When conflicts arise between the “business” and “technical” sides, lack of mutual understanding is usually the culprit. The scales are usually tipped against the non-technical manager in a debate though because their domain is more understandable to the lay person. For instance, a smart engineer can read a few Harvard Business Review articles and start making arguments about the business’s marketing or growth strategy that at least sound plausible (no matter how little they actually know). That usually doesn’t work in the opposite direction though. The average marketer or salesperson probably can’t spend an hour or two on StackOverflow and make credible-sounding inquiries about a system’s architecture, or read an academic journal and then challenge a data scientists’ methodology.
Engineers, data scientists, and other technical resources within a business can also make decisions with a level of certainty that you probably can’t. A piece of software may objectively use less memory; an engine can objectively consume less fuel. A marketing strategy just doesn’t have that type of clean certainty. People who are accustomed to deterministic outcomes are sometimes uncomfortable with their work being guided by people making decisions that seem subjective. Sometimes, they look down upon it.
How to Bridge the Gap
Like anything else, practice, or in this case experience, makes perfect. But there are a few things I believe you absolutely must do to build credibility as you develop expertise:
1. Know. Your. Stuff. If you’re on the business side, some of your decisions are will be more subjective and prone to challenge -- that means there is no room for sloppy thinking. You need to be able to explain your decisions and describe expected outcomes. Your mental model of the business needs to be rock-solid. Remember, engineers and data scientists are probably less comfortable with uncertainty than you are. If you’ve really done your homework and can lay out clear thinking every time, you’ll build trust with your team. As they say, game recognizes game.
2. Be Confident. If you’ve done your due diligence, stand behind your work. That’s not to say you stop being open to new information and ideas, but it’s good to show backbone. Don't be afraid to state the unknowns and what the risks are - navigating those is a big part of the non-technical manager’s job. Don't cave just because people object or raise questions. Without conviction, your effectiveness will be undermined.
3. Be Crystal Clear on What Really Matters to You. Whenever you lay out a plan that affects the work that technical resources will have to do, know what’s most important to you. You may find that the things others push back on aren’t critical, and that you can satisfy everyone’s interests without too much pain. But that requires that you’ve distilled whatever the idea is in your mind to what’s absolutely critical, and what’s negotiable. You also give technical resources as much leeway to figure out the “how” as possible this way, which they’ll appreciate.
4. Build Your Technical Knowledge. This one’s obvious: the better you understand your colleagues’ concerns and context, the better you’ll be at your job. You don’t need to become a programmer or a statistician or a mechanical engineer if you aren’t one, but you damn sure need to understand the complexities involved in what they do so that you can understand the tradeoffs involved. (For building your skills analyzing data, check out this article I wrote which also ran in Forbes.)
The last point is key. I’ve written before about my enthusiasm for the variety of excellent, cheap, and convenient resources for learning new skills today. Between learning on the job, books you can buy on Amazon, free and paid online courses, brick and mortar classes, and other outlets, there is no excuse for not expanding your knowledge. Ask your peers for what resources they’d recommend, and just get started. The very fact that you’re making the effort often helps build trust with your more technical colleagues (as long as you don’t pretend to be on their level).
Get Smarter One Block at a Time
If you need to understand something in a hurry and you’re feeling lost, your first step should always be making a block diagram of the concept. Block diagrams are simple ways of breaking down a machine, software program, mathematical models –any kind of complex system into something you can understand.
Think about it this way: every system takes stuff in, does some things, and spits stuff out. You don't need to understand every detail about how a car was built to understand what it does and how it works at a high level. Draw a diagram that illustrates how the thing works from start to finish. Whatever is a big ol’ question mark, you dig into using whatever resources you can get until you understand it a little bit more. Rinse. Repeat. Before too long, you’ll have at least a passing idea of what’s happening and where you can invest resources or solve problems.