This post was first published on CoderHood as 7 Best Ways to Make One-On-One Meetings More Productive. CoderHood is a blog dedicated to the human dimension of software engineering.
In most general terms, a one-on-one is a meeting between two people. In the corporate world, it is associated with a discussion where two people exchange candid feedback, share concerns and discuss how they can be more helpful to each other. It is also used to describe a meeting between a manager and one of his or her employees. The latter is the case I am going to discuss.
The one-on-one I am going to discuss post is a meeting between a software engineer and his or her boss.
Early in my career, I had bosses who didn't schedule regular one-on-one meetings. The relationship I had with those managers was made of rare interactions. I didn't know them, and they didn't know me. They only knew me from the work I did and the occasional casual conversation. At the time I didn't think of asking for more regular interactions, mostly because I didn't believe that it was something I had to initiate. Talking to my boss in a closed room setting was a rare occurrence, often reserved for specific brainstormings, promotions, or salary raises.
Having effective one-on-ones should be a priority for both managers and employees. The following 7 tips will help you make the best of that critical time.
You need to make sure to schedule recurring one-on-one meetings. The frequency and duration depend on the personalities of the people involved. With my direct reports, I tend to do 30 minutes every two weeks. In some cases, I do 30 minutes every week, and in other situations, I do one hour every week. Some people need more time to talk than others, and the schedule should be flexible to accommodate the needs of the people involved.
One-on-ones are important, and they must be a priority. I try as hard as I can not to cancel them, and I take them very seriously. During the one-on-one time, I become aware of issues and situations that I would not otherwise know about. If I didn't have one-on-one meetings, I would be blind to many important aspects of my group. Most of the best decisions I've made were the result of one-on-one discussions.
With that said, remember that scheduled one-on-one meetings are not the only time you should be talking to your boss or your employee. It is more of a reminder, a forcing function that exists in case life gets busy, you get distracted and forget to have interactions. Outside of that time, one-on-one discussions should occur anytime there is something important to talk about. If you already talked and there is nothing new to discuss when the scheduled one-on-one time arrives, just skip it.
If there is an agenda, it should be established by the employee, not the boss. The boss might have some items to talk about, and he or she should bring them up if there is time left. However, if there is no time during the scheduled one-on-one, a separate meeting can be arranged by the manager to discuss those items. The intent is to keep the scheduled one-on-one meeting focused on the employee's agenda.
The agenda doesn't have to be formal. It doesn't have to be written or shared in advance. One-on-one meetings and brainstorms are the only meetings where I do not believe the time should be pre-planned in details. Just like in a brainstorm, there is great value in keeping things informal and free-form.
Get in a proper mindset before the meeting. Don't go in thinking about other stuff, and rushing to get through it as if it was a waste of your time. Take a few minutes to clear your mind, and make space for the person you are going to talk to. Review your notes from the previous one-on-one with that person.
Unless you have to, do not bring your laptop to a one-on-one. The separation that a laptop produces between two people is a barrier that should be eliminated. Take notes the old-fashion way, with a notebook and a pen.
Prepare to connect and be actively present. If you can't get in that mindset, take your one-on-one to a coffee shop or somewhere outside of the office. Stepping in a different environment will help you get out of your head.
A one-on-one is a time for the employee to talk and drive the conversation, and for the boss to listen. As a general rule, if the manager is speaking more than 10% of the time, he or she is talking too much. For example, if your one-on-one is 30 minutes long, the boss should speak for 3 minutes or less.
I am a believer in servant leadership, and to be able to serve my employees I need to understand their concerns, their struggles and their points of view. I need to listen to them carefully and empathetically.
When you are in a one-on-one with your boss, drive the conversation. Be open and let them know what's on your mind. Don't hold back! That is your time to bring feedback to them about what they could be doing better, or ask for their feedback and guidance.
If you don't feel like you can be open with your boss, try to find ways to change that. If it is impossible, you might want to consider finding a new job or switching groups. A boss who is not interested in listening to you is not a boss you want to work for.
On that topic, make sure not to confuse "the boss is not listening" with, "I don't like what the boss is saying." The two are very different things. You want to be heard, but you can't always expect to like what you are being told. Listening goes both ways.
Sharing concerns is an essential aspect of one-on-one meetings. That is especially the case in software development. Software engineers spend much of their time in a state of deep concentration. In that state, concerns are often buried in the shadow formed by sustained focus. If these concerns are not allowed to surface, they tend to poison the developer.
Sometimes developers are not aware of these concerns until they have a one-on-one with their boss or a colleague. Talking freely and sharing ideas brings concerns to the surface and relieves much of their negative power. Sharing concerns is a form of cleansing, and it should be taken very seriously.
A word of warning: Do not overdo it. If all you do most of the time is bring concerns up, and you never try to find possible solutions, you might end up being seen as a complainer. There is a fine-line that needs to be respected, and balance that should be kept in check.
Try to bring up concerns together with suggestions for solutions. If you don't have a clue on what a solution could be, ask the person you are talking to for a brainstorm. Focus on the prospect of a solution, not just the existence of a problem.
Your career management is not your boss's responsibility. Your boss can help you, but it is your duty to drive it where you want it to go. One-on-one meetings are an excellent time to brainstorm career aspirations and become aware of what you want to do and what you need to do to get there.
For many software engineers, career goals are often expressed in the form of the type of projects and technical responsibilities. For others, career goals are titles or areas of influence. However, many people don't know what they want and have no strong opinions on where they want to go.
Use your one-on-one time as a way to bounce ideas around with your boss. Try to understand what options you have, how your boss feels about those options for you, and what you need to do to get there. The more you talk about your career goals, the clearer it will become what you want to do, and the more your boss will become aware of it. Help them help you.
If you wait for your boss to tell you what's next for you, you are letting him or her drive you somewhere, and you might not like where he or she is going. Be the driver. Take your professional life in your hands, and make it clear what would make you happy and excited. Expect to be told that you are not ready. When that happens, ask what you can do to become ready for it.
Giving and receiving feedback is a great way to grow. We are all somewhat blind to many aspects of our characters and performance. We can't see ourselves clearly through the eyes of others. In fact, it is impossible to have that clarity as we are self-bias. Gaining a glimpse of that outside view is a gift, and allows us to find areas where we need to improve.
For a developer, areas of improvements might be things like:
- Code or system design quality.
- Documentation quality.
- Code review participation and quality.
- Estimation skills.
- Attitude during meetings.
- Effects you have on the team.
- The way you interact with others.
- How you handle yourself in stressful situations.
- Working habits.
- Ability to learn quickly.
- Dogmas you might have and need to be aware of.
- Assumptions you tend to make.
- Unconscious biases.
The best way to receive feedback is to ask for it. The best way to ask for it is to ask for specifics. Do not ask something generic like "what can I do better?" That puts the responsibility of coming up with something on the other person's lap.
Try to be more specific. For example, "How could I have handled that situation better?" or "How do you think I was perceived when I did XYZ?" or even more specific things such as, "Do I speak too quickly? Should I be working on slowing down?"
Asking for specific feedback increases the quality of the answers you get. It gives the person you are talking to a chance to focus on a particular aspect without making them feel like they are judging you as a person. The answers you get when you ask for specific feedback will often surprise you.