I used to tell people that I was happy to help lead an effort, I just didn’t want to be in charge. Sometimes that would confuse people and it would take a while to explain. A long time ago a friend drew me a picture like this:
And I’ve used something like it often over the years to explain what I mean. I’ve also seen some very Dilbert style versions where the boss has a whip instead, and they’re meant to imply that bosses are less useful than leaders. That’s not at all the direction I’m going for. I just want to call out the difference because they’re both useful roles. Many times it’s the same person filling both of those jobs. But it doesn’t have to be. Understanding the difference, and how to both encourage and express leadership without needing to be the boss is a great skill to try to build.
So if you want to keep building instead of moving over to manage people what can you do to make sure you’re continuing to scale up how you impact your organization? I’m going to tilt this very much in the technical team direction cause that’s just what I know the best. But a lot of it applies pretty broadly for any individual contributor role.
Two of the most major areas that make management the default are planning and team development. It’s hard enough to come up with the plan for a technical project at all. But then trying to guide the team through the practical aspects of shifting goals and requirements, people leaving and joining the effort, and figuring out some realistic milestones along the way that actually reasonably reflect progress - that’s hard enough to do if you do understand all the parts of the system in detail. If the person who has to manage that isn’t able to just roll up their sleeves and dig in when something doesn’t seem to be working, the whole process gets hung up very easily. So the default becomes having someone who’s familiar with all the technologies also run the project.
That’s not the only way to solve for that problem though. If the person running the project can get enough of the right bits of info it’s not necessary to keep digging in to get answers and unblock things. Good bosses have their processes and techniques they use to make sure that happens. But there’s still plenty we can do to make sure that works.
Most important is to try to understand the right level of detail when sharing updates. I’ll often see junior folks pour tons and tons of info into their status updates thinking that will help with the planning. It might at certain times and for certain projects. But mostly that’s just noise if all we really need to know is that things are on track. Learning how and when to call out things that might be a problem is a great skill to try to hone. And a lot of the ideas overlap with the horsepower and torque points. When your call outs on issues are really representative of points that need special attention and not just things you might disagree with, you’re doing a great service to the team as a whole. And it takes just a few instances of that to be able to strengthen trust with everyone.
The other assumption that pushes teams to want to move senior people to management is that being someone’s manager is the best way to share knowledge. This one has always been particularly frustrating for me. I almost always see the opposite. People who were fantastic team members that I got a lot from collaborating with have all their time taken up with the new parts of their job. And when I talk to the people they’re directly managing, expecting them to be loving working for someone I know is technically very strong, that’s often not the case.
Of course there are tons of ways to help out your team by spreading some knowledge around outside of the default channels. But just like in the project management context, it’s all about making sure it’s the right info at the right time. It’s not super useful to your team if you just read the gang of four Design Patterns book and you want to take every single possible opportunity to lecture everyone about the top three or four patterns that would probably apply to what they’re working on. It would be super useful to them to hand over an article that you saw about how to configure netem if they’re working on tracking down a bug that seems to only happen over spotty networks.
It’s fantastic if you want to find some ways to share things you love working with and have deep knowledge of. Find the right opportunities to do so, and that can be a great level up for your team. But if you can manage to put aside what you really love and instead figure out the things your team currently desperately needs, that can be immediate significant benefit.