slug: lead-learning title: "What I learned from a year of leading a team" tags: [Management] pubDate: 2024-01-01 draft: true #

New notes:

• Realization that even as an IC you're accumulating lead/management experience
• Eg. I learned early that coming in strong, with lots of ideas for changes etc is never a good idea. Start by building trust, relationships, aligning expectations and getting to know the product, domain, problems, people etc. first.
• Pick up the managers path: will help you understand your organization and how you can interact with management better, even if you're not looking to become a manager.
• These days getting into management might be slightly harder. Maybe you can find a manager from another team as mentor.
• Timing? 20-50% dev time doesn't allow for much technical growth, so as a tech leader you want to have a very solid base here.

It's been almost one and a half year since I wrapped up a year as team lead, and I've had this half-written post lying around since then. Some context: I'm a software engineer so this was the first time doing people management.

Context: engineer going into tech lead role.

My own story #

• Natural transition, stand-in
• Arrow was pointing at me to take over line-management
• Happy to only do it for a year
• But what if you don't have a natural transition like that?

Do your reading #

People skills play a significant part in doing management. It's a skill that's difficult to 'just pick up and learn', but it's obviously also not the only thing you need. I would consider myself to have decent people skills, for example, and in that case you could be tempted to just 'wing it' and go by intuition in your work as a manager. That might even work out fine, especially if you find yourself in an environment where things are going great, and having a personal/unique management style might even be a plus. But there's a number of challenging situations that can arise as a lead, and you really need to be well-equipped to handle those.

Personally, I fell into the role suddenly and by chance, since my lead at the time went on parental leave and me being the best candidate for filling the role for the year. This meant that I didn't have much time to do my reading before starting in the role, but I luckily picked up a few recommendations early on. Camille Fournier's book 'The managers path' is a very common recommendation for the first book to read. It's a very concise and practical book, and it's written such that you only have to read the chapters up to the position you're currently at. And even as an engineer it can be helpful, since it makes it clearer what your manager can help you with and how you can make it work well.

There's tons of books out there, but if you're just getting (and reading one) then you can't go wrong with the managers path.

Expectations #

One of the things you really need to be able to tackle is expectations. We all have expectations, and they really need to be vocalized. For example, a direct report is not performing, but think they are, because they haven't been confronted with the expectations of their role. And then the performance evaluation comes around, and disaster strikes. As a manager, you're there to make sure the people in your team thrive. Make expectations for the people you manage transparent. Don't know what they are? That's a problem. Sometimes you might, unfortunately, manage someone who's not on the right trajectory. If the expectations are visible you can course-correct, or you can realize that things aren't going to work.

Trust #

Trust is one of those fundamental qualities that make or break a working relationship. If you're lacking trust (in any direction), you're gonna have a hard time making things work.

In my case, I became a manager of my own team, which meant that establishing trust wasn't a huge challenge. We did have a new hire who unfortunately was under-performing, and

• Different ways of building it, completely fundamental to have
• Example with showing family photos
• Saying what you're going to do, and then go out and do that - example with manager saying "I will set up recurrent meetings now" and then never acting on it.

Development #

Development time? Make sure you understand what the expectations are from your company. Are you realistically going to be able to contribute technically? Personally I find it hugely important to have technical knowhow. This also means that you have to be careful about going into management too early, because it will significantly slow your technical development progress.

This is something I've learned more from having a manager than being a manager. You're gonna be limited if your technical know-how about your product isn't very large. It means you depend totally on your team to help you navigate, and make things quite hard. So having time to contribute technically is super important.

A good tip is to book time-slots for development in your calendar.

• Makes it possible to access your team and their capabilities
• Engaging confidently with stakeholders
• You can help the team, give flexibility