Staff Front-end Engineer at Slack
October 29, 2018#front-end #web
Hi there, I'm a front-end developer currently working at Slack. In the past I was a developer and Engineering Manager at Expedia, and also worked at LinkedIn for a bit.
I used to manage a very independent and self-sufficient product engineering team where all of us wore many hats and our main goal was to deliver high quality software while continuously improving (ourselves and our processes).
After being a manager for almost 3 years I recently went back into being an Individual Contributor to get close with the code again.
I also write on Medium / Hackernoon when I am inspired, which happens to be around once a year.
When the opportunity to become a manager presented itself, I had been working in the team I would lead since its inception, so I knew the team and code very well.
I first became a Tech Lead, which at Expedia was a kind of "Manager in training wheels" where you manage one or two people for 6 months with the help of a mentor then, if that goes well, you're officially promoted to Engineering Manager.
In my case that went well, so after 6 months I started managing the two out of the three people in the team and hiring to expand it. During my time as manager the team grew to 14 people working from Europe and 2 locations in USA.
Right now my day-to-day looks like a lot of code, code reviews and design discussions, but back when I was a manager it looked a lot less predictable: Some days I felt exhausted and also like "I did nothing", when looking back it was not the case. I think it had to do with the fact that being a developer you are used to producing tangible things: code, pull request, deployments, etc. But as a manager your "deliverables" are much more abstract, if any, given that your main job - as I see it - is to cultivate the team and individuals that report to you, which means that you will have to do a ton of small things here and there - ad-hoc feedback, meetings, thinking how to improve the team's processes, socializing ideas, keeping the roadmap in check, etc. - but you might be pressed to find any tangible artifact as a result.
When I felt like that I remembered my self that, as a manager, the best way to measure your performance is measuring the team's performance: how is the team doing? how happy are they? As long as you can measure those, or a proxy for them, you can tell if you are doing a good job.
One of my biggest challenges was to get some of my team members to give me honest feedback. It took some time for me to build trust and adapt my communication style specifically to those team members, but in the end they felt comfortable enough to share the things that were bothering them, which cleared the air and helped me know what to improve on.
I didn't expect it, but after a while I realized that most of the job of a manager is about interpersonal relationships. You need to get along with many people: team members, peers, superiors, PMs, etc. in order to be effective at your job. For me it took a while to adjust as I'm quite introverted, but after a while I found myself checking on people and naturally building connections.
The best advice I was given was, for changes or improvements that could be potentially controversial, to socialize them ahead of time with your team members and implied parties one on one ahead of time to build consensus and work through the issues or questions that come up individually. Once you feel like the change has enough support, go ahead and announce it publicly. This way you avoid surprising your team members with changes which, in my opinion, is one of the worst things you can do: people need to expect what is going to happen and, more importantly, why.
I've never been in that position yet, but I guess I would tell them that becoming a manager is not easy at first, but can be very rewarding as long as you take pride and pleasure in building highly performant teams. I would also tell them that, while liking interacting with people is not a necessary requirement, IMO the best managers like interacting with people. Lastly, I would warn them that they will almost certainly have to give up coding at some point if they take the management path, which is something not everyone is willing to do - that was actually part of the reason why I went back to being an IC for now, I was not ready to completely give up coding yet.