Why and how we do one-to-one meetings

One-to-one meetings are a standard at more or less any software development team. Some of them have strict formats and agenda’s, while others are open-ended. Some teams do them weekly, fortnightly, or even monthly. Some teams don’t do them at all.

At Happy Bear Software, they are often the only opportunity we have to speak one-on-one outside of the context of a specific client project. They serve a number of purposes for us.

Firstly as a remote team working on disparate projects for multiple clients, we don’t often get a chance to talk. It’s probably good to be reminded that you work for us and not for the client, so our one-to-one meetings give us a rare chance to speak to each other when client work is humming along as expected.

Our one-to-one meetings are a chance for developers to raise any issues, concerns, or problems they might be having. This could be to do with the client project they’re working on, or perhaps their situation at home. Sometimes it’s enough just to talk about these issues, but where possible it’s a chance for me to take concrete steps to address any problems that might have cropped up.

Sometimes a one-to-one meeting is just there to catch up and build rapport. While this may not seem like the most business-minded way to spend your time, people will respond more favourably towards you if you have a rapport with them. This rapport also comes in handy when you have bad news or negative feedback to deliver. If your track record is 99 meetings where everything was fine then meeting 100 where you have to raise concerns about performance isn’t as difficult as it might have been. That feedback or that bad news is only one part of a longer relationship.

At times in the company we’ll want to try out new initiatives that might be controversial, or at least require buy-in from the entire development team. Rather than making a big announcement, proposing a plan and charging forward, one-to-one meetings are an opportunity to quietly build consensus. If you raise an idea and ask for concerns directly in your one-to-one meetings, then you’re much better prepared to affect real change in your team. After talking to your entire team individually and registering any issues they raise, your plan is far more likely to be well-received.

I have been a developer for the vast majority of my career. I’m only just getting into management, and am learning a ton of other things about finance, sales, marketing, and anything else I need to run a company. Sometimes it can be useful to get feedback on my performance and my behaviour from the development team. One-to-one meetings are a great place to ask for this kind of feedback and discuss the implications.

On the other hand, if there’s some feedback I need to give to a developer about their performance at work, then one-to-one meetings can act as a good place to do this. At the same time my preference is to set out the details of any negative feedback in text first (usually via an email) and have a discussion after we’ve both had time to digest and ruminate about it first.

We hire good developers, and while we accept that the average tenure for developers in this industry is around three years, we want to do everything we can to keep them around for longer than that. For this, the absolute minimum work we need to do is to do whatever I can to help the developers on our team meet their career goals. Some want to contribute to open source, others want to be famous conference speakers, yet others want to gain deep expertise in a specialty topic. One-to-one meetings are the exact right place to discuss these career goals, make plans, set targets, and stay accountable to them.

We carry out one-to-one meetings like we do all of our meetings, using remote video call, usually with appear.in. The only real preparation I do for the one-to-one meeting is to write a few bullet points about things it might be worth discussing. While we’re not averse to the idea, there’s no formal agenda for exactly what points a one-to-one meeting has to cover just yet.

We prefer to have one-to-one meetings once every two weeks. Once per week is a little too often and once per month is not quite often enough, especially to surface issues on client projects which usually need to be dealt with more quickly. This might become unmanageable on a larger team, but for now this interval suits us.

While our one-to-one meetings are free-form, I try to ask a number of questions at every meeting. Whether I actually ask them is usually down to whether I remember to in the moment, I’m not marking these off a checklist for example:

• How are you?
• How do you feel about your client work?
• Is there anything the company could be doing better?
• How do you feel about your productivity?
• Are you having any issues with other people in the company?
• How are things outside of work?
• Is there anything else you’d like to discuss?

The final question “is there anything you would like to discuss?” is one I like to ask at the beginning, the middle, and at the end of the meeting. Whenever I ask it I try to pause long enough to make it feel awkward. I really want whoever I’m speaking with to raise even the smallest of issues, so I press them on this multiple times.

We can’t claim to have the best one-to-ones and I don’t think one-to-one meetings will magically fix a dysfunctional development team. However they act as the medium your relationship with your development team is played in. If you have an open, collaborative relationship with your developers and aim to act in each others mutual interests, then one-to-one meetings can act as a place for those things to happen.