dein.fr

Update (Feb 2017): I am keeping a list of resources for engineering managers on Github: engineering-management. I have also changed my mind about some of the points below, but certainly not the last two ones: management is an amazing responsibility, and it requires constant learning.

It’s demanding

“Humans are much more complicated than machines”: one never experiences this saying more than when moving from a technical contributor role to a manager one. While debugging can be an exasperating task, discouragement is a feeling all managers need to learn to control, both in their team and in themselves.

Interrupt becomes the norm. You will become a marketplace for priorities. As in any marketplace, the immediate cost is often evident, but the long-term value is never obvious. That’s why all managers should take some time to reassess all of their current priorities and see if they’re not missing one. For instance, it’s very easy to forget about managers’ priority number one (hiring) when dealing with a complex project.

As regard transitioning from a world where you are praised for the code you ship to a world where you are a multiplier of other’s work, it won’t happen in one month. It takes some time to find the good balance between under- and over-managing. I don’t think I found it yet. One way I balance contributing with multiplying is through taking small coding tasks that nobody has time to do, letting team members do the big and complex projects. This way I’m sure I won’t interfere too much.

Empathy is required

Empathy is the most important social virtue. French writer Montaigne showed a great deal of it throughout his masterwork Les Essais, for instance when describing cannibals. Similarly, managers should be always thinking about their team’s feeling, listening to their instincts. Do you feel that this person is not happy with her project? Do you think that those two engineers don’t get along well? You need to take action. “As the prayer of St. Francis goes, we must seek to understand more than to be understood [1]”. It’s not anymore about you - it’s about the team.

You also need to be constantly thinking about the consequences of everything you do. One thing that I learned the hard way is that anything that has the potential to be misinterpreted will be. For instance, when dealing with a project that is late, you might unwillingly make remarks that will be deemed disrespectful.

People often talk about “trust but verify”. My management framework is more along the lines of “be helpful”. You need to become an helpful resource to your team members. For instance, if you do quality code reviews, engineers will know you will help them improve their code and spot bugs. If you do good architectural reviews, engineers will know you will help them succeed. If you provide candid feedback professionally, people will know that you take on this difficult task to help them blossom.

You should keep coding

Should managers code? Programming requires long period of uninterrupted time. It is almost totally at odds with a manager’s role which is to be the person who will be interrupted so that team members aren’t. I once took a coding project to reduce the load on my team. The effect was immediate and lasting, with decreased morale and wrong product directions.

That being said, not doing any coding is too risky for a manager. Front-line managers will lose empathy for the difficulty of engineers’ job if they stop coding. If managers are supposed to lead by example, then coding is also a good opportunity to assert some of the principles you believe in (writing tests and documentation, having a clean API, open sourcing software…). If you aren’t coding, you won’t be as resourceful when helping new team members navigate through the code. You risk also losing a good understanding of the technology you’re using.

It’s easy to make a difference

Some of those action items are common sense - but as Voltaire puts it, “common sense is quite rare”:

• Acknowledge your mistakes often, clearly and early.
• Listen twice as much as you talk.
• Strive for your engineer’s success, not for yours. Yours will come as a consequence of theirs.

One simple thing that very few managers do is to ask what people would like to work on. It’s very easy for a manager to become a task dispatcher. Whenever you have the opportunity to do so, try to get a better understanding of what your engineer like to work on: front-end/back-end, clear/unclear requirements, user-facing/developer facing, Python/JavaScript… Brainstorm ideas instead of trying to impose your own, because your idea might not be the best, and people need to have some buy-in. Their happiness and the quality of their work will increase.

There’s a poster at Facebook that says “do things and tell others”. If your team ship awesome features but nobody knows, what’s the point? More than anyone else (especially for engineers who might think it’s a chore), you need to communicate with the rest of the company. This is also a good opportunity to find synergies with other teams. You’ll also stay on top of what your team is doing. Engineers on your team will feel rewarded and recognized for their work.

The virtue of disconnecting

Lean startup, agile, MVP, etc.: current development practices seem to recommend focusing on the act of implementing, at the expense of preparation. It is probably true that when solving problems through code, the emphasis should be put on the implementation. Things are moving so fast that most technologies are new for everyone, and only through shipping features will you be able to get a better sense of the problem.

Not so much with management: there is a lot of value in weighing pros and cons, listening to everyone (especially in interpersonal conflicts), taking some disconnected time to research and quietly think about the problem. It’s especially useful to seek mentoring when contemplating difficult decisions.

You will grow through mentoring

There are numerous resources on the web to improve your programming skills. There’s also a wealth of resources about management, though it’s less structured. The Software Lead Weekly has been very helpful to me - I’ve never seen such a good curation of content.

There is something fundamentally different with improving your managerial skills. While you improve your code through your peers, as a manager you very rarely expect other managers to give you feedback. Similarly, your team member might (and should) give you feedback, but they might not be able to give you the best way to improve. Therefore, the best source of mentorship is probably your own manager.

You need to have senior management really believe in management as a craft. Having managers who really care about their work, think highly of it and always strive to improve themselves is key. There is a multiplying effect: people who really care about their work infect others to do the same, creating a virtuous circle inside the company.

It’s incredibly rewarding

An engineer works closely with 2-3 persons. You have the awesome opportunity of working with your whole team (around 7 awesome engineers), other engineer managers, product managers, designers, etc. Your impact will also be much larger. There’s a high chance nobody will remember the feature you built in 20 years. But people do remember their managers, especially those who mentored them at the start of their career.

I would like to conclude with the following: there are numerous common points between parenting and managing. The main one is the following: everyone has an opinion about it. You need to seek mentoring, but you also need to find your management style. Especially when under pressure, it may seem simpler to embrace a style that is not yours (e.g. micromanaging). Resist the temptation, because it will backfire (it did for me). Your management style depends a lot on your own character - which you can always improve, but you can’t fake it. Through self-improving by experimenting and learning, you will blossom in this awesome role.

[1] Lencioni, Patrick M. (2012-03-14). The Advantage: Why Organizational Health Trumps Everything Else In Business (J-B Lencioni Series) (p. 33). Wiley. Kindle Edition.

Picture by August Gregg