A comprehensive reference for all topics related to becoming a great Engineering Manager
This pandect (πανδέκτης is Ancient Greek for encyclopedia) was created to help you find almost any resources related to Engineering Management and everything related to it.
Note Quick legend on available resource types:
⭐ - GitHub repository with the number of stars
📙 - resource you can read, usually a blog post or a paper
🗂️ - a collection of additional resources
🔱 - non-open source tool, framework or paid service
🎥️ - a resource you can watch
🎙️ - a resource you can listen to
Table of Contents
📇 Main Section | 🗃️ Sub-sections Sample |
---|---|
Essential Reading | Blogs, Books, Presentations |
Podcasts | Engineering Management, Leadership Podcasts |
Newsletters | - |
YouTube Channels | - |
Giving Feedback | One-on-Ones, Retrospectives |
Measuring Success | OKRs, NCTs |
Other Topics | Remote Work, Presenting |
📙 What is an Engineering Manager? by Michelle Kung from Amazon [Blog, October 2018]
📙 What is Engineering Manager doing in a product IT company - Grammarly case Grammarly, Original Ukrainian Post [Blog, January 2021]
📙 16 Leadership Principles - Amazon
16 Principals:
📙 Mistakes I’ve Made as an Engineering Manager [Blog, February 2021]
📙 Do engineering managers need to be technical? [Blog, November 2019]
📙 You Can Be a Great Leader and Also Have a Life [Blog, December 2018]
📙 PM & EM: Rules of Engagement [Blog, May 2021]
Find a catalogue of engineering blogs at Engineering Blogs Awesome List
Find more Engineering Management books at The Leadership Library for Engineers.
🔙 Back to the Table of Contents
🔙 Back to the Table of Contents
🔙 Back to the Table of Contents
🔙 Back to the Table of Contents
Remote work, especially after the pandemic, is not easy to get right and can make or break a good team.
There are three levels of remote work:
Remote-friendly
Remote-first
All-Remote
On the lowest level, you are remote-friendly. It means, that your company allows remote workers embedded into regular office teams. At this level, the meetings are online, but often tooling that is used in them is mainly concentrated in the physical meeting room. For example, engineering team meeting in which the ideas are still drawn on a physical whiteboard to which the remote participants get access afterwards in a form of a photo.
Remote-first is an approach to leveling the playing field of both office and remote workers. All tools used are digital, when something is drawn, i.e.
architectural design of a project, everyone does it in an online board. Regular watercooler chatter also takes place online, i.e. through a watercooler slack
channel, or regular daily scheduler watercooler chat session. In this way, remote workers feel included in every single facet of work. One of the best ways to
validate that you are indeed following the remote-first mindset is to regularly ask one of the office employees to join the meeting from a phone booth or a
another room and to then get their feedback on what they felt was missing for them as a remote worker. Of course, you can also get this feedback from your
remote workers, but those who regularly work from the office, will be able to better spot things they usually take for granted in the meetings they join from
the office.
All-remote is similar to the previous, in this case though, there is simply no more physical office and everyone works remote. This adds challenges to having really good tooling for all aspects of work. Best examples to learn about this are all-remote companies like GitLab.
One of the toughest challenges of working remotely is that the team often does not feel cohesive after a long period of working remotely. This is best solved through a combination of applying the right remote-first tools and techniques (see examples above), with a good balance of team building sessions. When it comes to team building, or just general watercooler chatter, it usually depends on the team. A good way to start is to try some of the following approaches:
Additionally, you can prepare more team centric sessions. For example, you can prepare a quiz about the team on something like Kahoot: find out some interesting facts about each team member and let people guess who the specific facts or descriptions belong to. It's a fun way to get to know your colleauges better.
In addition to that, you can also have these sessions in an online room on gather.town. It's a great proximity-based online meeting tool that allow you to control a physical 2D character in a gaming like fashion. It's especially great for bigger groups, as it's easy to have a quick chat within a small group very seamlessly.
Your first instinct after going remote might be to compensate the lack of office interaction with a lot of meetings, however, it will only lead to meeting fatigue within the team. A way to compensate for this is to bundle meetings into meeting days, i.e. only allow meetings (apart from standups) to be scheduled for 2 or 3 days out of the week. The other 2-3 days don't allow for any team meetings (standups and short watercooler chats are fine). The meeting free days will allow the team to work uninterrupted for a longer time and there will be no meeting anxiety either distracting them from technical work. The team members are still free to schedule pair programming sessions during any week day.
Of course, many meetings can be just an Email, so consider what truly requires a meeting. If you do need to call a meeting, make sure its well-prepared not to waste everyone's time. A well-prepared meeting usually includes an agenda that is shared beforehand. If a decision needs to be taken in the meeting, it's better to already prediscuss it with individual stakeholders that will join it.
The key to successful remote meetings is also documentation. Make sure you keep a meeting log on Confluence, for example. The most crucial part of it should be the decision record. Make sure to write down all decisions taken during the meeting and list everyone who participated in taking that decision. People will eventually forget that they either agreed to something or committed to do something, and having their commitment written down in the decision record will save you a lot of time in the future.
Working remote may hide work and slow down knowledge sharing if it's not done correctly. A great idea is to have regular demo sessions to show what the team has been working on (internally to teammates and to the outside).
Some managers may get an idea to have longer standups, additional end-of-the-day check-ins etc. Usually, this adds more stress to the team, and contributes to the meeting fatigue. An interesting approach to try here is to have the regular standup sessions as usual, but 15-20 minutes before the session, the team can write down their update in a dedicated Slack channel. This usually helps them to gather their thoughts and think about what they want to say in the standup. This way, the standups can be kept shorter, since everyone already has formulated their update in a written form and simply has to reiterate it to the team. Another benefit of this, is that the other team members can ask follow-up questions or propose solutions to problems right there on slack.
This also helps to have a written log of what the team is working on that can be then read by someone who was sick or on vacation, they will catch up very quickly on the team progress. It also helps you as a manager in case you need to write something like progress reports to other levels of management.
Find more at the Agile Glossary here.