Note-taking and Documentation for Engineering Managers

During my time at Venmo as an engineering manager (since October of 2019) there are some note-taking / documentation things that I started doing that I hadn’t done before in my previous engineering manager gigs. In looking back I’m glad I started doing these things and would highly encourage others to consider doing them for your team as well. These are simple practices that don’t take up a lot of time and the hardest part of all this, really, is to just remember to do them.

Put 1-on-1 notes in shared documents

Since starting at Venmo I’ve been entering in notes from my 1-on-1 meetings in shared documents (shared between just by myself and the other person). While I don’t capture every little detail that’s discussed during my meetings, I do capture all the important gist of what’s discussed and most importantly - I capture any action items for myself and the other person. I also make sure to document any follow-ups I promise to the other person (eg, getting an answer on a question I need to ask around and/or dig into).

With each person I do 1-on-1s with, I encourage them to add to the shared document things they want to bring up at the next 1-on-1. While not everyone who I conduct 1-on-1s with do this, I’ve found that with those who consistently do this, we tend to have richer conversations because it sort of forces them to think about what it is that they want to talk to me about prior to sitting down with me. To be clear - it’s important to me that people feel comfortable reaching out to me at any point during the workday whenever they have pressing things they want to talk to me about and that they don’t feel forced to have to wait until the next 1-on-1 with me.

I would say that the major benefits of putting 1-on-1 notes in shared documents is that it provides transparency & builds trust. When I think back on 1-on-1s I’ve had with my own managers, I wasn’t too fond of 1-on-1s where note-taking did not take place because my experience has been that when things aren’t written down, they are very frequently forgotten. However, I also know that when I’m in 1-on-1s and the other person is taking notes, I wonder what the other person is writing down (especially if the other person is my manager) and there’s a small part of me that gets a bit nervous about what the other person is writing down. By having notes in a shared document I think it 1) allows the other person to have increased confidence that whatever important things are being discussed won’t simply be forgotten soon after the meeting is over and 2) provides transparency on what is actually being written down.

Enter (most) meeting notes into a wiki

Soon after starting at Venmo I decided that whenever I capture notes from various meetings I’m in, it might be beneficial for me and my team if I were to store my meeting (outside of my 1-on-1s) notes in a central place that serves as a notes repository for myself and the team. I decided to create a new page in Confluence (the wiki tool that we use) for the sole purpose of capturing notes. Whenever I was in meetings where I felt that there’s information that’s being discussed that people who aren’t present in these meetings might want to know - I decided to add the notes in the wiki page. And whenever I add notes into Confluence I take an extra minute to copy and paste the notes into my team’s (public) Slack channel. These are practices that I encourage folks on my team to do as well and it genuinely makes me happy whenever people on my team do this–especially when the notes pertain to meetings that I wanted to be at but couldn’t because of schedule conflicts on my end or because I was out of office.

I know a lot of people email notes that are captured and this is certainly way better than not sharing notes at all. However, I think putting all notes into a single place makes it much easier for people to go back and search through notes. When I initially began doing this I was worried that there would be way too much content on a single wiki page and that it would be too difficult to find what you’re looking for once there’s significant amount of notes have been accumulated. This, however, hasn’t been an issue for me in the the last ~1.5 years that I’ve been doing this. Each note entry on the wiki page has a title & a date stamp and this has been enough in keeping the page organized.

Keep in mind - I obviously don’t do this for every single meeting I’m in as there are certainly meetings I’m in where whatever is being discussed is probably not information that should be publicly shared with others on my team/in the company.

Other beneficial documentations

There are a few different kinds of documentation that I proactively try to provide for my team and they tend to fall into one of the following buckets:

• Process documentation: I’m convinced that everyone could do their job a little bit better, easier, and faster when they have clarity on certain processes that they should be following. This is most definitely true for new/newer employees but I’ve found this to be true for veteran employees as well. On the team that I manage for instance, we have a process around general steps that each developer should follow as they write and eventually merge their code. It’s a process that we established early on when our team was formed a year and a half ago but over time the process has been evolving. Not only was it my responsibility to create the initial “software development process” document but it’s also been my responsibility to keep this process documentation up to date to keep up with the evolving process.

• “How to” documentation: Whenever I come across a way to do something that isn’t written down and could potentially benefit others if they knew how to do this, I’ve made it a point to take some time to write it down in Confluence and share this information with others on my team and whoever else may benefit from this information. The most recent such documentation I wrote up was a workaround around being able to share audio during presentations over Microsoft Teams (really silly IMO that there isn’t a good way to do this on macOS Teams client yet). When I discovered this workaround I knew that I could not possibly be the only person in the company who is wanting to be able to share audio during presentations so I took 15 minutes to write something up & shared it various folks. I’d like think this was 15 minutes very well-spent.

In closing…

During my 6+ years of being in engineering management, I’ve become increasingly obsessed with helping folks I manage be able to do their jobs better, easier, and faster. I’ve learned that writing stuff down AND sharing with them (because undiscovered documentation is pretty much useless) is a very concrete way that I can make a difference in this area. As an engineering manager I can be prone to feeling useless from time to time because I’m no longer making the kinds of direct impacts that I used to make as an individual contributor. I’m no longer pushing up massive amounts of code like I used to. I’ve found that writing & sharing documentation that enables others to do their jobs more effectively is a great way to protect myself from feeling useless (which is a feeling that I think all people managers experience from time to time) and reminds me that my job as a manager is to do the things that enables my team/others to do their jobs more effectively.

• 2023 2
• 2021 6
• 2019 1
• 2018 5
• 2017 9
• 2016 25
• 2015 6
• 2014 6
• 2013 15
• 2012 16
• 2011 8
• 2010 13