Five Years of Running a Systems Reading Group at Microsoft

I understand that in a research lab or in academia, this is common practice. But in the more menial coding industry that most of us are probably in, how do you find time for this? Do people read papers in their spare time and discuss over lunch, or are there enlightened managers who support this during working hours?

I would be interested to hear others experiences with running these types of groups. We’ve tried this a couple of times at my current job and both times it’s petered out - people don’t do the assigned reading and then just stop attending.

Any suggestions on how to keep such a group alive?

Hi HN, I've been organizing a systems reading group at Microsoft for five years now. I wrote down some takeaways on what worked (and what didn't). I'd love to hear if anyone else has successfully kept an engineering reading group alive at their company, or if you have any favorite systems papers we should add to our list!

Good question. Most people read the paper on their own time, and we meet over lunch. The meetings themselves are just an hour, so it's not a massive time block. I've found that the people who show up are the ones who are genuinely curious and would be reading this stuff anyway (and sometimes just need a commitment/accountability to do it). Having a group gives them a reason to do it on a schedule.

Speaking as a SWE manager who explicitly “mandates” (not actually mandatory but I strongly encourage following your passions and interests in an academic kind of way!) we do exist, I assume I’m not the only one :)

My team almost always can find an hour between tasks organically so I’ve never really had to push

I'm not sure what you mean by menial coding but all my employers have supported this in the past. This was a variety of companies, big tech, startups, etc. I think its more likely your employer is the outlier.

This is a very good question. I also struggle to find a good solution to process various signals (papers, tecniques, etc.) with my co-workers while maintaining proper work-life balance. Either you have to be a full time geek, or be left behind..

> The meetings themselves are just an hour, so it's not a massive time block

How exactly are the meetings structured? I.e is someone leading discussions? Does each person go around and share thoughts? Etc

That implies that you have a fixed time for lunch and also chat during lunch. I may be the minority but I prefer to eat when I'm hungry and focus on the food instead of chatting. And there is also allergies, as a celiac, I have big troubles eating together with others - they may accidently contaminate my food

Any suggestions on how to keep such a group alive?

I lead a book club once (Designing Data Intensive Applications)- read a chapter and meet every two weeks. Was a real flop. Attendance remained high, but only one other person actually finished the book.

What was a real slap in the face - maybe a year after that book had concluded, someone told me I should lead another one about this other topic. She had not finished the first book, and she wanted me to regurgitate another to the group?

This is great and congrats on the success. Many years ago I tried starting a cybersecurity reading group in my city since the startup I was working at was small and people there weren’t interested in that topic. I got a lot of very green, aspiring and non-professionals to show up. We couldn’t really agree on where to start and people had different ideas of where to focus or even how much they wanted to contribute. Mostly people wanted to hear a summary and didn’t really put in the kind of effort that I had hoped. It didn’t last long. Congrats again on making it 5 years and covering so much ground.

Interesting. We don't have an engineering culture, so definitely no. Did you find similar groups within MSFT?

BTW heard about this paper[1] a few weeks ago, but not completely aligned with database and probably a bit too introductory for your group.

[1]https://www.cs.fsu.edu/~awang/courses/cop5611_s2024/vnode.pd...

Any tipps on finding interesting and valuable papers?

> The meetings themselves are just an hour, so it's not a massive time block

How exactly are the meetings structured? I.e is someone leading discussions? Does each person go around and share thoughts? Etc

My team almost always can find an hour between tasks organically so I’ve never really had to push

I’ve been scolded for reading books and documentation for the tasks and software I was asked to build (at a startup) during my regular work hours

No company I’ve worked at has ever had dedicated time for reading papers or articles

Maybe I’ve only worked at outliers?

Thats my experience as well. Of course not ten paper a day but some learning is always encouraged.

One company had a +1 day. You worked 4 days, had 1 day for learning - everything relevant for the job was fine.

Thank you! I think the biggest factor for us was that most attendees already had some technical baseline. That makes it way easier to pick papers and have productive discussions. A cross-experience group sounds much harder. We occasionally have non-technical people who attend (e.g., designers), but they usually are very eager to learn. The guided series format might have helped in your case, where you pick the topic and sequence upfront so there's less debate about direction each meeting. Honestly, just getting people to show up is hard at first, so the fact that you got it off the ground at all says something.

Thats my experience as well. Of course not ten paper a day but some learning is always encouraged.

One company had a +1 day. You worked 4 days, had 1 day for learning - everything relevant for the job was fine.

I’ve been scolded for reading books and documentation for the tasks and software I was asked to build (at a startup) during my regular work hours

No company I’ve worked at has ever had dedicated time for reading papers or articles

Maybe I’ve only worked at outliers?

In 35 years in the industry, reading and studying during work hours were always supported. Frankly, most places would let us play video games during work hours as long as we met our deadlines.

> I think the biggest factor for us was that most attendees already had some technical baseline. That makes it way easier to pick papers and have productive discussions.

Thanks for sharing your experience.

How do you suss out peoples technical aptitude, and what was the minimum level you were looking for?

How were your discussions structured?

Any tipps on finding interesting and valuable papers?

It depends on the theme. If we're picking something in a space the group already knows well, like databases, I'll look at "Best Papers" from recent VLDB/ICDE/SIGMOD conferences. If we're exploring a topic most people are unfamiliar with, we'll go with something more foundational instead. For example, we're starting an arc on datacenters (servers, racks, networking, load balancing, power, cooling, failures, etc.), and most attendees don't have deep background there, so I found a book on the topic that we're going to read through[1].

[1] https://link.springer.com/book/10.1007/978-3-031-01761-2

Interesting. We don't have an engineering culture, so definitely no. Did you find similar groups within MSFT?

BTW heard about this paper[1] a few weeks ago, but not completely aligned with database and probably a bit too introductory for your group.

[1]https://www.cs.fsu.edu/~awang/courses/cop5611_s2024/vnode.pd...

There are other groups within Microsoft, but they usually follow a presentation format rather than a collaborative discussion. Off the top of my head, Phil Bernstein[1] and Hanuma Kodavalla[2] run great database seminars for invited speakers. I regularly attend and have presented in both forums; Phil's crowd is mostly researchers, while Hanuma's is mostly full of SQL engineers. Different from a small reading group, but still great.

Appreciate the paper link! We like going back to the basics sometimes, so I'll definitely take a look.

[1] https://en.wikipedia.org/wiki/Phil_Bernstein

[2] https://scholar.google.com/citations?user=9eNQbZUAAAAJ&hl=en

In 35 years in the industry, reading and studying during work hours were always supported. Frankly, most places would let us play video games during work hours as long as we met our deadlines.

> I think the biggest factor for us was that most attendees already had some technical baseline. That makes it way easier to pick papers and have productive discussions.

Thanks for sharing your experience.

How do you suss out peoples technical aptitude, and what was the minimum level you were looking for?

How were your discussions structured?

Appreciate the paper link! We like going back to the basics sometimes, so I'll definitely take a look.

[1] https://en.wikipedia.org/wiki/Phil_Bernstein

[2] https://scholar.google.com/citations?user=9eNQbZUAAAAJ&hl=en

Thanks for the references!

[1] https://link.springer.com/book/10.1007/978-3-031-01761-2

Thanks for the references!

March 2026

I started a reading group in 2021, a few months after joining Microsoft as a new grad on the Azure Databases team. The group was initially focused on database internals, which was my favorite subject at UW. Databases touch so many areas of CS: compiler construction in the query engine, memory management with the buffer pool, storage systems, algorithms, networking. It's almost a microcosm of the whole field. There's also plenty of active research and conferences, like SIGMOD and VLDB, so it never gets old.

How it started

My day job is on the backend distributed storage engine for Cosmos DB, so I spend most of my time thinking about LSM-trees, B-trees, and distributed systems. When I joined Microsoft, I wanted to find other people who were curious about these topics beyond what their immediate work required.

The first paper we read was Algorithms Behind Modern Storage Systems. A handful of people showed up. The format was simple: everyone reads the paper on their own, we meet for an hour, and we talk through it. Pretty informal, just a conversation about the paper.

From there we went through a mix of database internals classics and systems papers:

WiscKey: Separating Keys from Values in SSD-conscious Storage
LLAMA: A Cache/Storage Subsystem for Modern Hardware
Finding a Needle in Haystack: Facebook's Photo Storage
Column-Stores vs. Row-Stores: How Different Are They Really?
The Bw-Tree (I'm a bit biased on this one since I work on the Cosmos DB implementation), and an interesting follow-up Building a Bw-Tree Takes More Than Just Buzz Words

That was basically the format for the first couple of years. Someone would suggest a paper, we'd vote on it, and then we'd meet and discuss. We also had a side channel where people shared engineering blog posts and talks that caught their attention. That informal sharing turned out to be just as valuable as the readings.

How it evolved

The more database papers we read, the more we found ourselves pulling on threads that led outside of databases. A storage engine paper would turn into a conversation about memory hierarchies. A replication paper would lead us into consensus protocols. Over time we started deliberately reading papers on adjacent topics, like What Every Programmer Should Know About Memory and Paxos Made Simple.

In 2024, we shifted from one-off papers to guided reading series. We worked through sections of the Red Book (Stonebraker and Hellerstein's Readings in Database Systems) over several sessions. That structure made a big difference. Instead of context-switching between unrelated papers every meeting, we could build on previous discussions and go deeper.

By 2025, the scope had grown well beyond databases, and I renamed the group to "Microsoft Systems Reading Group" to reflect that. The 2026 theme is datacenter foundations, and we will be reading through The Datacenter as a Computer and learn about things like servers, racks, network clusters, load balancing, power supplies, cooling, efficiency, failures, etc. Things we rely on and take for granted when we build a distributed database on a public cloud.

What I've learned about running one

Start small and stay consistent. The group has had active periods and quiet periods. The quiet periods almost always happened when the cadence got disrupted. It's better to meet once a month without fail than to aim for biweekly and skip half of them. Consistency builds habit, and habit builds attendance.

Let the scope grow organically. If I'd insisted on "databases only" from the start, the group would have stagnated. Following curiosity wherever it led kept things interesting and brought in people from different teams who wouldn't have joined a databases-only group.

Guided series beat one-off papers. One-off papers are great for getting started, but a multi-session series on a single topic is where the real depth happens. People build shared context, and the discussions get progressively more interesting.

You don't have to be the expert. Some of the best sessions were on topics I didn't deeply understand. Saying "I want to learn about this, let's figure it out together" is a much better pitch than "let me teach you about this." It lowers the barrier for participation and makes the group genuinely collaborative.

Have a co-organizer. This year, a colleague reached out about restarting the series after a quiet stretch. Having someone else invested in keeping things running makes a huge difference. When one person gets busy (and you will), the other can keep the momentum going.

Make it easy to show up unprepared. Not everyone will read every paper. That's fine. If your format requires everyone to have done the reading for the meeting to work, attendance will drop. A quick 5-minute summary at the start goes a long way.

What I got out of it

The obvious benefit is learning. I've read papers I never would have picked up on my own, on topics ranging from memory chip architecture to how Google schedules containers at scale.

But the less obvious benefit is the people. Running this group connected me with engineers, researchers, and scientists across Microsoft who are curious about the same things I am. Some of those connections have led to useful conversations about real work problems. Some of them are just interesting people to talk to. It also makes me happy to know that this company is full of people who are genuinely interested in this stuff.

If you're thinking about starting a reading group at your company, don't overthink it. Just post a paper, invite some people who you know will be interested, and see who shows up. You can figure out the rest as you go.

If you're a Microsoft employee and want to join, you can find us at aka.ms/msrg.

Main

Hacker Times