Supervising others

I dictated this article using OpenAI, and it rewrote it into something very jingo-y, so instead I just left it exactly as the transcription!

This is a blog post on some ideas about managing and supervising people. In the past few months, I’ve begun to supervise and coordinate the work of others more and more, and this has led me to realise a couple of things. And I’ve also received some feedback on managing people, which has also been quite helpful. In this short blog post, I thought I would share some of those ideas.

Communicate clearly and correctly

The first thing I want to share is that it’s very important to communicate clearly. When I was working as an individual contributor, if I communicated something in stand-up or in my own documentation, I tried to explain things clearly, but if I made a small mistake or referred to something incorrectly, it wasn’t such an issue.

But now that I’ve been supervising and managing other people, if I describe the task wrong or refer to the wrong buckets, S3 buckets, then this actually could really impact the work that somebody else does. And so I think it’s actually more important than I realised to communicate clearly and to check that what I’ve said is actually what I want and that it is comprehensible to other people.

Determine support level needed before assigning work

The second thing that I want to raise is about determining what level of support somebody else needs. In my own work, I have previously worked on a project and split things up into individual tickets. Then when I wanted to work on a ticket, I would simply, I would write a description, I would open it up and start working independently.

Other people who are new to the project and who are also developing their skills in this area more generally will be less familiar with the intricacies of your project set up and the context. And they may also be less familiar with some of the tools and Python classes and inheritance and stuff like that than you are.

So if you’re supervising somebody else, I found it useful to first assess what level of support they need. It might be that they are quite happy working on large chunks of work unsupervised, or it might be that they need quite specific guidance. But the idea here is that we don’t know what the level will be. And so in order to sort of fit the task to the person, we need to assess what level of sort of support or structure they need before assigning them a task and then make sure the task fits to that level.

Be curious when giving feedback

The third thing that I want to say is when giving feedback or especially, yeah, when giving feedback is that often other people do things in a different way to what I would have expected. And so in a few situations, I’ve given feedback where I’ve said, this is wrong. You haven’t done something the way that I would have done it. And then, you know, upon further discussion with somebody, I’ve realised that they actually had a totally valid approach. It was just that I’d only envisaged my way of doing things, or perhaps I had just misunderstood them entirely.

So when giving feedback, rather than saying, you haven’t done this in the way that I expected, this is wrong. I think it’s better to ask questions to understand, you know, it seems that you haven’t taken this particular approach. Like, why is that? And I think this is probably a better approach because it will help somebody. It will help you understand their work better and whether it does address the task. And also by asking further questions, hopefully it will sort of stimulate some ideas for that person and help them kind of understand their task and reflect on it more broadly.

It’s probably also worth saying: be nice! When I remember getting constructive feedback and was less confident at work, it really stung! So be compassionate and encouraging while being constructive.

End

So those are some short ideas. I haven’t been managing people for that long. And this is mostly in the context of allocating tickets and supervising work. So just a few short thoughts. I hope it will be useful for somebody else.




Enjoy Reading This Article?

Here are some more articles you might like to read next:

  • Crash course in asyncio
  • The importance of infosec
  • Building micrograd
  • LLM post-training
  • Self development plans