Image: iStockphoto/SeventyFour

Camille Fournier has two decades of experience building software for companies like Goldman Sachs, Rent the Runway and Two Sigma. She knows how to code. But that’s likely not why you may have heard her name. Fournier is also an expert on the topic of engineering management, having written a popular book on the topic, “The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change.”

It’s this second area that rightly gets Fournier attention, because it’s this human side of code that is most lacking. Sometimes we make believe that great software is a product of a lonely genius, hunkered down over her keyboard late at night. Sometimes this is true. But far more often, software is a collaborative, social activity that requires developers to be…social.

With this in mind, Fournier has offered a list of skills that senior engineers need to thrive.

So you want to write code…

Given how much time most of us spend time in meetings, Fournier’s first skill shouldn’t be a surprise: “How to run a meeting, and no, being the person who talks the most in the meeting is not the same thing as running it.”

For engineers looking for guidance on exactly how to run a meeting, there’s good guidance over on Hired, including asking the question whether a meeting is necessary at all. If you’re a manager of people (engineers or otherwise), meetings can be effective but they can also be expensive. The more people you have in the room (or on the Zoom), desperately wishing they were doing something else, can add up to a lot of money.

SEE: The best programming languages to learn–and the worst (TechRepublic Premium)

When you’re not meeting with a group, you might be asked to meet with folks one-on-one, and this is where diplomacy comes in handy. According to Fournier, two other skills include:

How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid


How to explain a technical concept behind closed doors to a senior person too embarrassed to openly admit that they don’t understand it

Just as Radiohead sang “anyone can play guitar,” some developers think that “anyone can write software.” They can’t. Or, rather, we can’t. Some of us can’t, anyway. Or, perhaps put a better way, some of us don’t. With that in mind, a significant part of your job as a deeply technical developer is to learn how to translate that expertise for those of us who aren’t as technical.

Two of the best people I’ve worked with who knew how to do this were colleagues of mine at MongoDB: Kelly Stirman and Jared Rosoff. On many occasions they helped to ground me in the why and how of difficult engineering concepts, which allowed me to participate in decisions (or in making sense of those decisions for our customers through writing). It’s a great way to hit Fournier’s Skill #14: “How to convince management that they need to invest in a non-trivial technical project.” It’s hard for management to buy in if they can’t grok the context of a technical decision.

And then there’s the fine art of getting stuff done without directly managing the people needed to do the work. Fournier has two skills that tick this box:

How to get another engineer to do something for you by asking for help in a way that makes them feel appreciated


How to lead a project even though you don’t manage any of the people working on the project

This need is critical in the highly common case of matrix organizations, where you might have a dotted-line connection to someone but no ability to declare what they must do. Often the trick is to better understand another’s goals and objectives, so as to figure out how to align your needs to their goals. But even with that alignment, gratitude goes a long way toward making people feel that it’s worthwhile to help you.

Fournier lists a number of other skills, but perhaps the tl;dr is this: Great engineering is as much about working well with others as it is about working well with ones and zeroes.

Disclosure: I work for AWS, but the views expressed herein are mine.