How To Manage Technical Teams When You Don’t Share Their Credentials

I landed my first management position at an early-stage startup when I was just a year out of college. Whenever colleagues knocked on my door and I beckoned them in from behind my desk, it always felt like I was wearing one of my dad’s suits and just playing the part. That impostor feeling was never more acute, though, when a senior engineer would swing by to argue about something. It would go something like this:

Engineer: “Do you realize that these requirements mean we’d have to rewrite all the database scripts? Are you telling me that’s what you want two engineers doing for two months?”

Me: “Um . . . yes?“

Debating with the engineers was a real source of stress for me back then. I hadn’t yet learned how to deal with abrasive personalities (of which we had a couple), and I was learning everything on the fly. Usually when someone came calling, I really had missed some important detail or other. Other times, though, I would realize later that I should’ve held firm—but just didn’t know how to discuss points of strategy with more technical team members.

“Non-technical” managers often struggle to give instructions on more technical issues and wind up deferring to those subject-matter experts in the company. The two sides can easily come into conflict, thanks to a shortage of context shared between them. Some conflicts, of course, are inevitable—even desirable. But those that come from mutual distrust and misunderstanding aren’t. In my experience, nontechnical managers face an uphill battle for two reasons.

The Two Biggest Sources Of Conflict

First, technical folks often think they understand the business side because it’s inherently more accessible to outsiders. A smart engineer can, for instance, read a few Harvard Business Review articles and then make arguments about strategy that at least sound plausible to themselves (if not to others). That usually doesn’t happen in the opposite direction. Even a smart marketer or salesperson can’t spend an hour on Stack Overflow and make credible inquiries into system design.

Second, engineers, data scientists, and other technical staff tend to make decisions with a level of certainty that the rest of us often can’t. A particular software architecture, for instance, can objectively run faster than the alternative; a new jet engine can objectively consume less fuel. A marketing strategy—even a really well-researched one—just doesn’t come with that kind of clean certainty.

And understandably, people accustomed to more data-backed or deterministic outcomes can be uncomfortable with their work being guided by people whose choices seem so much more subjective—or even even superficial—by comparison. When neither side fully understands each other, you have a recipe for occasional conflict. But there are a few things you can do to become more effective at bridging the gap as a non-technical manager.

1. Above All, Know Your Stuff

Some business decisions will always be subjective, which means there’s no room for sloppy thinking. You need to be able to explain your decisions and describe expected outcomes. 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—Or Fake It

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 some backbone. Don’t be afraid to acknowledge the unknowns and risks, but don’t cave just because people push back or raise questions based on technical expertise you don’t have yourself. If you don’t demonstrate conviction, your effectiveness will be undermined no matter what.

3. Pin Down What Really Matters To You

Whenever you lay out a plan that affects the work that technical team members will have to do, figure out what’s most important to you and do that first. You may find that the things others push back about aren’t especially critical to you, and that you can satisfy everyone’s interests without too much pain.

But that means you need to distill whatever the ultimate goal is in your mind beforehand. Decide what’s absolutely crucial, and what’s negotiable will be come clearer. This way you can also give technical employees as much leeway as they need to figure out the “how,” which they’ll likely appreciate.

4. Steadily Build Your Own Technical Knowledge

This one’s obvious: The better you understand your colleagues’ concerns, the better you’ll be at working with and managing them. You don’t need to become a programmer or a statistician or a mechanical engineer or what-have-you. But you do need to understand the major complexities involved in what they do so you can understand the trade-offs involved in strategic, business-related choices that ultimately affect everyone.

Between learning on the job, books you can read, free and paid online courses, brick and mortar classes, and other resources, there’s just no excuse for not building your technical knowledge—especially if you interact with high-tech workers every day. In fact, they’re a great starting point: Ask your peers what resources they’d recommend, and get cracking. The very fact that you’re making the effort often creates room for common ground you might not otherwise share.

Christian Bonilla designs analytics software at Resonate, despite having no formal engineering training. You can follow his business ramblings at SmartLikeHow.com or on Twitter at @smartlikehow.

A version of this article originally appeared on SmartLikeHow.com. It is adapted and reprinted with permission.