On Being an Engineer Manager (2017)

In this post I will share what I learned throughout the last year (2017) as an engineering manager of 10 people and how it has impacted me, as a professional.

A manager should act as a buffer for his/her team. New features, spec changes, requirements are a constant flow. Before even bothering engineers with these, I try to filter out the noise.
A manager should be optimistic. A team’s moral compass is highly influenced by their lead. I am skeptical and pessimistic by nature, I find it to be somewhat of a struggle to keep a positive outlook. In this particular point, I failed.
As a manager, the company comes first, the team second and the individual third. I will never commit to things that are impossible to deliver and will always try my best to come up with a compromise. Ultimately the company’s success is what allows people to have a living: mine and everyone else. Individual egos must be kept in check, since these can negatively influence the dynamics of the team, decrease the productivity and the overall happiness. Software engineering can become an intellectual exercise sometimes, where we are just “kids” trying new technologies, and there is room for this, but I keep in mind that we have a responsibility towards our stakeholders, users and investors.
My context switching ability has improved. I am able to switch between code, helping an engineer and talk about requirements with a product manager without too much effort.
My negotiation skills also improved, I used to start a conversation with “no”, now I make a conscious effort to say “no, but” and present different alternatives. Thanks to a fellow engineering manager, I learned to make the distinction between what needs to be built and when it needs to be done. This innocuous detail makes me have a better judgement of the situation.
On the other hand my ability to focus on a task has dropped considerably. I am no longer able to code for 1h straight. I would say that 15 minutes is a victory. This is a problem I will try to fix somehow during 2018.
My technical abilities are still sharp, mostly because I spend a lot of my free time looking and writing code. But I can no longer just rely on my day-to-day job to be up to date. I do a lot of code review (around 2-3 hours per day), which in a way helps me, but PRs typically are laser focused and don’t provide the overall picture.
My UIKit skills are not what they used to be, but to be honest I haven’t had fun doing UIs in a while. This makes me think if this is because of the overall mess that is using UIKit, or if it’s just my personal taste that has changed.
When coding I try to be out of the critical path, doing things that are non-essential. I target areas that wouldn’t block a release from happening (although I have failed this on one occasion).
I enjoy developing a lot, and this has been one of my biggest endeavours: giving to other engineers features that I would like to do myself. This has proven to be more difficult than I initially thought.
Having awkward conversations, about missing a deadline, a particular behaviour, or some other thing, has created a psychological burden in me. In some cases it actually keeps me awake at night, thinking about some displeasing situation, which of course has ramifications in my overall performance later. I think this is because these people are not just my colleagues, but friends. Striking the balance between keeping a good relationship and having a tough conversation is tricky and no article or book prepares you for that.
A lot of books and blogs advise on having 1 on 1 meetings. I do have them every two weeks for half an hour, but, and this is my own failure as well, a lot of times the conversation leads to the status of the project. I don’t think this is the point of those 30 minutes, since it just becomes a mental exercise around jira tasks status. This post gave me some useful guidance that I will put into practice in 2018.
That warm feeling you get after shipping a feature is gone. In half a year, the imposter syndrome hit like a train. As a manager, it’s difficult to quantify what I, as a single individual, deliver. For my superiores, what I accomplish is a bundle of all the projects I lead, for myself not really. Having ownership of a particular part of the code, is something that as a developer makes me proud, it boosts my self-esteem and makes me feel needed by the company. As a manager, I feel that the team would just run on its own and that I am easily replaceable. This last part might be true, but I fear my insecurities also play a role in having this sentiment.
When WFH or during vacation I am propense to micro management. I am glad our team has an environment that allows my engineers to be frank about it and tell me directly. If that wasn’t the case, I would probably never have noticed this behaviour. This is something that I feel has improved, but there is still work to be done.
I am particularly proud of hiring a world class team this year: Anders Ha, Serg Dort, David Rodrigues, Diego Petrucci, Michael Brown and Wagner Truppel. All these people were sourced by me, or indirectly referred (Serg used to work with Wagner). Hiring good people is f&%ing difficult, don’t let anyone tell you otherwise.

My goals for 2018 are:

Have a more positive outlook.
Be nicer.
Improve my ability to focus.

I would like to end this post by sharing some sentences, typical from books that you can find in the “Self-help & personal development” section, but nevertheless have helped me:

Take each day as it comes.

Rome wasn’t built in a day.

Be patient, good things take time.

After the storm comes a calm.