Who should be in that group?
As my broader team has grown from 5 folks to 30 over the past few years, we’ve started running into a persistent people issue: who should be in that group?
Maybe it’s a mailing list for the whole team. Maybe the group grants access to certain resources in production. Maybe it’s a chat room for folks to coordinate team lunches.
A few options we’ve tried
All of our groups pretty much fit into one of these buckets:
Literally anyone at the company can join but we only publicize the group to folks on the team
Anyone on the team can join but people in the group only publicize it to other folks who they think would want to join
Auto-managed groups based on reporting structure (like a mailing list for everyone who reports up to my boss with no exceptions)
No clear guidance except “go talk to one of the senior folks on the team”
We’ve had problems with every single one of these situations.
Groups that are open to everyone grow over time - The chat room where we discuss ongoing production emergencies has ballooned to 150 people (many of whom cannot help with the outage at all) and chatter in that room slows down our incident response.
Public groups that are not well publicized make people feel excluded - Folks who never come into the office still wanted to know when others are going to lunch because that’s a sign that a decent chunk of the team will be offline for a bit. Technically anyone could have joined that group but not enough people knew it existed.
Auto-managed groups expose weird nuances in org charts - We had someone on our team filling in for someone on another team for six months. During that time, this person officially changed managers and was auto-removed from our team mailing list because they no longer reported to my boss. Everyone wanted this person to keep getting team-wide announcements though.
No clear guidance creates inclusion issues too - We had a handful of folks who tend to help out with emergencies a lot so they had extra production access. For production safety reasons, we wanted to keep this group as small as possible so we let the folks who really needed it join and said “go talk to this senior person if you want in”. Naturally, someone else wanted to be “in the club” but we really didn’t have clear guidance on who should be in the group or not. It didn’t help from an optics standpoint that everyone in the group happened to be white guys and the person who wanted to join was not.
Some slightly better alternatives
Fret not! We’ve found a few things that are working better:
For large, auto-managed groups, make sure there’s a way to manually add extra folks. Make the inclusion criteria something like “ask any manager on the team and they’ll probably rubber stamp it”. This seems to strike a good balance between low overhead (one less thing for every single new hire to think about) while still including folks with interesting situations.
For sensitive groups, consider adding clear responsibilities for group members. “Oh I hear you’d like to join our i-always-have-production-access group. If you’re okay being on the permanent pager-of-last-resort alias like everyone else in the group, we’d be happy to have you join.”
If a sensitive group is getting too large, try making it a rotation. We have a pair of engineers who have a dangerous amount of ambient production access at all times. After some folks asked to join that group, we decided the right approach was to have a rotating pair of engineers with access rather than a dozen with permanent access.
When making a new group that you suspect only a small slice of the team will be interested in joining, consider letting anyone join and sending a short announcement to the whole team. A few lurkers generally doesn’t hurt and can help a lot with team cohesion and trust.
All groups need clear admittance criteria. “Ask a senior person” is fine from a process perspective as long as the senior person is judging specific criteria.