If you ask any engineering manager about what tools they use, 1-on-1's will most likely be near the top of the list. They help you keep on top of things, share new ideas, learn from your directs, or build a stronger relationship with your team.
By definition, 1-on-1's are *(often recurring)* meetings designed to spend some dedicated time between two people for work purposes around a shared subject or agenda, most commonly between a manager and their direct.
While engineering managers tend to mention them a lot, they are not something specific to engineering or software development, but rather they are a generic, yet very useful managerial tool. They're most commonly used to keep you connected with your directs or peers, be aware of any changes, blockers or problems, or keeping tabs on projects. This is especially useful in an environment where you and all your directs are working remotely as it also helps mitigate some of that "alone" feeling that some people tend to get when working in remote environments.
I can recount one specific case where a developer was really struggling with the disconnected nature of remote work. This was made even worse by seeing their peers thriving in this environment. Now, granted, they had no prior remote working experience, so arguably, part of the issue would also stem from hiring. But through constant check-ins, some even daily, the situation improved greatly, which kept us from losing an otherwise excellent developer.
In this article I'll expand on the way I've run these meetings in the past, what I found worked well and what didn't do so great. While it will be biased by my experiences, it does touch on concrete issues, tips on how to formalize them and ways to make them feel less like a chore.
All about communication
For a team to be successful and operate in a cohesive way, the key is always communication. And while with small teams this might come easy naturally, as soon as your team starts to scale, communication is something that you must actively work for, as to ensure that all parties are on the same page. You might even say that communication is your primary function as an engineering manager. Be it communicating down, up or sideways, you must ensure everybody knows what's going on.
1-on-1's are just that, a tool for you to use in ensuring you properly communicate with both your directs as well as management. Since you'll be spending a proportionately larger amount of time communicating with your directs this article will mostly apply to that scenario.
While the 1-on-1's themselves are a great tool, and I can't recommend their usage enough, you should also be mindful on how you schedule them, or how you run them, as there's ways they could turn into a drain, both from a mental as well as from productivity perspective.
Best advice I can offer you is: "don't make them boring". Ensure there's relevant issues to talk about, and ensure you don't schedule them too often. If you do, you'll run the risk of them being perceived as a chore, with your direct either dreading in that call or just tuning out. For me, the cadence usually came about naturally, but if it doesn't, check your agenda, and decide if it's actually worth to have one; otherwise just cancel. As a rule of thumb, once every two weeks seems to be a sweet spot, but this heavily depends on your team size, deadlines, and individual personalities.
Whilst most engineering manager articles or learning resources won't directly mention this, I want to touch on as it's something that I felt personally benefited me as a manager, as well as the team's cohesion and bond overall. While all my 1-on-1's had an agenda, I always tried to make them personal as well. Share hobbies, activities, ask about theirs too. I found that doing so not only formed a closer relationship, but it also made the meetings something to look forward to, as they felt a welcome change from the routine of day to day.
Formalizing
Personally, I've run 1-on-1's on both ad-hoc as well as pre-defined schedules, with various degrees of success, but in order to truly make them beneficial to the team, you have to formalize them as part of the culture. This way, both you and your direct know that one is coming up and can prepare for it accordingly. There's nothing worse than showing up for a 1-on-1 unprepared and just winging it. That wastes both your and your direct's time, and ultimately impacting team productivity.
One of the staples of formalized 1-on-1's is having an agenda. While they can work without one, as either your or your direct will know what the task at hand is, it loses a lot of efficiency as well as making both parties unable to properly prepare for it.
Personally, I've been partial to having a "living", shared agenda _(think Spreadsheet, or a Notion doc)_ that constantly gets updated with items, both by you and your direct. This way, you both raise issues up for discussion, you both prepare for them, ensuring that the time spent together is being put to good use.
I've touched above about cadence, but there's one more facet to scheduling that must be considered, in order to avoid making meetings stale, repetitive, or, as I said above, "boring". With people that you interact frequently _(eg: you're working together on the same project)_ scheduling a 1-on-1 might not be worth the time, as you are already communicating and sharing ideas on a daily basis. For cases like this, while I would be mindful of the agenda, and act on anything relevant, I'd often skip those meetings, or just hold them less frequently.
One last thing I'd like to add about scheduling, something that stems from my own personal experience, when using 1-on-1's to either share information or to coordinate, either up or laterally _(with other managers)_, I would usually forgo schedules and just have them on a case-by-case basis, once the agenda gets big enough or there are pressing matters to resolve. This approach worked well in my experience, however since no two teams are alike, it needs to be adapted to your own specific situation.
In this article I barely scratched the surface on the topic of 1-on-1's, and it should be read in the context of a short guide, rather than an exhaustive list.
There's so much more to say on the subject: relevant topics, tone, pre-empting conflicts, choosing what information to share, etc, and while I'm tempted to expand on everything, I fear that it would bloat this article way too much, making it lose the original purpose for which I've written it.
I don't believe there's a manager out there that doesn't know about, or already using 1-on-1's, since it's such an easy and convenient tool; for most, it even comes about naturally.
Hopefully what I've written above gives you some ideas on how to run yours, and through the lens of my personal experiences, gain a sense of how they can be used in practice.