I have learned a lot through peer groups, both industry wide and company internal ones. Company internal peer groups offer a unique opportunity to help you get better at your job. However, there are not yet good resources for running company internal peer groups. This post includes what I have been able to learn on the topic so far. My hope is that this post can serve as a starting point, and we can, as a community, develop those resources.
Getting Good at Things
I love learning, particularly learning how to be better at something. I love that feeling of improving mastery. Knowing that I can do something today that I could not do yesterday, or figuring out how to work around something I found challenging. Just ask my kids about when I ski the same slope over and over again, practicing some specific skill (“Dad, stop thinking so much and just ski!”).
There are many ways to learn and develop skills. The list starts with classroom instruction, as we all spend years in formal education (I have a Ph.D). From formal education, we can continue on to mentoring and coaching, as well as books for the self taught. I have enlisted mentors across my career, benefited from direct speaker coaching ahead of certain public talks, and I am a voracious reader.
There is a lot of very good research and literature on the value of those learning activities and how to do them well. I am particularly fond of “Peak” and “How to Read a Book” for example, but there are many more. I encourage you to take full advantage of the classroom, mentoring, coaching, and books – I sure have and I continue to do so.
These learning activities (classroom, mentoring, coaching, books) are based on there being someone who has invested the time to understand how to be very good at something, and then sharing that learning with you.
Those resources do not exist for everything you might want to get better at. There usually are not very many books or coaches to help you specifically get better at your job at your company.
I have benefited from an additional resource in my career – something that has supported me and helped me learn: peer groups. Peer groups are particularly helpful for those specific things, such as your job or your company. I have benefited from peer groups across and within companies.
A peer group is a collection of people with something in common, leading to some form of shared experience. The common feature could be background, skill set, age, or current job role, among many other things. The shared experience of a peer group makes the groups ripe for learning and supporting each other. For instance, peer learning in academic situations improves student outcomes. Peer groups are often used as support groups of all kinds, such as Alcoholics Anonymous, NAMI, or any kind of support group.
“The Rands Leadership Slack exists to help longtime, new, and aspiring leaders to learn through conversation and sharing of ideas.”
“LeadDev is a space where we can come together to learn from our mistakes and experiences as a collective. Through sharing the knowledge we’ve gained as technical leaders, we can both grow our own careers, develop others, and propel the tech industry forward.”
These peer groups are wonderful resources. I am thankful that I get to participate in them and learn from my peers across the industry. I have learned a lot about my current role as a staff engineer from listening to and participating in discussions in these groups. The software engineering industry has only recently embraced this role of staff engineer and these peer discussions are helping to define the role and how to succeed in it.
As good as these industry peer groups are, they cannot address all my needs. They provide me perspective across the industry, but they cannot provide me with direct insight and perspective on my company and my exact role. How could they? My peers in this group work at different companies and I cannot freely talk about all the details about my company.
Company Internal Peer Groups
While you cannot talk freely about company issues outside your company, you can within the company. A company internal peer group takes all the wonderful parts of the work focused peer group, and adds the ability to talk and learn about your specific company and your specific role within that company. These groups are often focused on a role. That role can be your job, or some aspect of your job.
In my career I have benefited from three company internal peer groups. I joined my first company internal peer group early in my first job after grad school. I was working at IBM Research and there were a number of us who started around the same time. We were all trying to make sense of our new world. In order to make that sense, we banded together and formed a group for new hires. We hosted talks, picnics, and roundtables. It was an incredibly postive experience for me. I learned a lot, met a lot of great people, and was exposed to new opportunities.
My second company internal peer group was for new engineering managers at MongoDB. Like the new hire group, there were several of us in a new job, trying to make sense of that job. We had monthly lunches and learned from each other. We were able to compare notes on things like the performance review and compensation cycle, as well as normal day to day stuff.
My third group is my current peer group, focused on staff plus engineers in engineering at MongoDB.
MongoDB Staff Plus Peer Group
|Screen shot from a MongoDB Staff Plus Engineering Peer Group meeting|
After two and a half years as a manager, I switched back to an IC role as a staff engineer. I worked hard to define my new role and do as well as I could. After a while, I realized I did not know how to be a good staff engineer, because I did not regularly work with other staff engineers in the company. I did not see their examples, good or bad.
Leaning on past experience, I reached out to some of my staff engineer peers, and formed a new peer group. It turns out that I was not alone in being confused in this new role. There was a lot of interest in getting together to talk.
The first thing we did was form a private slack channel for the group and invite appropriate people. We spent some time discussing whom to invite. After some discussion we decided to invite all the senior ICs (staff engineer or higher) who reported through our CTO. These were fairly arbitrary limits, but we hoped that this would make a nice size group with common interests.
We did not directly add everyone who matched our criteria to the slack channel. Rather, we sent an email to them explaining what we were doing and inviting them to join. Those who expressed interest were added to the slack channel. In this way, everyone in the channel made an active choice to participate in the group and no one was forced into something in which they were not interested.
Further, we made the slack channel private. The hope was that the members would be a little less self conscious when discussing issues in a private slack channel. I think this has been the case.
Since its inception, the group has flourished. In addition to lively slack discussions, we have regular meetings, and occasional group dinners. The meetings are scheduled at two different times in order to accommodate the schedules and geographies of our members.
In all cases (slack, meetings, dinners) we talk about a lot of things and share experiences. This includes sharing current pain points. Sometimes someone will share their problem thinking it was particular to them, only to find out that it is a common problem for the group. In those cases, it is comforting to know we are not alone. We also work to make the problem better for all of us. Even when a problem really is specific to one of us, it is cathartic to be able to share the problem. Often, other members are able to provide useful perspectives that help understand the problem and to start attacking the problem.
We also share interesting tidbits that come in. Interesting articles or podcasts. These often lead to good discussions and occasionally new experiments or initiatives. For example, we have discussed Will Larson’s book Staff Engineer, as well as the LeadEng’s Staff Engineering conferences, as well as various blog posts about staff engineer topics such as using career ladders (also called title matrixes) for growth discussion.
Best Practices for Running Peer Groups
While I have practical experience from three productive peer groups, there is always more to learn. As part of organizing my staff plus peer group, I looked for best practices for running peer groups within a company, so I could make my group as strong as possible. Unfortunately, I did not find a nicely curated list of best practices. Hopefully this post and this page on my website can serve as a starting point for others. While this post captures my best knowledge at the time of writing, I will continue to update the web page as I learn more.
What I did manage to do was learn from my peers about running peer groups. I reached out to peers in other companies about their peer groups. I used the industry peer groups discussed above (RLS and LeadDev). In this case, my peers were people with experience running and participating in peer groups. While I did not find the concise set of best practices I desired, my peers did share many useful resources with me, as well as their own personal experiences (good and bad).
Reviewing my peers’ experiences (good and bad) along with my own, some commonalities emerge. I hope that these commonalities can serve as a first set of best practices for running peer groups. These best practices were developed for running staff plus peer company peer groups, but I believe it is broadly applicable to any kind of company peer group. I will touch the most significant practices here, while the complete list is on my webpage.
I would broadly divide the best practices into three best practices:
Get the scope right
Members run the group (Self Organizing)
Provide value to the members
Get the Scope Right
The first decision when creating a peer group is deciding who should be included in the group. If the group is too large, it’s unwieldy. It’s hard to get a coherent discussion of common interests. If the group is too small, there’s not enough discussion or energy and the group is not self-sustaining. Successful peer groups manage to hit the happy medium to get groups large enough to have a lot of positive energy, but constrained enough to have strong unifying themes.
For reference, we originally (2021) invited 57 people to our staff plus peer group, we currently (2022) have 59 people in our slack channel, and we have 10-12 people on an average call. These numbers have worked well for us. In particular, the 10-12 people on a call is large enough to have a lot of energy, while being small enough to still be able to get a word in edgewise. The specific numbers are not important – what is important is having a coherent and energetic group.
Part of getting the scope right is getting the structure right. A good amount of discussion on industry wide peer groups focuses on behavior guidelines to keep the community from degenerating. However, in a company internal peer group, there is already an existing company culture that can do the heavy lifting here. If there is, there is no need to invent a new culture and set of procedures for the peer group (If there’s not, consider looking for a new job). Instead, you can keep the process and overhead light.
Members Run the Group
I have helped organize every peer group in which I have participated. Looking back, it seems that the more someone was involved in organizing each group, the better they have done in their careers. For example, the founder of my second peer group has been quickly promoted from team lead to director (and I expect him to continue moving up). The co-organizer of my first peer group is now a vice-president and IBM Fellow.
I don’t think this correlation is a coincidence. Part of the value of a peer group is getting to know more people, working with more people, and being exposed to more opportunities. That happens for everyone in the group, but it happens even more so for those running the groups.
This is one reason why members, instead of outsiders, should run a peer group. As I have talked to people across companies, this has been a constant observation: the successful groups are self-organized, and the unsuccessful ones are not.
There are two other reasons why members should run the group. First, smart people tend to distrust outsiders, even well intentioned outsiders. With that distrust, the peer group members are less likely to engage and make a strong community. Second, an outsider does not directly know what the peer group and its members need. The members of the group know – they are living it.
These three reasons compound upon each other in successful peer groups. The groups are started by the members, so the groups address the needs of the members. Because they are run by group members, other peer group members have trust in the group and commit their energies to make the group better. And with that positive energy poured into the group, there are more people actively engaged, meeting more people, and reaping more benefits from the group.
Provide Value to the Members
Successful peer groups provide value to the members of the group. It is their reason for being. This is in contrast to providing value to the company (although peer groups also do that). There are plenty of groups within a company that serve the needs of the company: architecture boards, interview committees, tiger teams. Some of those groups look like peer groups and their members may all be peers, but please do not confuse the two classes.
There are many ways to provide value to members of a peer group. The largest groups of value I have seen and heard are
A Place to Complain
Perspective and Advocacy.
I started this post with the idea of getting better at your job. Peer groups do this. They serve as good forums for group learning. This can be from informal discussion, peer run sessions to share learnings, and more formal sessions to bring in experts to address shared interests.
I have seen all three of these. Informal discussion has been a mainstay of all my peer groups. Questions of the form of “How do you handle X” were a staple of the new engineering manager group and my staff plus group. For example, at a recent staff plus meeting, someone asked about handling their meeting load. How did others manage and limit their meetings so that they could get their work done?
Slightly more formal are the peer run sessions. They can be as simple as a brown bag lunch with someone drawing on a white board about something they know, or can be a formal presentation. The key is that some members of the group know more about something than others. This difference can be from specialization, or just being further along some process or journey than the others.
I still vividly remember conversations from brown bag lunches from my first peer group (new hire), including a conversation describing 11 nm processor technology, and how there was nothing that was actually 11 nm long or wide in the process.
Formal external sessions involve bringing in someone from outside the group to address a shared interest. In my first group I ran a speaker series. I brought in executives and distinguished staff members to talk about their experiences. They shared stories and advice with us. For example, we hosted a talk by the head of our division (research). In addition to providing useful career advice, he was able to describe the big picture both for the research division and for IBM, and how it all fit together (us, our projects, the division, the company). In a large company like IBM, those relationships are not always obvious. That context made it easier for all of us to do work that mattered to our division and company, and ultimately to grow our careers.
A Place to Complain
A common feature of my current group, and other peer groups for staff plus engineers is complaining. At first blush it feels petty to bring up complaining as a feature of peer groups, let alone a top feature. But it is not petty at all, instead it serves an important purpose and was described to me by many people across companies. People referred to it as a form of “Group Therapy”.
There are a number of annoyances and problems in anyone’s day. Being able to talk about those problems (no matter how petty) makes them smaller and easier to deal with, and a sympathetic ear is very comforting. In a typical meeting for my current group, we will commonly discuss a variety of issues from process to infrastructure to impediments to engineering velocity.
A peer group fits a particular niche in allowing this venting. It provides a supportive group of people who are detached from the situation (it’s not about them), who have experienced similar problems, and can appreciate how annoying a particular item can be.
This group therapy may (and often does) lead into learning, perspective, or advocating for change. Those outcomes are great, but the key observation is that having a safe and supportive environment for being able to vent your frustrations is incredibly valuable in and of itself.
My current group has a private slack channel and private meetings that facilitate this group therapy. Not every successful group keeps their basic communication private, but they all have some private venue that facilitates this complaining.
One example complaint topic for my staff plus peer group is disambiguating technical leadership from people management. We have a large number of smart, talented, and motivated people who want to drive positive change at MongoDB. The confusion between technical leadership and people management leads to frustration day to day, and we can vent that frustration. Better still, we see that it is a common problem. We are working together to improve things on this topic and the company has been receptive to our efforts.
Perspective and Advocacy
Sometimes sharing complaints and problems in a peer group provides more than a sympathetic ear. Someone may know a solution for the given problem and can help make the problem go away. This is an awesome outcome, leading back into learning opportunities.
Other times, someone may not have a specific solution, but knows something that can help. Maybe they work in a different part of the company and therefore knows something new that is useful to the problem. Or maybe they know some back history on the specific issue. In either case, the person can provide perspective.
The perspective may make the problem less frustrating and more understandable (Phil wasn’t ignoring you – his kid has been in the hospital, so he has been more distracted recently). Other times the perspective will unlock a possible solution or new line of attack for the problem. (The foo team doesn’t object to adding bar, but they were bitten in the past when they were required to add a specific API for baz support and that API differed from their existing conventions.)
Finally, shared complaints may expose common pain points for the group (such as our technical leadership vs people management example). These pain points may be common to the group, and rare for anyone outside the group. It is very gratifying to learn that a problem “wasn’t just me”. In these cases, the group can then work together to address the problem and advocate for change. Change is hard and takes time, but having a group behind it makes it more feasible.
Let’s Learn From Each Other
To briefly recap: peer groups help you improve. They have helped me throughout my career, and I hope you take advantage of them as well. If you do not have an existing peer group at work, please consider starting one. Hopefully this article can help you do so. If you do have one, consider engaging more in it and take full advantage of it.
If you are in a company internal peer group, you are also my peer. I would like to learn from you and help you learn. If you have suggestions for improving the best practices or you just disagree with them, I would like to hear from you. If you have any resources that should be included on the resources page, let me know and I will add them.
Finally, if you know of any researchers who focus on peer groups, please introduce me or share their work with me. I would like to leverage their work and enable their research.
Special thanks to Eoin Brazil for providing feedback on an earlier version of this post. Eoin is a member of my staff plus peer group. He has helped make this post better and he consistently makes our peer group better. Thanks also to all the members of the MongoDB Staff Plus Peer Group, as well as the members of the Rand’s Leadership Slack and the LeadDev community who create such wonderful communities and helped contribute ideas to this post.