How I would like to be managed - Part I

An alternative title for this post is : "What you should expect from a good engineering manager?"

I started reading The Manager's Path and the second paragraph in the first chapter poses this question. I think it was a rhetorical question and not one the author asked to provoke thought/discussion. But here we are. I abruptly put the book down (well, the tablet) and started writing.

Leadership and/or mentorship are always on the back of my mind, mainly because I want to lead one day and I would like to be good at it. I also want to constantly grow and I would like to be mentored. One day, maybe I'll be good enough that I will be able to mentor others.

Aside : There is a separate discussion to be had about whether your technical manager should also be your technical mentor but let's leave that aside for now.

Given that, here is how I would like to be managed (as a software developer):

• Give me context about the team and/or the company,
• Give me an introduction to the project that I will be working on,
• Get to know me better, as a person and as a developer,
• Help me understand why I am on this project.

Let's look at each of those in detail.

• Give me context about the team and/or the company,

I want to know where I will be working and who I will be working with.

Please don't just tell me to join the teams' slack channel and introduce myself to the rest of the team.

If I am new to the company and yours is the first team I join, please give me context on how the company works in general. This can involve talking about what your day-to-day looks like and/or what my teammates' day-to-day looks like.

Tell me who is who in the team and how the team works. If I briefly know who is who on the team and what they are competent at, I can go off on my own to talk to them if/when the times comes when I need their help.

This is still relevant for people who aren't new at the company. The company might not be small enough that everyone knows everyone else so it is still useful to get a brief introduction to the rest of the team.

• Give me an introduction to the project that I will be working on,

I want to understand what I will be working on and why I will be working on it.

Plase don't just ask me to read the project README or a bunch of other Google documents. Please don't just assign a bunch of "Good first issue"s to me and ask me to start opening Pull Requests.

Tell me why the project matters. Who is the customer for this project? How long has this project been going on for and what is the history of the project? Give me an idea of the big picture. Once you give me a brief introduction, I will be able to make better sense of any documentation you point me to, whether it is technical documentation or not.

This is relevant to employees who are moving between teams but it is especially important to new employees because it sets the expectations for the rest of their career at your company.

• Get to know me better, as a person and as a developer,

I need you to know who I am, how I work and what I am good at. More importantly, I need you to know what I am bad at and things that prevent me from getting work done.

Please don't have expectations of me, technical or otherwise, when you don't know me.

If I am someone who can't work without a big picture, you need to know that. If I am not someone technically capable of breaking down a big task into smaller chunks, you need to know that.

Most importantly, I need you to know whether or not I am capable of taking constructive criticism and how I expect such criticism. Am I okay with you being curt with me or do I need you to go into the details of what I need to improve upon, why and how? Am I comfortable receiving this criticism while other team members are around or do I need you to talk to me in person?

This is equally important for new and existing employees who are moving between teams. I might be used to a certain way of working and leadership in my previous team or at my previous employer. So, get to know me so you can set your expectations appropriately.

• Help me understand you and know you better,

I need to know who you are, why you are leading this project, how long you have been with the company and/or the team. I need to know who you are as a person and how you lead your team as a manager.

Please don't expect me to ask around about you or magically understand your leadership style.

Unless I know who you are and how you work, I won't know how to reach out to you when I am having trouble working or trouble completing a task.

• Help me understand why I am on this project,

This is relevant to both new employees or employees who are moving between projects.

Am I on this project because I possess skills that no one else on the team has or maybe no one else is as experienced as I am? Am I on this project because you need more people? Does the project need more people because you're close to a deadline or is it because the scope has broadened and a new phase of work is beginning?

This is useful to know for new employees but this is especially important for existing employees who are being moved in between teams. Depending on the company you work for and the way the company leadership manages people, I might have been pulled abruptly from a project to be put on yours and I would love to know why I never got the chance to wrap things up in the previous project or why this new project wants/needs me.

I'm sure there are more but nothing else comes to mind at the moment. As you can see, these are all on the people and culture side of things. This blogpost is already long so I thought I'd stop here and create a new blogpost to talk about the technical side of things.