How to be successful in software engineering management

Comment: Software development is more than code, it’s also about working well with people. Management expert Camille Fournier offers engineers key advice on non-coding skills.

Image: iStockphoto / SeventyFour

Camille Fournier has twenty years of experience in creating software for companies like Goldman Sachs, Rent the Runway and Two Sigma. She knows how to code. But that’s probably not why you might have heard his name. Fournier is also an expert on the subject of engineering management, having written a popular book on the subject, “The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change.” ”

Must-read developer content

It is this second area that rightly catches Fournier’s attention, because it is this human side of the code that is most lacking. Sometimes we pretend that good software is the product of a lone genius hunched over his keyboard late at night. Sometimes it is. But much more often, software is a collaborative and social activity that requires developers to be … sociable.

With that in mind, Fournier came up with a list of skills senior engineers need to thrive.

So you want to write some code …

Considering the time most of us spend in meetings, Fournier’s first skill should come as no surprise: same as directing it. . ”

For engineers looking for advice on exactly how to run a meeting, there is some great advice on Hired, including asking if a meeting is really necessary. If you are a manager of people (engineers or others), meetings can be effective, but they can also be expensive. The more people you have in the room (or on the Zoom), desperately wishing them to do something else, can be a lot of money.

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

When you’re not meeting a group, you may be asked to meet people one-on-one, and that’s where diplomacy comes in handy. According to Fournier, two other skills include:

How to please a senior manager who wants to talk about technical stuff he doesn’t really understand, without rolling his eyes or making him feel stupid


How to explain a technical concept behind closed doors to a senior who is too embarrassed to openly admit he doesn’t understand it

Just as Radiohead sang “Anyone Can Play Guitar”, some developers think “Anyone Can Write Software”. They can not. Or rather, we cannot. Some of us can’t, anyway. Or, maybe better, some of us don’t. With that in mind, an important part of your job as a deeply technical developer is learning how to translate that expertise for those of us who are not so technical.

Two of the best people I worked with that knew how to do it were my colleagues at MongoDB: Kelly Stirman and Jared Rosoff. On many occasions, they have helped me understand the why and how of difficult engineering concepts, which has allowed me to participate in decisions (or make sense of those decisions for our clients through writing ). This is an excellent way to achieve Fournier’s competence n ° 14: “How to convince management that it must invest in a non-trivial technical project.” It is difficult for management to buy in if they cannot understand the context of a technical decision.

And then there’s the art of getting things done without directly managing the people needed to get the job done. 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 they feel appreciated


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

This need is essential in the very common case of matrix organizations, where you may have a dotted connection with someone but not the ability to declare what to do. Often the trick is to better understand each other’s goals and objectives, in order to understand how to align your needs with their objectives. But even with this alignment, gratitude goes a long way in making people feel like it’s worth helping you.

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

Disclosure: I work for AWS, but the opinions expressed here are my own.

Also look

Gordon K. Morehouse