Note: This article is translated from Japanese to English by myself. (Japanese one is here)
I made the following tweet over six months ago.
I didn't say it too loudly though, I thought my learning motivation increased and my technical skills grew after I became an engineering manager.
https://twitter.com/ohbarye/status/1110584464856354816 (The original tweet is in Japanese)
This tweet gathered some certain Likes, then I thought it would be a little worth to supplement my thoughts and experience by writing an article.
As far as I can observe, there are a lot of people who think negatively about engineers becoming managers. They say, "Managers can't have time to write code", "Managers' tech skills gently decrease", and etc.
I believe those ideas are true in most cases though, I'd like to put my personal experience as a counterexample.
Disclaimer: Of course, I admit that there are many cases in which it is impossible to write code and a manager's technical skills are reduced. This is a just personal breakthrough story that my technical ability has grown by comparing the past with the present.
Background
I became an engineering manager in 2017, about two years ago. Before that, I had worked as an individual contributor for 5 years.
As I wrote in article (Sorry, in Japanese) in the past, at that time, I was frustrated that "my growth phase was over just by continuing everyday tasks". But I didn't know how to seize more growth, how to find a problem, or how to make a proper solution.
However, working as an engineering manager, thinking about what to do in that position, and re-examining what I want to do often led me to improvements in technical capabilities.
In this article, I will write about personal experiences like that.
Why I was able to grow
In my opinion, there are two reasons: First, the influence given from my position, role, and surroundings. Next, the increase in pressure that I have on myself.
Influence from my position, role, and surroundings
When I became an engineering manager at Quipper, all the members (subordinates) were high-level colleagues who could complete their tasks on their own. The reason I became a manager was only that I spent a long time in the company relative to other employees. I never thought that such excellent members needed growth support or thorough coaching.
Even under such circumstances, there were goal setting and evaluation as an engineering manager's tasks. For this reason, I thought that "being able to talk with members about technical issues and actions to achieve them" is the minimum requirement for a manager, and it was necessary for me to try hard to pass the line.
I didn't think it was mandatory to cover all areas where I didn't keep up with members, but members sometimes raised issues that I wasn't aware of at all, so I knew my shortage regularly. This was directly linked to an increase in learning motivation.
Great engineers give insights even in a chat
Yes, I learned a lot from 1-on-1 that "I can learn from just chatting with a great engineer."
Regularly, I was blessed with the opportunity to see and hear a great engineer's skills backed up by experience and knowledge, such as how to find solutions to problems, thinking processes, how to make plans and execution ability. It can be said that it was thanks to the observation of the members for evaluation more than when they were just colleagues for me. Although 1-on-1 is never done only by the relationship between a manager and a subordinate, it is a fact that there are inevitably opportunities for exchange and chat.
I started to feel that it could be even better to make such chats and exchanges happen not only in 1-on-1 but also in daily work. And I started thinking about cultures, behaviors, skills, and ways of thinking that make it happen naturally. This article (Japanase) that introduces "working out loud" concept is for that. I didn't deeply think of this kind thing until I became an engineering manager.
Leverage hiring and mentoring opportunities
This is not limited to engineering managers though, as I become involved in recruitment activities or become a mentor for a new employee, I got more opportunities to be asked and to explain more about technology.
It is not enough to know the technology used in my company, but I should know why we are using it, why we are not using the alternative technology that has become popular in recent years, what issues exist around the stack, how to deal with the issues (technical roadmap). It is necessary to understand to the extent that it is possible to answer questions that have been deeply explored several times. This pressure is also useful as input for skill improvement.
Increased pressure I put on myself
What I have said so far has been that the necessary level has been raised by calculating backward from the situation and role that I was placed. On the other hand, there were often chances that led to success by raising the hurdles imposed on me by myself.
Although it wasn't originally eager to be a manager throughout my career, I asked myself "what would you like to be if you become a manager?". Some answers were "technically reliable manager" and "known in even out of my company by being on a stage of big conferences". (Knowing that it is not what other people want me to do, I put them on the extension of my ideal engineer image)
This is an ego because nobody forced me to become a manager with high technical skills. What manager I should become would be supposed to be decided by meeting expectations by talking with surrounding members, not what I wanted to be. Having said that, it just easily gets boring if I work for only other people's expectations.
I wanted to follow the path where my ideal manager image and my ideal engineer image overlap as much as possible, and as a result, I put pressure on myself to "strengthen my technical skills".
More concrete examples
Things I was careful in my work
If I double as a manager and a developer, I need to make sure that I do not become a bottleneck. As a result, a shift to tasks with no deadlines or relatively loose deadlines happened.
For example, updating libraries and frameworks, eliminating technical debt, removing unnecessary functions, and improving the CI / CD area. Tasks whose importance is high but their urgency is low. I found that I didn't have the skills to create opportunities to do them. By working on these, the range of technical capabilities expanded.
Involve surroundings
Also, even if I work on these tasks alone, it's necessary to have my colleagues review my work and to hand over to my team members. So I mastered how to involve the surroundings for achievement and how to have my deliverables run on production with less effort.
This is also part of the technical capabilities in a broad sense.
Choose what to do
I mentioned that my tasks had shifted, but in fact, not only it changed naturally, but also there were more opportunities to choose what to do by myself.
If team members are excellent, projects would proceed without any manager's interference. I had to think about what task is a high value to work on. This is an ideal environment but at the same time a hard mode.
Output outside of company
Outside of work, the number of actions that are conscious of output has been increased. This is what I wrote in another article (Japanese).
- Contrubite to OSS
- Create more personal hobby apps to learn new things
- Give presentations in conferences and meetups
- Organize a meetup for my interest
I was conscious of the output and chose a project and how to work carefully. Although they were possible without being a manager, it was good that I could use my position and role as a reason to push my back.
Did those things never happen if I'm not a manager?
Looking back now, there was no need of being an engineering manager to make the above-mentioned efforts, processes of work, ways to imporove skills. Even if I was just an individual contributor, none would stop me doing such things. All I needed is to just do it.
However, to be fair, I should say it is a fact that the manager's position is often more advantageous in terms of ease of transfer of work, ease of movement, and ease of task adjustment. Even in a flat and transparent organization, some kind of information is quickly notified of managers, which can help find issues across teams.
For me, an ordinary engineer like me, one of the survival strategies is to create an opportunity to improve technical skills using the manager's position and role.
As an aside, there is also the idea of a pendulum model that goes back and forth between managers and engineers without making the roll change to managers irreversible.
Reproducibility
What I wrote above is a completely personal experience, so I'm not sure if it is reproducible.
The previous two years and the next two years would be quite different even in the same environment, so I can't say "Yes, you can do it" even at my company. But at least there is a manager (me) who behaves as described above, I think there will be plenty of opportunities in the future.
Engineering managers work differently depending on the company or team, so I really don't know how effective my story is in other companies!
However, I believe that it should be a general goal for managers to be able to make appropriate delegation and create and select valuable tasks, so it would be nice to see examples and impressions similar to those of me.
Top comments (0)