Several years ago, I was recruited for a role in engineering leadership at an established software company. This was curious, because although I’d worked in many roles in tech organizations and had been leading people for a long time, I was not a programmer. But the company needed somebody with solid management experience and an ability to lead a young satellite office; plus, in an org with separate tracks for individual contributors (ICs) and managers, I would be expected to work with senior engineers, not be one. I thought I could probably bring useful skills to the team, but I was actively concerned I’d be laughed out of the company by the actual programmers.

In fact, I wound up developing some of the most mutually satisfying internal partnerships of my career. I’m no longer at that company, but I’ve stayed in engineering leadership. Here are some of the things I learned in that role that might be helpful if you, too, find yourself leading people with more technical expertise than you have.

Software development involves a lot more than coding

This is beyond obvious. You also need design chops! Product vision! Somebody has to sell the stuff! But beyond all those key functional skills, you also need people who have seen the common mistakes software companies make – and some of the possible paths to success. That perspective is key, and surprisingly rare, when it comes to organizing people so that you actually ship things customers want.

For example, one of the most common mistakes companies make is setting software launch deadlines far in the future and insisting on a fixed set of specific, complex features (or, more commonly, an ever-increasing set of such features on that deadline). In a best-case scenario, you meet the deadline but ship something customers don’t use, and you seriously burn out the team along the way. In the worst case, you never ship anything at all, and you seriously burn out the team along the way.

You don’t need coding skills to identify this losing pattern and suggest other ways your teams can approach their work (two possible winners: medium-length deadlines with a variable scope of work; or very short deadlines with a very limited scope of work). Convincing organizations to work differently is hard, and it’s helpful if you can explain why software projects with a fixed complex scope and fixed long deadlines will fail. But that requires understanding software development, not code. If you’re able to influence your organization to work in more productive ways, you’ll be enormously valued by engineering teams and the business at large.

Lack of technical expertise can be useful

First, being a non-programmer helps reduce confusion about roles, and it can give ICs a chance to grow as tech leads. But there are more subtle benefits, too. One handy thing about having limited coding knowledge is that nobody expects you to know much about technology, and you can ask anything at all. That’s cool because not only do you get to learn, but it also gives engineers a chance to teach you things. In an IC/manager relationship, the manager typically has more explicit power in the org chart. By giving ICs a chance to gain status as teachers, you can balance the relationship a bit which creates fertile ground for partnering on day-to-day org strategy and on bigger decisions.

At my last company, a series of reorgs left several internally-focused teams buried in groups whose customers were external. The structure made it hard for them to work effectively, which I recognized not because I was reviewing pull requests (I didn’t even have a GitHub account), but because I could see they shared a set of communication problems. I proposed that we form a new group to house those teams, that we could experiment with serving our coworkers in new ways, and that I could lead the group. The tech leads on those teams were comfortable with me in that role, even though among senior directors at the company, I had the least direct technical experience.

Among the ways I’d developed relationships with those tech leads is that each of them had answered my technical questions over the previous years and had dedicated time to teaching me about our systems. They knew that I trusted their judgment as engineers and that I wouldn’t interfere with their decisions. They also knew, in part from seeing the ways I’d used the things they’d taught me, that I had complementary skills to bring to the group – things like helping them align technical proposals with company goals.

Being technical isn’t a thing

In the weeks before starting that first engineering leadership job, I took a lot of friends out for coffee and asked them all for advice about managing engineers. I got plenty of good tips that basically boiled down to: engineers are people, too, so manage them like anyone else. That was useful to hear.

But much more intriguing was the comment a friend in DevRel at Google made: ‘Being technical isn’t a thing, so don’t worry about that.’ She said it with such confidence, I had to reevaluate the common idea that there are categories of people, those technical and those non-technical. I’ve come to realize that what she meant is that technical expertise is a thing that people develop, not an inherent quality people have. Moreover, expertise is a spectrum – a non-linear one at that – and there isn’t a point at which you’re either technical or non-technical. (Not to mention that it’s counterproductive to discount other kinds of expertise in organizations that need a range of skills.)

Real talk: it’s one thing to understand that idea, and it’s another thing to internalize it. When I left that job for another engineering leadership role, I asked a lot of the people I’d been working with if they had advice for me in my new job. One principal, two mid-levels, and one early-career engineer all separately said to me, ‘You don’t need to worry about being technical enough. You’re plenty technical.’ I was taken aback.

These were people who’d reported to me and had to teach me very basic things, like how a monolith is different from service-oriented architecture, or what React is. And yet, they didn’t think my lack of technical depth was a problem. That didn’t mean it was time for me to stop learning. Instead, it meant that I could approach conversations confident that we could figure out software problems together, each bringing useful questions. It also meant I wasn’t personally lacking as a ‘non-technical’ leader, and it wasn’t helpful to broadcast any suggestion that I was.

Not every organization is a good fit for engineering leaders who aren’t programmers

When I was ready to leave that company, it took a while to find a new role. That’s in no small part because lots of companies want engineering managers to roll deep in code – either because that provides an efficiency in the way they’re organized, or because their culture values a specific kind of technical fluency. That’s fine; in fact, it was a strong signal that those companies weren’t a fit for me. I looked instead for companies that already had separate tracks for ICs and managers. That suggested they were sufficiently mature to value management skills. I also looked for companies that needed engineering managers to lead teams and build cross-functional relationships, especially with Product. Those are all responsibilities that benefit from experience in software – but not specifically with code – and are things I enjoy doing.

Since moving on, I’ve talked often with ICs who used to work with me. They commonly say that they hope we get to work together again. None of them have laughed me off.