So perhaps you’re like me and you manage a software development team. You are now responsible for the care and feeding of a non-zero number of developers, each of whom have a job to do and a career that they’d like to advance in various ways. If you’re in this position, you were probably once a developer yourself.
I’ve been in this role (or some variant thereof) multiple times over the course of my career, and I learned how to be a manager the hard way – by making lots of mistakes. Looking back with the benefit of hindsight, all my mistakes stemmed from a misunderstanding of the manager’s role.
You see, I thought I was the one who had to get the work done – to be the expert, to guide the technical direction of the team, to be the idea guy. In football terms, I saw myself as the running back – give me the ball and watch me score the touchdown. I couldn’t have been more wrong.
I have people on my team who are better developers than I am, who have forgotten more about the subject matter (email) than I will ever learn. If I hadn’t learned from previous experience, I would have come onto the team acting like the expert. And I would have quickly lost the team’s trust.
My true role – the true role of any manager – is the lead blocker. The offensive lineman. The big beefy guy whose job is to clear a path for the running back. To remove obstacles for the guy toting the rock – my teammates.
Is there no place for the manager to share her technical expertise? Absolutely there is. About four months into my time on the team at Klaviyo, I wrote the technical specification for a new engagement tracking system. However, before taking on this responsibility, I consulted with our senior developers to ensure they were not interested in handling the task themselves.
I still write the occasional spec or take on a coding task that the team is too busy to take on. But my real job is looking for things blocking my team and remove them. That may mean making a call to HR on behalf of a team member. It may mean talking to another team where there’s a dependency that’s slowing my team down. It may mean challenging a engineering policy that doesn’t quite fit with your team’s needs.
It also means being in tune where each member of your team wants to go in their career and mentoring them, getting them opportunities for growth and advancement within the company. It means exercising radical candor (seriously, if you haven’t read Kim Scott’s book by that title, make it a point to do so) and giving them honest feedback to point out growth areas. It is a huge morale boost when a person knows their boss is an advocate for them and will work for her success.
It means being a cheerleader for your team and its members to the larger organization. It means making sure that your manager knows the contributions (and the names) of everyone on your team. (And if your manager isn’t doing skip-level 1:1’s with your team, encourage them to start.)
The ball is in play. Your team is poised to score. Clear a path to the end zone for them, and gain their trust.