I’ve just come out of a JUXT team-leads catch-up where we discussed the art of 1-to-1s - mostly to share experiences and best practices from our wide variety of clients and projects, but with the aim of eventually writing up an internal “beginners’ guide” for new team-leads.
Anyway, it got me reflecting on what I do, and why. I highly doubt anything in here is particularly novel or ground-breaking, but I hope the ideas are as useful to you as they have been to me.
Like a lot of developers, I started from the rather naive position of “Alright, I’m managing people now, I have to do 1-to-1s because that’s what managers do. I’ll put some recurring meetings in”. Up until that point, I’d never seen the value of them. I still won’t pretend to be a seasoned veteran at this, but over time I’ve iterated how I view and how I run 1-to-1s, so that they’re more valuable as a feedback mechanism both for me and for the people in my team.
Starters-for-ten
A few quick ones to begin:
-
I have 1-to-1s with everyone in my team, every three weeks, for 30-45 minutes, but obviously there’s no hard-and-fast rule. This works for us - go with what works for you! On XTDB, we’re a distributed team - so my 1-to-1s are mostly over video call.
The schedule can even vary for different people in the same team. In the past I’ve had people who prefer 1-to-1s more often, and some who prefer them less; some who prefer them as scheduled meetings, and some who prefer an ad-hoc chat at the local coffee shop.
-
These meetings aren’t for me to lead - they’re for a team member to talk about the things that are important to them. They decide the topics, it’s for me to actively listen.
Specifically, if I have any other messages or feedback that I need to raise, they are strictly out-of-scope here. These are absolutely not the forum for unsolicited advice or, shall we say, “unsolicited feedback on areas-for-improvement” - it’s a sure-fire way for people to lose trust in the process if they’re dialling-in and expecting an earful.
(Exceptions being positive feedback, which is always nice to hear, or other feedback if it’s actively solicited.)
-
I really make an effort not to significantly reschedule or cancel 1-to-1s.
These are typically one of the first meetings to be postponed if time is tight. Admittedly, I’m quite fortunate in my current role to not have a huge amount of other meetings1, so it’s easy for me to say, but more so than other meetings, moving this one around may give an impression of how much you value the other person’s well-being relative to everything else you’ve got going on (especially if it happens every time).
That said, life is rarely this simple. In practice, at the start of the day I might move a 1-to-1 within the same day, for example, but I definitely try not to make a habit of moving them further than that, and not last-minute.
Some concrete practices
In terms of concrete practices: firstly, I keep a personal (unshared) journal of what we talk about. I’ll take brief notes throughout the call, but I also make a point of taking 5 minutes at the end to write up more detailed reflections.
- These notes include my team member’s own aims and learning objectives for themselves (even ones mentioned off-hand, in passing) - this means that when I later come to wider team/project planning, I find it much easier to take an individual’s personal development aims and preferences into account.
- They also include even vague hints and gut feelings - things I wouldn’t otherwise remember between catch-ups, things I might not notice in the day-to-day. This note-taking makes it easier to spot recurring themes - both for an individual, but also issues that affect more than one person in the team (even if they’re not all raising it).
Openly, I’m not naturally the most perceptive of people - no doubt there are better managers for whom this kind of thing is second nature - but this practice around notes has helped me improve.
(I used to think I could ‘just’ remember everything - this, perhaps unsurprisingly, didn’t work out in practice.)
The ‘Goldilocks’ questions
When I first started managing people, one of the things I found hardest (relative to writing software) was the appreciation of context, nuance, grey areas - something my own early managers would no doubt tell you wasn’t my strong suit! In particular, the need to adapt my managerial style to suit the situation and people at hand - to my dismay, there was never a neat, silver-bullet, one-size-fits-all solution.
This doesn’t seem at all uncommon in our industry. Indeed, it’s well understood that the skills and characteristics required to write good software are very different from those required to be a good manager!
A lot of these are skills that you continually develop over a longer term, but there are a few specific areas that I find require more frequent fine-tuning - this is where I really value regular feedback from my team:
- How challenging are you finding your work at the moment?
- How are you finding the level of support you’re receiving?
- How clear are your current objectives and requirements?
What these three have in common is that they’re all about balance. You don’t want any of them to be either too much or too little - there’s a sweet spot in the middle. Getting the right level of challenge is perhaps a trivial one - you obviously don’t want people feeling either bored or overwhelmed.
With the level of support, you obviously don’t want too little. At the other end of that spectrum, you have micro-management - not fun for anybody, and not conducive to an individual’s growth. Similarly, overly-specified requirements remove any sense of individual ownership and autonomy.
How I elicit feedback on this varies - both for different people and for the same person at different times. Most of the time these now take the form of a few explicit quick-fire questions (especially for those who are used to being asked!) - e.g. “ok Martin, level of challenge: too much, too little?“. Sometimes it might be a 1 to 5 scale (3 being “just right”), sometimes it might be more subtle, sometimes the conversation naturally covers it anyway.
In my experience, the exact answer is often less important - I wouldn’t bother graphing them over time, for example! The main aim is to get people reflecting on their current situation and state of mind.
In the absence of any other names, I’ll call these my three ‘Goldilocks’ questions. No doubt a lucrative career in management consultancy now beckons 😁
Continuing the conversation
If you’ve read this far, I’d love to hear what works for you as well - please come join us in the comments!
Good luck!
James
Footnotes
-
I’m still very much on a ‘maker’s schedule’ ↩
