Monday, October 31, 2022

Special Places

Oil painting of a cafe scene by Edouard Manet. Man at table with top hat in the foreground. Waitress drinking behind him. Another woman in the distance in the background.Source: from Google Art Project and on display in Walters Art Museum.
At the Café by Edouard Manet from the Google Arts & Culture via Wikipedia

Los Alamos, SRI’s Augmentation Research Center (ARC), Café Guerbois at the beginning of Impressionism. For the right person, each was a special place. What must it have been like to be at Los Alamos with Fermi, Feynman, and others for the Manhattan Project? Or to be at the Augmentation Research Center for the development of the future of personal computing including the mouse, the graphical user interface, and video conferencing (culminating in the Mother of All Demos)? Or to be in the Café Guerbois with Manet, Degas, Monet, Renoir, and others for the birth of Impressionism? Just imagine the ideas and excitement that must have been in the air in each place.

You cannot go to any of those places today. Sure, there’s still a research lab at Los Alamos and the ideas of ARC are everywhere. But those exciting, special times are in the past. Special places don’t just exist in a place, they also exist in a time. It is easy to mourn that these special places no longer exist. I think this is misguided. Instead, we should celebrate that they ever existed!

What Is A Special Place

It is easy to come up with examples of special places, but harder to define what they are in a useful way. It’s tempting to use the porn rule (you know it when you see it). I think we can do better than that and can determine some common features of special places, even if we do not come up with a precise definition.

First and foremost, a special place brings great people together. Without great people, none of my examples would have amounted to anything interesting. Wonderful things can happen when you collect exceptional people in one place.

But a collection of exceptional people is not sufficient to create a special place. For example, academic conferences often bring together exceptional people, but they usually don’t bring them together for long enough to do something extraordinary. Special places bring great people together for an extended period of time so that they can do something extraordinary.

I posit that to bring extraordinary people together for an extended period of time and to do something incredible, you need a common purpose. Los Alamos and the Manhattan project are a poster child for shared purpose, but so are the Impressionist meetings in Café Guerbois or the ARC.

Not only is purpose needed, but the group and purpose have to exist at the right time. For example, the Manhattan project could not have succeeded without our increased understanding of atomic physics from the previous decade. You cannot split an atom if you don’t understand that an atom has a dense nucleus consisting of protons and neutrons.

A Funeral Should Be A Celebration

None of my examples of special places still exist in the same way they did. Yes, there’s still a lab in Los Alamos, but the lab today is not the same as the special place I described above. The ARC and the Café Guerbois no longer exist except in history.

We have a way of remembering someone who has passed; it’s called a funeral. Funerals are often sad, somber affairs, but they don’t have to be. Part of my heritage is Irish, so I’ve been to multiple Irish wakes and funerals. While there is sadness for our loss, the room is usually filled with laughter as people tell stories about the deceased. Yes, we mourn, but we also celebrate the life lived and we celebrate that we were able to be a part of that life.

We should treat the passing of special places the same way: We should celebrate that the special place ever existed, the advances it produced, and that we were able to be a part of it in some way. Special places are rare. So many things need to go right for a special place to exist. It is a wonderful thing whenever a special place comes into being.

My Two Experiences With Special Places

I have been blessed to be a part of two special places: IBM Research and MongoDB.

I joined IBM Research after completing my PhD. I worked with some amazing people who had done incredible things. Some highlights from my time at IBM Research include meeting and talking to Fran Allen (Turing Award winner and inventor of the optimizing compiler), Bob Dennard (inventor of DRAM, Dennard Scaling Law), and Dick Garwin (designed the first hydrogen bomb, and generally went around IBM being brilliant). Fran, Bob, and Dick were all still working at IBM when I joined and they had done their greatest work within IBM Research (h-bomb excluded).

Here’s the thing – all that work was done in an earlier era of IBM Research. There was still cool work being done when I was there (e.g., Blue Gene supercomputer), and the key people were still around, but IBM Research was already a different place than that special place that created those incredible innovations.

By the time I joined, IBM Research was an echo of its previous glory. Still, I was blessed to experience that echo and work with those brilliant people. However, others had a different experience. Some of my colleagues had worked at IBM Research during its heyday and ever since. They knew they had lost something special. Some of them were bitter or frustrated over the loss. They started their careers in a truly special place, but they were ending their career in a lesser (but still interesting) place.

Those colleagues were focused on their loss. They should have focused on celebrating that they were part of something special in the history of humanity.

Now, I work at MongoDB. When I joined, the company had less than 400 employees, was privately held, and had grand ambitions. We had the beginnings of a revolutionary database, but not all the features or stability needed for a database. The CTO and co-founder was brilliant and he knew he needed a lot of good people to build out this new database.

There was so much possibility, so many problems ripe to be solved, and so many great people in a supportive environment. It was a wonderful and terrifying place to join. For my part, I helped build (from scratch), a world class performance testing infrastructure (for example, see this, this, and this) from essentially nothing. Others built out the missing features or built fundamentally new things (e.g., transactions, Database as a Service, Queryable Encryption,…). We regularly had time set aside to work on side projects, we had internal hackathons, and we had yearly off-sites for all of engineering at waterparks. I got to know and work with many brilliant and kind people.

I still work at MongoDB and I think MongoDB is still a special place, but it’s already a different special place than the one I just described and I originally joined. How could it not be? Over 8 years MongoDB has grown by more than 10x, became a public company, and filled in all the basic features required of a database. Many people use MongoDB for large scale production workloads that are critical to their businesses.

Put another way, MongoDB is a real product and database; it’s no longer just the potential for something real. And it’s not just a database either. It has added a suite of related products including a database as a service offering, and is now expanding into being a platform for developers.

The company is larger and the software is more mature, but there are still many interesting challenges to face, and many brilliant people to work with. If anything, there are a lot more brilliant people now because we have the space, capacity, and resources to address the next level of questions. We continue many of our special traditions, such as our internal hackathons, and adjust others that we’ve grown too large for (e.g., we have too many people for the waterparks). As MongoDB continues to grow, I hope it continues evolving as a special place for as long as it can.

Special Places Contain The Seeds Of Their Own End

However, MongoDB will not remain a special place forever, just as Los Alamos, ARC, and the Café Guerbois are no longer the special places they once were. Special places are dynamic things, in which extraordinary people are brought together at the right time and with the right purpose. They exist for a reason. There’s some potential or problem in the air that is ripe for addressing. If the special place is successful, it grabs that potential or solves that problem. However, with the problem solved, the motivating reason goes away. It may be replaced with another, but then it’s a different place.

If the special place is a company or government organization, the place will grow with its success. A 20 person place is fundamentally different than a 200 person place which is fundamentally different than a 2000 person place. The dynamics are completely different. So, even if a special place holds on to its reason for being, its success will completely transform the interactions and structure of the special place.

Eventually, every successful special place will come to its end, through some combination of solving its defining problem and growing into something unrecognizable from where it started.

A special place can try to delay the date of its end through reinvention. It can continue to bring in more great people, update its purppose and goals to align to current opportunities, and adjust how all those people work together. It may successfully delay its end for an extended period of time, but eventually it will meet its end.

Celebrate The Special Places

While the end of a special place is inevitable, its end should not be sad. We should celebrate that each and every special place had a chance to exist in the first place and graced us all with something wonderful. If you are lucky enough to be a part of a special place, even for a short period, you should be extra grateful for that experience.

I know that I am. I am grateful for my experience in the echo of IBM Research’s heyday. I was exposed to wonderful people and ideas because of it. I am grateful that I was able to join MongoDB as it moved from an idea with potential into something real, and I am grateful that I now get to continue working on the challenges of a scaling company with a product that is used widely. As my friend Eoin put it “MongoDB is the best place I’ve worked”. I hope that I continue to get to work at special places – I will search for them. And I will celebrate each and every one of them.

Special thanks to my friend and colleague Eoin Brazil for reviewing this post and for our discussions on the subject. The examples in this piece were particularly improved from his feedback. 


Tuesday, September 6, 2022

Defining Your Own Job

I have spent the past 2 years, since I stopped being a manager, trying to define my job. No, that’s a lie, I’ve been trying to define my own job for much longer than 2 years. I’ve been trying to do it for many years. Specifying both what is and what is not my job. I suspect many (but not all) of my peers are doing something similar. If you are happy with your personal status quo, with your existing structures and roles, with doing what you are told, you can skip this post (maybe read this one on community instead). However, if you are still interested, join me on a journey of self-definition.

Career Progression

For many jobs, particularly in the tech world, there’s a progression in responsibility and scope. You might be hired out of college for a specific role. You join a team with an area of responsibility and a backlog or roadmap of work. Your manager gives you easy tasks so you can learn the ropes, and slowly you take on increasing responsibility. However, there’s still a list of things that need to be done, and you help go through it. There are clear expectations. There may even be a career map laid out for you, documenting exactly what is expected as you grow.

For example, this is what we do at MongoDB Engineering. We onboard people. We grow them, and we give them a blueprint for what to do. I’ve had the pleasure of seeing many young people join us as interns, return as full time employees, and thrive in this system. Many of them are now senior engineers, leads, directors, and staff engineers. The system works.

However, even as nicely scripted as that process is, there comes a point when no one tells you how to do something. It may be an open problem that needs a design. It may be pushing on a neglected pain point. It may be picking up an opportunity to write a blog post. Suddenly there is flexibility in what you should do and how you should do it. It might only be a little bit at the start, but it grows. To me, this is when things get interesting.

At work, someone needs to decide what problems need to be solved and what work needs to be done. More specifically, someone needs to decide what you should work on. Ideally, that person should be the person with the most insight into the company's problems and your strengths. If you are doing things right, you are the person with the best insight into your strengths. With some effort, you can also have the best insight into some area of your company's work.

When you do that, you are defining your own job. No one else is. The sense of self-determination is very motivating and satisfying to someone like me. More importantly, I would argue that when you start defining your own job, you become more valuable to your company.

More Valuable Employees

Who are the most valuable people at your work?

Sometimes you may ask a question at work and be told, you need to talk to Alice. Or you may hear a VP say, we need another Will. Your company works because of people like Alice and Will. They have defined their own valuable roles. They may have an impressive title (or not), but they are talked about like that because they are one of a kind. The company had no idea it desperately needed those roles until someone started to do them.

What makes Alice and Will valuable, is that they are:
  1. Addressing a need the company didn’t know it had
  2. Very good at their role
  3. Very motivated in their work
Known problems are relatively easy to address, but unknown ones are not. You first need to identify them, then decide on how to address them, and then address them. Each of those steps can be slow and ponderous. One motivated person can iterate through all three steps much faster than a group of people. That person can then show the organization work in progress that both demonstrates the problem and the solution, quickly reducing overhead in time and people in order to fix a problem.

The second two points tie together. By identifying and working on a problem before others, they have a head start and will be better at it. Because they are working on what they want to, they tend to be motivated and make even better progress. It’s a very rewarding cycle.

An Example: A Very Valuable Employee

I have a friend and colleague who worked in a support organization. He pulled support cases from a queue, addressed them, and moved on to the next ticket. He was good at it and got the harder tickets. Soon he identified several things that could make his life easier on those support cases. He built scripts to collect the information, and other tools to visualize the results.

Suddenly he had become the person to go to for hard problems. He liked the hard problems. Further, this bought him more space to think about the hard problems and how to solve them. He built more tools and planned ahead. Eventually those tools were productionized and taught to others. He remained the best at the tools, because he was always pushing their limits and pushing them forward. He also had time to think about what the next limits might be.

What does my friend work on today? Whatever he wants to. Everyone knows he’s incredibly valuable. Everyone brings him the most interesting problems to work on. He’s engaged and productive, and everyone knows he’s valuable.

A Roadmap To Defining Your Job

Assuming I have sold you on defining your own job, you would like to know how to do this yourself. The first step is to be good at your job. This may take years. Do what you are asked to do, learn, and execute. This is critical for building trust and flexibility. Do not skip this first step.

Assuming you are good at your job and have that trust, the next step is to know some things about your company and yourself.
  • What does the company need?
  • What are you good at?
  • What do you like working on?
It takes some work to know what you are good at and what you like to do. The answers aren’t always obvious and require some reflection. What you like working on is specific to you and includes the things that give you energy and satisfaction. The important part is to give yourself time to take a step back and review. Journaling can be a big help in conjunction with reflection. That reflection will also likely reveal things the company needs. When you have all three, try to find the commonality: what you are good at and enjoy and that the company also strongly needs. That’s the sweet spot you want to target.

Hand drawn Venn diagram showing the overlap between what you like doing, are good at, and is valuable to the company. There's a star marking the center overlap of all three. The region that is only "like doing" is labelled "hobbies". The part that is just "valuable" is labelled "rest of company". The overlap between good at and valuable is labelled "Burnout, resentment". The overlap between valuable and like doing is labelled "Frustration, bad Reviews". The overlap between like doing and good at is labelled "happy irrelevance".

It is not enough to know what that common item is that uses your strengths, that will help the company, and that you will enjoy. You also need to convince the company (and your management) that those things are the best use of your time. That work might not be easy, but there are things you can do to give yourself your best chance. Three important items are:
  • Know what you want and let others know
  • Report to the right level and part of the company
  • Find opportunities to do what you want

Know what you want

You hopefully have identified that common area of things the company needs, that you are good at, and that makes you happy. That is not enough – it’s not specific enough. You need to turn it into a job that you can sell to others. Or a change in your current job. Either way, it has to be something concrete enough to be actionable. It might even be more than one thing, giving you options and more ways to succeed.

If you have something concrete in mind, you can act on it. As new opportunities come in, you can easily grade those opportunities against your list. If a new opportunity matches your ideal, congratulations! If the opportunity doesn’t fit with your ideal, you know it’s not what you want. It might be a chance to negotiate for what you do want to do, or maybe it’s just “no, thanks for thinking of me.”

More importantly, once you have concrete ideas, you can talk to other people about them. Tell your colleagues about what you would like to do. Tell your management chain. Talk far and wide about the things that get you excited and that you want to do. Tell people why you want to do it and why you think you would be good at it.

Most people you will talk to cannot directly help you. They don’t have that job to offer you. That is fine, because (most likely) you do not know who will be the key person. You are planting seeds of possibilities. The more seeds you plant, the more chances you have of success.

For example, some new company issue or problem may come up months from now that would provide a perfect opportunity for you. There’s no way to know about those today since they don’t exist yet. Maybe one of the people you talked to is in the room to discuss that issue. If they remember your conversation they might say “Hey, this sounds like a problem where we need X. I know that Naomi is interested in working on things like that and would likely do a great job”. Maybe you talked to more than one person who’s in that discussion, and maybe they second the idea.

On the flip side, if you do know someone who could give you your job today, go talk to them! Learn about their problems and needs, and let them know what you would like.

Even if it’s easy to get management to agree to let you do your desired job, you still should talk to a lot of people about it. That way, people already know to come to you on relevant issues when you get the job. Management gives you the license to use your time on the job. Having people know to come to you and trust you on that job helps you do the job and to do the job well.

Report to the right level and part of the company

The job you define for yourself should align with your manager’s goals. If your ideal job has broad reach, touching multiple projects, you should not be reporting to a line manager with a very focused responsibility – that will just lead to frustration for both of you. Similarly, if your interests are solidly in one department, you shouldn’t report to your CTO. The CTO can’t provide useful support without stepping strongly on other people’s toes. Similarly, you cannot support your CTO and their problems if you only touch that one small focused area.

The key is finding a manager at the right level. Someone whose purview is largely aligned with your interests. Someone who can help you succeed, and whom you can help to succeed. There’s no strong formula here, just questions to ask yourself. “Am I at the right level?”, “What is the right level for my interests and ideal job?”, “Am I reporting to the right person?”, “Who would be able to support me well?”.

Find opportunities to do what you want

In the best case scenario, you tell people what you want, and you get it. Most of the time we don’t live in that best case scenario, or at the very least it takes time to get there. There are still things you can do while waiting for that perfect opportunity, and those things make that opportunity more likely to eventually show up.

Specifically, find those parts of that ideal job that you can do today. You likely have some leeway in your current job, whether it’s deciding on the next item to pick up and work on, or some flexible time in your schedule. Take advantage of all of them. Find the work item that aligns with your goals and pick it up. Make sure your team’s backlog has at least a few of them ready to be scheduled. In general, any place you have flexibility in your current role, push that flexibility towards your goal, towards the opportunities to do things that advance your goals.

For example, I want to spend more time reading papers, organizing ideas, and leveraging those ideas at work. I have some approved time on my calendar for my personal development that I use for this. As part of my job, I regularly talk to people. When someone has a problem that could use some research, I use my time to search for relevant papers, scan them, and synthesize the ideas for them. There’s an active project (for another team) that came directly from such work I did last year! I enjoyed that work, and it helped me build a track record of value.

Additionally, when I have the luxury to pick my work, I pull the more exploratory tickets. The work that could use some exploration, discovery, and organization of ideas. And I’ve made sure that my team’s backlog always has such tickets. I don’t always have the luxury to pick those tickets – often there are high priority things that have to get done – but, I am ready for those times when I do have the ability to pick them.

Defining My Job

I started this post talking about how I am trying to define my role. I am. I am doing the things described in this post. I know what I want to do: I want to advance the state of the art of performance testing and software engineering at MongoDB, ideally through collecting, curating, and demonstrating the best ideas from the performance community and academia. I take every opportunity to talk about those things, why they are valuable, what that might specifically look like for me, and why I would be good at them. You may have noticed that I just told you those things also. Maybe you will end up helping me.

Additionally, I regularly talk to my management about my desires, and how to align my interests and skills with the company’s needs. I am not yet in my ideal job, so I also regularly look for (and create) opportunities in my current role to do the work aligned with my ideal role.

Some days I make great progress. I work on the things I want and deliver clear value. Some days I try, and it doesn’t work out. Other days I work on what’s needed (and deliver value), but don’t advance my goals. Starts and stops and non-linear progress seem to be the way of life and that’s okay. On average, I am moving towards the things I want, and I hope that you do also!

Special thanks to Eoin Brazil for providing feedback on an earlier version of this post.

Wednesday, July 6, 2022

Peer Groups in the Workplace

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. 

Peer Groups

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. 

There are also many work focused peer groups, enabling people to get better at their jobs. I am a member of two industry peer groups: Rand’s Leadership Slack and LeadDev (conferences and slack). 

“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

Screenshot of a Zoom conference from a staff plus peer group meeting. There are 10 boxes arranged with one person in each box.
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 

  • Learning Opportunities

  • A Place to Complain

  • Perspective and Advocacy. 

Learning Opportunities

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. 

Tuesday, May 17, 2022

Creating and Fostering Communities at Work

Some days I feel that the most valuable thing I’ve done at MongoDB has been to create slack channels. 

I know that may sound absurd to those who know me professionally (I have done a lot at MongoDB, for example, developing our performance testing infrastructure and changing the way we spot performance changes in our testing environment), but bear with me for a moment. I have started a lot of slack channels, such as: #fountainpens, #greatoutdoors, #cookie-club, #staffplusengineering, #academic-research, #writing, #performance. And I spend time on those channels sharing pictures and stories with colleagues as well as talking shop.  My wife has said she wants to join MongoDB just so she can join the slack channels. However, the channels themselves aren’t important – what’s important is creating and fostering communities. 

Two Challenges at Work

Before addressing why work communities are important (including Cookie Club), let me discuss two work challenges that corporate executives spend a lot of time thinking about: knowledge silos and employee engagement. Knowledge silos exist when knowledge gets localized in specific teams and people don’t talk across teams. Employee engagement is directly related to both employee productivity and retention. They both relate to communication. 

Communication at work

If you are like me, you likely talk to many people during a normal work day. You talk to the members of your team frequently and know them quite well. I have daily meetings with my team and we chat on our team slack channel frequently. You probably  talk to the members of sibling teams regularly and know them, but not as well as the members of your own team. I have a weekly meeting with my parent team and we have regular social events such as team lunches. 
It may get fuzzy and distant beyond your sibling teams. Your work may bring you into contact with people on more distant teams from time to time, and there may be large numbers of people you recognize but don’t know in the office. If you only do your job, these are the people you likely know at work. 

If those are the only people you know at work, there are some problems that arise. If these are the only people most people at your work know, there are bigger problems. Those problems can be grouped into two overarching problems. First, it’s lonely. Most of us want to feel a sense of connection and purpose, and it’s hard to feel connection and purpose when your social connections are so limited. Second, this pattern of communication leads to knowledge silos at work: One group doesn’t do what the next group is doing. Both of these problems are important. 

The first problem ties directly to employee engagement. A lot has been said about employee engagement and companies care deeply about it. Engagement is tied to both retention and productivity. MongoDB cares enough about employee engagement to run twice annual employee surveys to measure employee engagement and continually improve it. The second problem (knowledge silos) is a huge area of research and discussion, as well as a source of much fretting by senior executives at most companies. 
When teams are siloed, work gets duplicated and teams work to cross purposes. Even if you manage to get all the right people in a room together, you still have a problem: no one knows each other. They don’t have working relationships. It takes time and effort to build a good working relationship, so, before any productive work is done, the work of team building and connection building has to be done.
I work on performance, which is a cross-cutting concern. I need to know which projects will impact performance, and how and why they will impact performance. More importantly, I need to know which interactions between projects will impact performance. I’ve invested time and effort into building relationships across the engineering organization so that I can do my job. As a result, I often find myself also providing guidance to others for whom to go talk to for various things, helping others break down silos as well.  

My claim is that communities at work help address both of these challenges: silos and engagement. 


A community is any group of people that come together for some shared interest and have some sense of shared identity. I split work based communities into work focused and non-work focused groups.

Work Focused Groups

Just as they sound, work focused groups are focused on some aspect of work at the company. Beyond the basic teams people belong to, work focused groups include peer groups, technical interest groups, and more. 

Peer groups connect people with similar backgrounds. They may be at the same stages of their career or be in similar roles. Spending time with these people can be very energizing and motivating. I greatly value the time I get to spend with my peers in our staff plus peer group, which is focused on senior IC (individual contributor) engineers (title of staff engineer or higher). We are focused on issues that impact the senior but non-management leaders in engineering in our company. As with any peer group, these are people trying to push the company in the same direction as myself and share a sense of purpose with me. Additionally, we can learn from each other, making ourselves better at our jobs and pushing that shared purpose forward. Strong stuff. 

Similarly, technical interest groups align people who may be in different parts of the company, but with similar technical interests. Technical interest groups help improve everyone’s skills by widely sharing learnings and best practices. It can also be motivating for members to see others across the company who care about the same technical topics as themselves. I have benefited from our performance interest group, with its speaker series and discussions in slack. I know more about performance engineering in general and performance engineering at MongoDB in particular, because of this group. 

Both kinds of groups directly help employees do their jobs better. They are worthwhile based on that value alone. The groups also foster a sense of belonging and establish connections across the company, both of which may be more valuable than the direct benefits. More on both of those later. 

Non-Work Focused Groups 

There are more groups beyond just the ones focused on work. These groups likely have no direct connection to the company beyond the fact that everyone in them works at the same company. I claim these groups are just as important (if not more) than the work focused ones. The groups can be organized around anything and they have many forms. 

Cookie Club is an example from my company: once a month we get together to bake something and share the results with each other. While Cookie Club meetings are tied to a physical location, they pull people from across functions of the company, including learning and development, engineering, education, etc. Additionally, the affiliated slack group connects people interested in baking across the company and the world. 
Plate with a selection of cookies and cake on it. Includes a chocolate cream puff, a snickerdoodle, a slice of pound cake, a square of corn bread and a cookie around the outside, with a smaller peanut butter cookie in the middle. The peanut butter cookie has visible flakes of salt on the top.
Assorted baked goods to be shared at a recent Cookie Club meeting 

I’ve been involved in other non-work focused groups organized around topics such as hiking, sustainability, fountain pens, reading, and more. And as many groups as I’ve been involved with, there are many more groups. For example, groups organized around exercise (tossing a kettle ball or doing planks near the elevators) or groups to explore different kinds of food near the office. 

The essential part of all of these groups is that they are organized around some shared interest that is independent of work and they connect people throughout the company. 

How Communities Make Work Better

As suggested above, communities help make work better by breaking down silos and improving engagement. Recall, work silos refers to knowledge being isolated in part of the company, and various parts of the company not knowing what each other are doing. Employee engagement is directly related to improved productivity and employee retention. 

Breaking down silos

The solution to silos is more connections across the organization. However, all to all communication isn’t possible in a large organization (see Dunbar’s Number). 

Thankfully, we don’t need everyone to know everyone, it is sufficient to have some connections between all the key company functions. These connections facilitate conversation. Since the point is to facilitate conversations (and provide a basis for trust for future collaborations), the connections do not need to be particularly deep. What is needed is that when an issue or opportunity comes up, someone should know someone to reach out to, and they should feel comfortable when they do reach out to them. 

Random connections across the organization go a long way to serve that need and shared interest communities are great for developing these random connections across the organization. Connections through work focused groups have high value as there is already a professional relationship. However, the non-work focused groups may have higher value since they create even more random connections throughout the organization. Or, put another way, work related groups create particularly useful random connections, while non-work related groups create more random connections, across more far flung portions of the company. Both help to break down the silos. 

For example, I’ve personally benefited from my connections at Cookie Club. After the most recent Cookie Club I had a great discussion with someone from the learning and development team (Jen) about development topics that impact me and the company. Previously, I’ve coordinated a training event for my team with Jen. My working relationship with Jen is strong in large part because we bake together. 

Building Engagement

Beyond bridging silos, communities cultivate a sense of belonging and shared purpose, leading to improved engagement. The work focused communities help employees see why their work matters, and how their work fits into the big picture. Work focused communities also help employees do their jobs better (improved skills and network) and better see the impact of their work and their improved skills. Our performance interest group shows me and others how MongoDB cares about performance across products and departments and the cumulative impact of all of our performance work.

The non-work focused groups also improve engagement. The non-work focused groups enable employees to put energy into things they care about, and share those experiences with co-workers. I have great shared experiences with colleagues across the company due to Cookie Club. I also see colleagues coming together to make MongoDB and the world a better place through supporting underrepresented groups in our Allies community. 

This leads to happier and more fulfilled workers. It also develops a larger sense of shared identity with colleagues. They have stronger relationships with their colleagues and a greater sense of belonging. Employees with a strong sense of belonging are engaged employees. 

Call to Action

As described above, communities at work help foster random connections throughout a company, improving employee engagement and breaking down knowledge silos. 

Yet the work to support and organize communities at work is often overlooked and undervalued. I hope my words make you think about work communities more and value them more highly. If I’ve succeeded at this, I would encourage you to participate more in the communities that interest you and possibly help organize or foster a small number of them. You will benefit, and so will your company. 

If you are in position of power at your company there are additional high impact actions I hope you  take: 

  1. Make it easy for your rank and file to organize and foster communities

  2. Reward and recognize the people who do so

 If you make it easy to organize and foster communities, your employees will do so. Making it easy can entail such things as making it easy to communicate (messaging, wikis, mailing lists), allowing time in the work day for activities, or providing funds. If you reward and recognize your employees who do so, those employees will keep at it and other employees will build on their efforts, ultimately building a stronger company. 

Special thanks to Rita Rodrigues for feedback on this post. Rita helped make this post better and makes our writing community a stronger community.