jade rubick

A history of Mini-Ms


This recounts the organizational history of Mini-Ms. Histories like this are important for a couple of reasons:

  • They can provide valuable context.
  • You can use that context to give you a better ability to adapt practices to your local situation.
  • And you can learn from the history about the environment from which the practice emerged, helping you to create a similarly fertile place for other practices to grow.

This post is last in a series:

  1. We first looked at how Mini-Ms work and what they are.
  2. Then, we covered how to implement Mini-Ms.
  3. We next discussed variations you may want to consider.
  4. And finally we cover the history of Mini-Ms.

Before we had enough managers to have Mini-Ms, we had one management group for engineering. We called this the M-team meeting (and the name Mini-M came about when we split it up).

In the early days, this meeting combined operational matters and topics designed to make us better managers. Our VP of Engineering would present on topics about how to be an effective manager. For example, how to run effective meetings, or on project management. But a lot of our topics were conversational in nature: like a discussion group on management.

The management meeting format varied depending on the problems we were solving. For example, during review periods, we would read each other’s reviews and critique them.

I participated in these early review review sessions, and they taught me almost everything I know about writing reviews. “Overall, the performance reviews at New Relic were better than most places I’ve worked before or since, and I attribute much of it to this practice… There were multiple sets of eyes on reviews which helped identify bias and also ensured nobody ‘phoned it in’.” – Jason Poole, former Mini-M Organizer.

In the early days at New Relic, we had weekly status updates that were due every Friday. Managers would gather and write them together. We called these meetings “Status Jams”. This was importantly different than the official M-team meetings, because Bjorn Freeman-Benson, our VP of Engineering, wasn’t there. It is very hard to create peer connections if a hierarchical leader is present, so those Friday meetings gave us a time to check-in with each other, decompress, and occasionally kvetch about things we didn’t agree with or understand.

Nic Benders was in charge of a team that was developing a new product. At one point, Nic left that team to go create Site Engineering, and another manager, Etan, was selected for that team. Nic and Etan started having a weekly 1-1, where they talked about the team, management, and other topics.

The seed for Mini-Ms happened when Jon, another manager, joined the management team to build yet another product. Bjorn said, “Hey, Nic, can you add Jon to your 1-1 with Etan and help him get up to speed?” This group became the first Mini-M.

This went so well that Bjorn decided to make it into something that should be scaled out to everyone. He designed it as an organizational practice. He assigned managers to Mini-Ms and insisted everyone attend one. And he tweaked the practice over time.

Bjorn described the thinking behind it this way: “The purpose of the mini-Ms (originally) was to help the managers improve their craft just as pair programming or mob programming or code reviews are used in the development team to improve that craft. It had additional benefits such as creating a more consistent management practice across the whole org and being emotional support for managers (because it is a tough job), but the original goal was about people stronger in one skill helping people weaker in that skill get better. And because nobody was better in all the skills, having a group help each other improved everyone more rapidly than 1-1 coaching, etc.”

This part was related by Nic Benders, then reworked by me to make it more intelligible to people who weren’t there. If you have more to contribute to the history, let me know!

Thank yous

Not a lot has been written about Mini-Ms, but there is one post currently on the New Relic blog, and another that has mysteriously vanished.

Bjorn Freeman-Benson was the founder of the Mini-M practice. He shared a lot of his thinking about the principles behind why Mini-Ms were successful and what they were aiming for. He advised me to break up this post into sections and make it easier to get to the implementation section. And shared overall feedback.

Nic Benders ran the first Mini-M, and established and evolved the practice. He also ran one of the more influential Mini-Ms for years. He reviewed this post, offered feedback, and contributed to the history section and described some of the design goals for Mini-Ms.

Darin Swanson authored some content that were inspirations for large parts of this article. He and I have worked together on helping other companies implement Mini-Ms, so contact me if you’re interested in help. He also provided feedback and suggestions on drafts of this article. He encouraged me to explain the first team concept more fully, and to describe why pre-product market fit companies may not be a good match. And he suggested I split the content into separate articles.

Elaine May provided feedback, some of which was so good I just ended up quoting her. She was gracious enough to offer some talk to talk about her experiences setting up or participating in similar programs at other companies. And she talked about her experiences with me in New Relic’s Mini-Ms. Elaine introduced me to the Chatham House Rules, which I incorporated into the post.

Merlyn Albery-Speyer helped me improve the section on “when to use Mini-Ms” by pointing out some preconditions for success. He pointed out that the structure became less important after the Mini-M is established. Merlyn pointed out that we tried to keep people from being in the same Mini-M as their managers, or other people reporting to the same manager. He also shared the theory about VPs not being willing to be vulnerable as a possible explanation for why the Mini-Ms never took off in manager of manager groups to the same extent they did for frontline managers.

Molly Graham contributed the section on “Manager coaching circles” in the variations post. She has an insightful newsletter.

Jason Poole shared his experience as an Organizer of Mini-Ms. He pointed out a now mostly disappeared second post on Mini-Ms. He also suggested ways Facilitators could counter unproductive ranting, and pointed out how effective the Mini-Ms were for improving our performance reviews.

Marty Matheny shared feedback based on his experience as an Organizer. He helped improve the advice for Organizers. And he pointed out that engineering adjacent departments participated.

Chris Hansen pointed out that confidentiality was an issue with whiteboards. He noticed an error that would have been embarrassing. He pointed out the value of M-teams in distributed organizations to counter isolation among managers. He also added some advice for participants. Chris also helped with a point about the value of the first few meetings.

Teresa Martyny reviewed a draft of this post and pointed out some redundant assertions I was making. And she recommended I break this into multiple posts or edit for brevity.

Natasha Litt was another early Mini-M leader, and she reviewed a draft of the post and contributed to it.

Marco Rogers influenced some of my thinking on building communities in a recent conversation, so some of his ideas were reflected in that section.

Image by Tide He from Pixabay

Comments powered by Talkyard.