Setting Managerial Priorities

Throughout IT is the notion that when you are promoted to being a manager, you should somehow be able to do the things you have been doing. If you are a coder, you should be able to code and manage. If you are a writer, writer, sysadmin… the same theory holds.

The manage-from-within notion is something a lot of community managers have to contend with every day. It is an especially fuzzy boundary because, typically, community managers aren't really managing people at all, but rather guiding resources and providing support. So why shouldn't they get to also work to their strengths?

Because nothing could be further from the truth.

Earlier this week, I read a tweet from Erica Joy, Senior Engineering Manager at Patreon, that was very much on point for identifying what a manager should be prioritizing.

Joy's tweet was specifically about engineering, and subsequent tweets in this thread emphasize that she is also talking about managing humans, not the kind of management we find ourselves doing when working with open source communities.

Her point is well made: before you can settle into doing hands-on work as a manager, you need to make sure all of your managerial duties are checked off first. The one I especially liked was the point about paying off cultural debt. "Cultural debt" has many connotations, and frankly I was glad someone else in the discussion asked her what she meant. Joy defined cultural debt in this instance as:

All the stuff you put in the "I'll fix it later" column. Figuring out how teams work together, establishing communication practices, defining processes, etc.

— EricaJoy (@EricaJoy) April 30, 2018

What Joy defines as cultural debt also overlaps quite a bit with the processes of open source community management. This is why I believe her message can apply to open source community leadership as well: integrating teams, building workflows… that is pretty much what a community manager does, too.

In an informal setting like an open source community, it's going to be hard not to roll up your sleeves and get hands-on with a given project. That's to be expected. But as far as time allows, open source leaders need to apply time to much of the points Joy highlights (perhaps swapping "You have worked on community growth" for "You have nobody else to hire.").

Pay particular attention to the last point: too many times we put the needs of the project before our own, and that is a sure-fire recipe for burnout, which helps no one at all. You are a part of the community, too.

Image by pixabay, under CC0 Public Domain license.