What I learned from becoming an Engineering Manager

What I learned from becoming an Engineering Manager

Managers of engineers face a true challenge. They should stay on top of the technology, mentor, empower, and be attentive to all team members, while at the same time remain responsive to other organizational interfaces and to their own manager. In some organizations, team leads are also expected to stay hands-on and keep developing code!

The challenge increases two-fold when considering that the managers themselves were engineers prior to becoming managers. The transition is very hard, since managing people requires a very different skill set than being an engineer. Getting used to the vastly different daily routine usually takes a lot of time.

Sharing here some of my thoughts on developing my personal managerial style:

1. Meaningful 1:1's

Having meaningful conversations leads to healthy relationships. While 1:1 weeklies are a great platform for preventative maintenance - they allow check-ins on main topics and removing blocks, those meetings can be used and leveraged to achieve a lot more.

These meetings are incredibly important and are often overlooked by managers. Having an open conversation with all of your developers pinned in the calendar on a weekly basis is the foundation of collaborative work. It’s a must for managing humans, IMO.

Here’s what I think is most valuable to have in mind while planning your weekly 1:1's: 

  • Safe space to vent: I start by asking questions that open the discussion for sharing any frustrations. By doing that, I am providing an expected and safe place to spit out thoughts that make it possible for me as a manager to draw a calming picture for  the team member, who may be in flux about some miscommunication. It also gives me the opportunity to become aware of anything that requires my immediate attention. Plus, people sometimes need to get things off their chest. And that’s understandable. I want my team to know I’m listening.
  • Conduct discussions which would not have happened otherwise: I ask for ideas, or leading questions like: ‘What are your thoughts on x or y?’ Or ‘What would you have done differently?’ - then we spend time talking about those thoughts and ideas. If no new idea comes up at that point - they will usually come back with a few by our next 1:1. But people usually have a lot of ideas. And more often than not they don’t share everything with their manager. The 1:1 meeting is a chance to speak up and brainstorm about your team member’s brain child. This creates the amazing opportunity to actually help push their ideas forward, but also creates a positive psychological effect - people are more likely to hear what you have to say after you’ve carefully listened to them.
  • Agenda is dictated by the team member. I make sure to let the team members lead these meetings - That passes a strong signal to your team member, that you are not  piggybacking the 1:1's to drive your own agenda, or to just check up on their tasks status.

Tip: Here’s an idea - to keep this informal, you can call the calendar invite with something creative, like “Alice and Bob meet to talk about anything”.

2. Set a high standard

I challenge my team to aim high, make no compromises and leave no room for mediocrity. I push for expertise in all fronts - coding, analysis, technology, communication.I find that when this level of conversation is achieved, everything else falls into place. 

Your A players stick around when they can express themselves and feel challenged. All team members benefit from becoming experts and getting a good reputation within the organization, and candidates also get that vibe - which makes it easier to recruit other A players (which is a near-impossible task nowadays).

So when a developer on my team tells me about challenges they meet and solutions they come up with, I always ask as many questions as I need to understand. It’s easy to get lost in details, or not to carry through on those various threads of conversation.

More often than not, this sends either me or the developer to another iteration of doing more homework - either learn more about the technology, the requirements, our product. I see a vital part of my work is that follow up - I make sure we both do the homework. We work this idea together - while my role here is mostly to provide a broader perspective and to make sure we turn this idea into a live thing. This genuine type of discussion leads to a better quality product, architecture, and ultimately - it’s just more fun!

3. Team values

I care greatly about the team values - how we work together and how we interact. Defining and considering those values - helps prioritize and put those principals into actual work. For me those values are being transparent and respectful at all times, while constantly sharing our knowledge with one another. 

Once I had those values nailed down, I could build them into the day to day team interactions. 

A fruitful discussion can be done via  IM (e.g. Slack), over a Pull Request, or F2F (god forbid, should COVID-19 finally leave us alone). Email is fine sometimes. I find that applying the following principles keeps the team discussion interesting and engaging for everyone:

  • Respect the discussion: Genuinely listen to other people’s feedback and opinion. Make sure to hear them out and address any point they make. Try to relate to their point of view. 
  • Empower and enhance learning for others: Make it safe to ask questions. Encourage curiosity, and provide a broad perspective of your own which can light up additional directions for learning.
  • Provide as helpful and transparent information as possible: Team members should share their workflow, the challenges they meet, design decisions, API’s they expose, etc. in great detail. Documenting the process as well as the end result is encouraged. This lets people into other people’s work more easily, and facilitates the discussion.

Final note

When done consistently, these behaviors diffuse into the team’s culture. It sets an example of how to strive for excellence and empathy at the same time, and ultimately as a manager I am inspired back by the amazing things that members of my team build.

We’re also looking to add another Frontend Developer to our team at Applitools - if you’re up for the challenge, feel free to reach out, or just ask me anything at [email protected] . I love connecting with new people.

Yoni W.

Software Engineer at Booking.com

2 年

Great post!

回复
Roni Stern

Head of Product at Playtech

3 年

Thanks for sharing! I can relate to everything you wrote, even though I manage product personnel and not engineers. Not saying that managing people is easy, but I try to live by a simple rule: think what you would like to get from your own manager, and try to provide the same to your team. On that note, I also consider 1:1's very important and sad to not be able to do them often enough. Also, I think one of the most important things is to know your team members' work. Always be in the loop of what they do - it keeps them engaged and empowered, and as important - it keeps you fresh and up-to-date.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了