Reflecting on Different Types of One-on-One Meetings in my Software Engineering Career

In the past year I have been reading more software engineering management books in order to learn about what I will be doing as I advance in my career to lead a team and mentor more junior engineers. I began reading books on this subject before my summer intern started in June 2021, in order to learn how to be a good engineering mentor. Some of my favorite books that I have read on mentoring and management include:

• "10 Steps to Successful Mentoring" by Wendy Axelrod
• "Mentoring" by Camille Fournier
• "The Manager's Path" by Camille Fournier
• "Become an Effective Software Engineering Manager" by James Stanier

One of the things that each book I read emphasized was the importance of having consistent (ideally, weekly) one-on-ones with my mentee or direct report. Benefits of having one-on-one include establishing rapport, empathizing with difficult situations, answering any questions the report may have, listening for signs of unhappiness or wanting to leave, learning about team dynamics issues as early as possible, and more. Not hosting one-on-ones consistently can even have extreme consequences like how for Camille Fournier, once her direct report quit the company because they said she did not make enough time for them; this was true because they had not had consistent one-on-ones.

Looking back at my experiences having one-on-ones with my manager in my software engineering career, I realized that I have experienced many different types of one-on-ones. I wanted to share things I learned from my past one-on-one experiences, and how those learnings are shaping how I see myself conducting one-on-ones when I lead an engineering team.

Curalate, Summer 2017, Philadelphia

At my summer internship at Curalate, I had a tech lead who I worked with 95% of the time and I had an engineering "people" manager who was on a different team. My one-on-ones were only with the latter. I was new to the concept of one-on-ones because this was my first working experience at a software company. Once every two weeks, we would meet in one of the glass door conference rooms and he would ask me how my internship was going and I would awkwardly answer without giving too much information because I was not sure how the information would be used and how it would affect my chances of getting a return offer. I sensed a low level of trust in one-on-ones because I did not work with my engineering manager on a day-to-day basis. Conversations seemed shallow, and I felt like he did not share information with me about the company so I did not reciprocate.

Looking back, I have noticed some things about the process through which I did one-on-ones with my manager that are different from my more recent one-on-ones. First, my one-on-one meetings were not held consistently every week; I think they were held every two weeks or even once per month. Second, the one-on-ones were in a conference room where people could see us through the glass door. Even though they presumably could not hear us, I notice now that the physical location did not give a sense of confidentiality due to the glass transparent doors. Third, my engineering manager was not the person who I worked with on a day-to-day basis, so it felt very useless to me at the time to be sharing thoughts on how work was going with someone who was neither my manager nor my skip level manager (my tech lead manager's manager). Actually, on second thoughts I think it is possible that he may have been my skip manager but this was never made clear to me and no questions were ever asked about my feedback toward my tech lead if that were the case.

In the end, I did get a return offer for a full time position from my engineering "people" manager, so I did think that was cool that he was the person of authority who advocated for me and secured me an offer. Information like this was not made clear to me in the beginning, and I was also too shy to ask in our earlier one-on-ones, which looking back I think is a failure on both of our ends.

Built Robotics, 2019 - 2020, San Francisco

My one-on-one meetings at my first job were very different from those at Curalate. One-on-ones were held with my tech lead manager on a weekly basis and lasted anywhere from 30 to 60 minutes. Unlike Curalate where the meetings were held indoors in a conference room sitting down, at Built Robotics we had a culture of always going on walks outside while chatting. I think that the company did one-on-one walks because we did not have any conference rooms for confidentiality, it is a Silicon Valley culture thing since the weather is great in California compared to on the East Coast, and the CEO just loved doing walks/walking work and the culture trickled down from him. Either way, I really liked going for walks for one-on-ones because at Built Robotics it was literally the only time when we could get out from the office without having to put it in the Slack #general channel that we were heading out and taking partial PTO off.

My manager and I walked the same ~1 mile loop each time as diagrammed below.

I enjoyed the walk-and-talk approach of doing a one-on-one because in the Built Robotics company environment it was a nice way to de-stress, stretch the legs, and get some fresh air. Besides that though, I felt that the medium of being away from the computer was difficult in that I could not show my manager things on the computer if I had gotten stuck, or it was more difficult to take notes on things that needed to be done. If I wanted to come prepared with questions for my meeting, I could theoretically jot them down on my phone as a note, but in practice this rarely happened. I acknowledge that walking has benefits such as confidentiality and it allows for a more casual conversation because walking is a casual environment. Given that our company did not have conference rooms, I think that walking outside was a logical one-on-one structure.

A separate funny story I wanted to share is that we were walking rain or shine. That was quite the experience doing one-on-ones while walking, with each person holding an umbrella.

WePay, 2020 - Present, Virtual

My experience of doing one-on-ones at WePay has been different. For one, they have been virtual. Like at Built Robotics and unlike at Curalate, my manager at WePay is the one that I work with day-to-day. As an individual contributor, I like this more because it feels easier to have an established, trusting relationship. This was my first manager who set up a private Google Sheet to track agendas for each weekly meeting and the notes from each meeting. Doing meetings virtually has also been different because it is easier to have notes pulled up, and if there are things that I request my manager to look into for me, sometimes he can look it up right on the spot since he is already in front of his computer. Having meetings virtually also allows a degree of flexibility to rescheduling meetings if things come up and also allows for meeting from different physical locations. Unlike at Curalate where I was constrained to an office conference room and unlike at Built Robotics where I was constrained to walking the same loop every week, at WePay I have met with my manager on one-on-ones while I was in Los Angeles, the Bahamas, and more, or vice versa for him as well.

My manager and I meet on a weekly basis and the exact time and day has changed as our team size has changed, and I think that has been okay and easy to coordinate. One downside of virtually meeting is that sometimes it has been easy for me to forget about a meeting if I miss the Mac Calendar notification and the phone notification. For instance, one time I was working in the office and stepped out to use the restroom, and because I did not have my laptop and phone with me, I ended up forgetting about the meeting until my manager pinged me several minutes into the scheduled meeting.

One thing I learned from my one-on-one experience at WePay is that it is helpful to have a private Google Sheet one-on-one tracker document. It is helpful for the direct report to add things that are on their mind; it is helpful for the manager to prepare; and it is helpful to write notes with action items so that actionable items are not lost.

Conducting One-on-Ones When I am a Manager

The first thing to preface here is that you do not have to be a manager to start conducting one-on-ones. I actually started conducting one-on-ones this past summer when I was the intern buddy / tech lead for my team's summer intern. While my manager held formal one-on-one meetings with my intern to cover more people / company culture questions, I met with her each day to talk about her project and answer any questions she had. We met in the office a few times and also brainstormed together on the whiteboard. I would consider this as me having run one-on-ones that cover technical aspects of a project, and I would mostly direct her people/company questions to my manager.

When I am a manager, I have an idea of how I want to conduct one-on-one meetings. My idea is a combination of things I have learned from formal software engineering jobs, from informal work-study jobs in college, and from the books I have read. Here is what I am thinking:

1. One-on-one meetings every week at the same time.
2. The time should be set by my direct report because this is her meeting and is meant to benefit her mostly (although I benefit as well from listening and making decisions based on info I have)
3. Have an agreement of confidentiality, meaning that I will not share information that my direct report tells me with others unless I have permission to. Confidentiality is encouraged by many books because it promotes more openness of sharing information.
4. Use a private Google Sheet to track items to add to the agenda, notes that were talked about, and actionable items to be done by whom.
5. Stay away from walking unless there are no conference rooms or spaces where a meeting can be held in private. A walk once in a while is fine if the direct report likes meeting in that fashion and if it is on a day where access to a computer and to taking notes is necessary.
6. Until the team grows to a larger size where an engineering manager holds one-on-ones and a tech lead does not, I would like to have a system where I as the tech lead hold one-on-ones. I believe that the size when the team transitions is when there are more than 4 or 5 engineers, but time will tell.

As I continue to see more things in my career, this list will change and get better.

Conclusion

I hope you enjoyed hearing about my different one-on-one meetings in my software engineering career so far. I remember when I was in college my roommates who had done summer internships in San Francisco told me about their one-on-ones walking in circles around a park and at the time I thought that was such a weird, Silicon Valley-only concept. Contrary to what I had initially thought, I have learned that one-on-ones are a very useful tool for an engineering manager. Specifically, I have observed that the environment in which a one-on-one meeting is held should be carefully engineered to facilitate candid information sharing. The way that one-on-one meetings are engineered is not a cookie cutter one design fits all because different direct reports will have different preferences for one-on-one meetings. I think that ultimately the engineering manager should structure the one-on-one meeting based on what is convenient for the direct report, not what is convenient for the manager.