The Power of One-on-One Meetings and Personal Connections

The Power of One-on-One Meetings and Personal Connections

As engineers, we generally prefer less talking and more coding. There’s a widespread belief that no one likes meetings.

I used to hold that belief. As a result, when I started leading projects, I procrastinated on scheduling regular one-on-one meetings1 with engineers on my team. Although I knew it would be beneficial and both my manager and my mentor advised me to do it, for varies reasons, I was hesitant and kept putting it off.

Finally, I had a few one-on-one meetings last week. They turned out so productive and useful that I only wished I started doing them earlier, even before I started to lead projects.

It’s a big learning for me to realize how valuable it’s to have personal connections with my team. It’s one of those aha moments that changes the way I see things. And I can’t wait to share my learnings with you. =]

This post covers:

  • Why I didn’t want to have regular one-on-one meetings;
  • Why I was wrong;
  • The benefits of one-on-one meetings;
  • Topics for one-on-one meetings;
  • My learnings.

Why I didn’t want to have regular one-on-one meetings

The specific case I have in mind is related to a teammate with whom I worked closely with. Since we sit right next to each other, we normally had quite a few casual conversations throughout a day, either related to the project or about random things. Considering we worked so closely together, I felt that we were on the same page and wasn’t sure if regular one-on-one meetings would add any value.

The second reason had to do with the belief I mentioned earlier that engineers dislike meetings. I was worried that that coworker might prefer coding over one-on-one meetings.

I also worried that it might be awkward. I had the impression that having regular one-on-one meetings and talking about your career goals and such are things you do with your manager. I wasn’t sure if my teammates would be comfortable to discuss those personal things with me. I was afraid of that potential awkward silence — as an introvert, awkward silence is definitely one of the things I wanted to avoid.

Lastly, because the team was in full speed execution mode, I personally also preferred to save those meeting time for execution. Since I preferred coding over meetings, I wanted the same thing for my team.

Why I was wrong

With doubts, I scheduled 20-mins bi-weekly one-on-one meetings with that teammate. I was so skeptical that I even left a note on the meeting invite suggesting that we could reduce the frequency if needed. But five minutes into our first one-on-one meeting, I knew I was wrong and was extremely glad that I scheduled the meetings.

It turned out all four of the concerns I mentioned about were completely invalid.

First of all, even though we worked closely together, we never formally talk about how we felt about how the project had been going. The one-on-one meeting was a good forum for that discussion. Although nothing surprising came up, it was still helpful and reassuring to learn about each other’s perspective.

Secondly, it didn’t turn out to be awkward at all. That 20 mins went by fast. Besides the project, we also talked about our own areas of focus for career growth for the next six months and how we could help each other.

Lastly, after our first one-on-one meeting, I definitely considered that 20-mins to be time worth spending. I now actually think it’s more valuable to allocate time for regular one-on-one meetings than spending all the time on coding. The next section will explain why one-on-one meetings are so beneficial.

The benefits of one-on-one meetings

1. They help you keep a pulse on the team.

As a tech lead, it’s critical to keep a pulse about how everyone on the team is feeling. If people on the team is not happy, sooner or later, things will go wrong. And regular one-on-one meetings are the best forum to check how each individual feels.

“regular” and “individual” are the keywords here.

Things change, so do people’s feelings. Getting on the same page once is not enough. Regular check-ins to make sure you stay in sync with how people feels are necessary.

Group meetings aren’t the most efficient way to listen to and address each individual’s concerns. One-on-one meetings allow both you and the other individual to have more dedicated conversations.

2. They help you build personal connections with your teammates.

One-on-one meetings are not only for discussing projects, but also for you and your teammates to learn more about each other.

I was surprised by the power of personal connections. Although my teammate and I only spent about 10 mins to talk about our personal goals, that 10 mins changed took our relationship to the next level.

Before the meeting, our relationship was around the project at hand. After that discussion, we became friends helping each other to grow who also happened to work on the same project.

That was a powerful transformation that helps forester lasting friendships.

3. They help you better understand where each person is coming from.

Because of the above two benefits, you will have better knowledge about each individual on the team. As a result, you will have an easier time to understand your teammates’ perspectives, which will also help you better facilitate technical discussion.

Topics for one-on-one meetings

Obviously, I’m new to hosting one-on-one meetings. But here is my small list of topics for one-on-one meetings.

  • How do you feel about the project so far?
  • What are the things we should keep, watch, and change about the project and the team?
  • What do you want to focus on in the next 6 months? And how can I help you?
  • What do you want to learn by working on this project?
  • Here are the things I’m focusing on, and here’s how I think you can help me.

My learnings

1. I have a tendency to overlook the people-side of things.

Being a goal-driven and task-focused person, it wasn’t natural for me to emphasize on the people-side of things. This experience showed me the power of personal connections. Now I notice this tendency, I will try to “over-index” on the people-side of things until it becomes natural for me.

2. Leading projects have more to do with empowering the people than checking tasks off the list.

I used to think leading projects is about making sure each individual task get done right. Now I gradually realize it’s more about making sure the people on the tasks are set up to success. When the whole team is on a good state, you will feel the team is pushing the project forward together, instead of you dragging it by yourself.

3. Sometimes, I should ignore my logic.

No matter what decision I make and no matter if it is right or wrong, I always have reasons behind that decision. Since my reasonings come from myself, they always sound right. For example, in this case, I did have reasons that sounded correct to myself for not having one-on-one meetings. As much as my reasonings seemed correct, I was wrong. Sometimes, I should just ignore my own logic and give other options a try. As stupid as it sounds, I shouldn’t assume the voice in my head is always right.

Anyway, I’m glad that I had this experience. I look forward to continuing this journey and learn more along the way. Life is good when you get to learn. =]


My career plan for the year is to grow into a tech lead. I’m excited about all the learnings ahead and would love to share this journey with you in a brutally honest fashion. I will be sharing my weekly learning on the blog.

In the next few months, I will focus on growing in the following areas. You can expect to see posts related to them:

  • focusing on the big picture of the project instead of near-term implementation details;
  • balancing my efforts between leading projects and coding;
  • work-life balance for long-term productivity;
  • the human side of software development: making sure everyone riding with me enjoys the ride and feels fulfilled and inspired.

[1] One-on-one meetings means meetings with only two participants.

Leave A Comment

Your email address will not be published. Required fields are marked *