[Editor’s Note: This article originally appeared in the SIGOPS blog and is re-posted here with permission.]

With most systems and architecture conferences taking the online route, we figured it’s a great time to get to know a few people in the systems/architecture research community. People of Systems & Architecture is a series of interviews conducted this year, and continues in the same vein as the People of PL, People of POPL, and the People of Language Design and Implementation interviews done by John Wickerson, Jean Yang, Brandon Lucia, and Minjia Zhang.

In this edition, Akshitha Sriraman meets Margo Seltzer, who is the Canada 150 Research Chair in Computer Systems and the Cheriton Family chair in Computer Science at the University of British Columbia. Her research interests are in systems, construed quite broadly: systems for capturing and accessing data provenance, file systems, databases, transaction processing systems, storage and analysis of graph-structured data, new architectures for parallelizing execution, and systems that apply technology to problems in healthcare.

She is the author of several widely-used software packages including database and transaction libraries and the 4.4BSD log-structured file system. Dr. Seltzer was a co-founder and CTO of Sleepycat Software, the makers of Berkeley DB, recipient of the 2020 ACM SIGMOD Systems Award. She serves on Advisory Council for the Canadian COVID alert app and the Computer Science and Telecommunications Board (CSTB) of the (US) National Academies. She is a past President of the USENIX Assocation and served as the USENIX representative to the Computing Research Association Board of Directors and on the Computing Community Consortium. She is a member of the National Academy of Engineering, a Sloan Foundation Fellow in Computer Science, an ACM Fellow, a Bunting Fellow, and was the recipient of the 1996 Radcliffe Junior Faculty Fellowship. She is recognized as an outstanding teacher and mentor, having received the Phi Beta Kappa teaching award in 1996, the Abrahmson Teaching Award in 1999, the Capers and Marion McDonald Award for Excellence in Mentoring and Advising in 2010, and the CRA-E Undergraduate Research Mentoring Award in 2017.

Professor Seltzer received an A.B. degree in Applied Mathematics from Harvard/Radcliffe College and a Ph.D. in Computer Science from the University of California, Berkeley.

A: Tell me a little bit about your career journey.

M: It’s a circuitous journey that had no pre-planning. One of the things that I always tell my graduating students, particularly undergrads, is don’t try to plan out the rest of your life; figure out what you’re doing next. In large part, that’s because I never could have predicted where I ended up. 

I grew up in the middle of nowhere in upstate New York in a teeny tiny school. It was a teeny tiny town where we had more cows than people. But, I was from an academically focused family; there was never a question of whether college was in my future. I was very much a math and science person. I remember that when I was in middle school, I fantasized going to Harvard. I have two brothers, both of whom are quite a bit older than I am. One of them had applied to Princeton and been rejected. This was always referred to as a “character building experience” in my household. So, I applied to Harvard, and I knew that I was going to get rejected, and that was going to be my character building experience. Except, Harvard had the poor sense to admit me. So, I went to Harvard. Now you have to understand that when I said this to people in my town, they were like “Oh, where’s that?” I remember that my boss at the restaurant I worked was pretty excited; he would tell all his customers about it, but, most people were just like, “Oh, that’s nice” [shrugs]. “Where’s that? Is that as good as the local school up the lane?”

So, I prepared myself for coming from a place where I was big fish in a little pond to going to a place where I was no one. I set myself up for that, which was fine. For me, college was a journey of figuring out things that I’m actually pretty good at. One of those was running things. Another, which I learned through both good and bad experiences, was leading people. I had a fabulous time in college and worked super hard, because I was basically paying my way through college as well. By the time I graduated, I was like, “I’m done with school. Maybe someday I’ll go back, but for now, I’m done.” So, I went and got a job and I did three startups in a period of five years. One of the smart (i.e., I made a lucky decision) things I did right around the time I graduated was taking the GMAT, LSAT, and the GRE tests. That was to keep all my bases covered. My thought process was that I was probably going to test better then than I ever would in the future. Also, the test results expire in five years, which meant that at some point I’d have to decide what I wanted to do. 

I was at startup number three and I got dumped by a boyfriend, like really hard. I was really upset and we tried to do the “let’s be friends”. After a few weeks, we decided we’d talk on the phone and he said, “What are you up to?” I said, “Oh, I was thinking, maybe I’ll take a graduate course. If I like that, maybe I’ll apply to graduate school”. And he laughed and said, “Oh, well, that’s what you said when I first met you”. Now, he’d only met me six months ago, but I was livid. So I took a graduate class and then I applied to graduate school. I *do not* recommend this as a technique for going to graduate school, but it sort of worked out for me.

I was working for a company that was somewhat insane in a variety of ways. I had it in my head that if I went to grad school, they couldn’t be mad at me. Whereas if I left and went to another company, they could be mad at me. Again, not really a good decision making process. But, in fact, they were so mad that they sent letters to Stonebraker, Patterson, Katz, and Ousterhout explaining to them that I had been working on a proprietary project and under no circumstance was I allowed to talk about it. Now I assumed that they did this because they figured that that would torpedo my graduate career. Instead, it meant that I showed up in grad school with this mystique like, “Oh, who is this person for whom they felt the need to do this?”

Grad school was great [thinks]. Um, no, grad school was not that great. I like to tell my students who start their PhD that there will be times in grad school when it’s really, really hard. I tell them “Just don’t hide if you have a problem. I’m here for you. We’ll get you through this”. Nobody told me that.

So, there were times in grad school when I wanted to quit.

In fact, at one point, my partner, who is now my husband, was looking at a possible job in a different state. And I was like, “Oh, please take the job” since then I’d have an excuse to drop out of grad school, because without the excuse, I couldn’t drop out [rolls eyes]. Like you just can’t do that.

By the time I finished, I figured that it made sense to go after the one job that I couldn’t have gotten if I hadn’t finished. And that was being a professor. Again, not the best decision making strategy [laughs]. But I went on the market. I was ridiculously successful and long story short, I ended up at Harvard. It was the best job in the world for me because, it turns out I don’t do really well with a boss. Academia is one of very few jobs in life where you don’t really have a boss. So, it actually turned out to be a great fit. It brought together the various aspects of me that I was really good at. I’m a people person, I’m an extrovert. But, I’m also a geek. I really enjoy programming and I like technology. Being a professor lets me do those two things. So, that is the journey full of really, really bad decisions. It still got me to an okay place.

A: Thanks! Moving on to my next question, what are some of your current research directions?

M: The fundamental problem I have can be described either as really broad interests or really short attention span. I do too many things. I continue to work in storage because that’s been my bread and butter since day one. I have an incredibly wonderful collaboration with Cynthia Rudin at Duke where we do interpretable machine learning. She does the math and I make stuff run quickly. We get awesome students to help us, and that’s been fabulous. I’ve got a bunch of stuff in graph processing and then my newest crazy endeavor has been program synthesis. Then, there’s my work in data provenance. I spent the first ten years I worked on data provenance worrying about how to get provenance and then realized that nobody cares about data provenance. What they care about is making their lives easier. So, now we use provenance; it’s a rich source of information upon which we can build tools that actually improve people’s lives. And then there are my three last Harvard students, one of whom is working on interactive program synthesis, another is working on interesting systems and security applications of whole system provenance, and the third is working on machine learning for program repair.

A: How do you come up with your research ideas? 

M: That’s a great question! I subscribe to many strategies, so I don’t have a good answer. One of my favorite answers was from Brian Bershad who said that he subscribed to the frying pan school of problem solving: after you hit yourself over the head with a frying pan enough times, you should stop and say, “Wow, that really hurts. I wonder if I could fix it”. Data provenance was one of those things, where documenting scientific processes is really hard when people don’t do it and it’s terrible. So maybe we could fix that. Similarly, with the program synthesis project, nobody likes writing assembly language, yet there are still places where people have to write low-level code. It turns out that, especially in the embedded, particularly embedded military platforms, they run software that is decades old. The reason is that it’s just too hard to upgrade the software. New hardware comes out, and it’s now too painful to upgrade software. So, how can we expedite that process and allow software to grow with hardware? 

I’ve never seen a research problem I didn’t like.

I talk to people and they’ll mention things that are interesting. Collaboration is really fun. I’ve got a couple of visualization projects going on, because systems people are often really good at producing interesting data and not very good at helping people use it. I am not somebody who knows how to solve visualization problems, but I can often identify things like, “Ooh, this is really interesting data! I wonder if there’s a way we could make it accessible to people”. I’m really excited about being able to visualize the data that we use to make intrusion detection systems, because in many cases, you get an alarm that says, “Oh, we think there’s intrusion”. And it’s like, “Why?!” um well because some piece of software says so. I think it would be really great to give people the mechanism to dig down into it and get a sense of what’s going on. So, that’s been a whole fun area.

My secret desire is that I want to spend the rest of my career trying to publish in as many different areas of computer science as possible. I’ve got my first PL paper under submission at the moment, but I’ve never published a theory paper. My ML papers have a lot of math in them though. I haven’t published in scientific computing either. So yeah, that’s my new fantasy.

A: Your research spans across a wide variety of areas. You’re an expert in a whole host of different fields.

M [interjects]: Or an expert in none [smiles kindly].

A: How do you go about working in all these different fields and maintaining the level of expertise that you do across all of these different projects?

M: It’s all smoke and mirrors?!

One of the things I love about being a professor is that a part of my job is to learn new stuff.

I learn a ton of stuff from my students and I think at some point they don’t realize that they know more about things than I do. I have to repeatedly tell them that, and they don’t believe me. I remember one episode this past year where it was a project in the storage area, and I was getting frustrated because there was something that I fundamentally didn’t understand. I knew the student did. It had never occurred to the student that I didn’t understand something that they did! I was like, “No, no, no, you really do”. I really want them to know that. That’s the great part about working with really smart students: they teach you stuff.

I learn a ton from my collaborators. In some ways, the places where I’ve had the most impact on my ML collaborations is where I don’t understand something and I keep asking until I get it. This makes the collaborator understand the different perspectives better too.

I think everybody has a superpower and part of your goal in life is to figure out what your own superpower is.

I am not the best systems builder. I’m not the best ML person by a long shot, but I am really good at synthesizing information from different places, putting it together, and seeing connections that maybe aren’t obvious to other people. A lot of research problems I’ve identified arise from asking dumb questions and then being able to see things in other areas that fit together. Initially, it never occurred to me that this was a skill, but it turns out that it is.

There’s an ability to be comfortable with figuring out the right layer at which you need to understand something. For a lot of us who are inherently control freaks, it’s super hard to say, “Oh, I understand it at this higher level and I actually don’t understand low-level details”. I think that’s a really uncomfortable position for a lot of people, but if you’re going to work across areas, there are going to be some areas where you’re going to have to draw a line and say, “Okay, I can stop here”. I don’t know if this is a skill or a failure of a skill. Often with graduate students, one of the challenges, particularly when I’m encouraging them to do these bold, stupid, audacious (pick your right word) projects is helping them figure out that they don’t need to go all the way down to the bottom on every topic. You need to understand that this is the technology we’re going to use. So, you don’t need to understand how to develop it from scratch. But, I think learning where to draw those lines and say, “Okay, for this project, I can be comfortable knowing things at this level, without going all the way down to the bottom” is important. I think I’m more comfortable than many people relegating some of that to a magical black box. But then, I sometimes get myself in trouble that way [laughs].

The biggest challenge for me is I don’t get big blocks of uninterrupted time. I feel that that would be a luxury and I can’t figure out how to make it work in my schedule because the students have a fixed amount of time to get their degree. My job is to help them be as successful as they can during that period of time. So, that’s where my energy has to go. I need to make sure that the students are doing their best work and that I am staying just enough above water that I can make sure that they’re swimming quite comfortably. I would love to have more time to just code for fun as I enjoy coding. But, I don’t have enough time to do that. 

A: What is your most favorite research paper?

M: I have a couple that I really like a lot from a pure technology point of view. I still love the VMware ballooning paper by Carl Waldspurger. We often read that one in my class and I think it’s just such a cute, clever idea. I also love the Martin Rinard failure-oblivious computing paper because it’s the first time and maybe the only time I’ve been at a conference and I saw people walk out of the room literally angry that he would even propose that. But, I thought it was great. Oh, and then there’s always Ken Thompson’s trusting trust paper about the compiler hack, which I love.

For my USENIX lifetime achievement award keynote, I titled my talk “The fine line between bold and fringe lunatic”. It’s sort of about this struggle of picking a project that is sufficiently hard and challenging that you can really focus on intellectually stimulating stuff while minimizing the amount of drudge work (Dijkstra said this far more eloquently than I). In both the PASS (Provenance Award Storage System) and VINO projects there was a lot of drudge work. We had to rewrite the C library for VINO and we just did a ton of kernel hacking in PASS. It’s just not a good use of time. I try to avoid asking graduate students to do work that is boring and mundane and isn’t really going to teach them a lot.

A: You have received numerous teaching awards over these years. What are some of your favorite teaching moments?

M: One of the first courses I taught at Harvard was a big intro course. It’s now CS 50, I think. At the time, I changed languages and introduced the internet to CS 50. My husband has this saying: “Who let these people out alone?!” when he sees somebody making a decision that’s extremely stupid. Halfway through the semester, I walked out of class and I was feeling pretty good about it. And all of a sudden, it hit me. “Oh my God, I’m one of those people they let out alone”. They just said, go teach our intro course. And I totally changed it. 

When I used to teach the operating systems course at Harvard, this is going to sound crazy…but, grading final exams in that course was always incredibly rewarding because, the students who three or four months earlier couldn’t have given you a concrete definition of an operating system are able to talk about real system design tradeoffs with a reasonably good level of sophistication. That is really quite remarkable. The fact that I can watch that transformation over three months is amazing. 

This isn’t traditional teaching, but there’s this moment pretty much with every PhD student where you’re in a meeting with them talking about their work and something happens and you just look at them and say, “Oh, you’re ready to graduate”. I vividly remember a student who was very polite and deferential. We were in a meeting and I don’t even remember the context, but he said something and I kind of teased him about it. And he turned around and teased me back. And I was like, “Oh my God, you’re ready to graduate!”. He was like, “huh?!” [shrugs]. It’s that willingness to be independent and being able to push back. That’s always a really fun teaching moment.

At Harvard, I was co-teaching with Radhika Nagpal (which is a ton of fun btw) when I learned to appreciate functional languages. It was a bizarre course. She was teaching the first half in Scheme and the second half we taught with C++. I never liked Scheme and never liked LISP or any functional language, but one of the assignments she was going to have them do was a babbler. Larry Summers had just given his infamous speech about gender and math. I wanted to babble Larry’s speech. So, I sat down to do the assignment and I was writing pages and pages of code. I pulled Radhika aside and told her that I thought the assignment was really hard. She looked at me and was like, “What do you mean? It’s three lines of code!”

She thought nothing of the fact that you recreated the dictionary every time you added a term to it. Whereas, I was writing an update-in-place dictionary scheme, which is like a total “no no”, but it was this aha moment of like, “Oh, I really am not thinking about this right, am I?” I was bringing my systems hat to the problem, and that was not the right hat to bring. So, I think that sometimes just working with students helps you realize all the biases you have. They may not be societal biases, but they’re most definitely technical biases. 

There was this student who always sat about three rows back and was really intense. I was convinced that this student hated me. It was really intense. And I was like, “I don’t know what I did wrong!” It turns out the student and I are total buds at this point, we get along great. The intense look was just because the student was really concentrating and trying to pay attention. But, we bring these biases in, and we make assumptions about people that are totally wrong.

My favorite part is when students are able to either tell me I’m wrong or demonstrate something that I wasn’t sure they were capable of doing. 

Having spent my early teaching career at Harvard, I felt that the most important thing I could teach any of those students had nothing to do with computer science. It had to do with being able to say “I was wrong. I made a mistake and I’m sorry”. If I could teach them to say those things, I’d succeed. Unfortunately, though not intentionally, I ended up saying those things in class a lot, because I do make mistakes. 

One of my worst yet best lectures was when I was teaching a concept I had taught many times before. But, I just got really confused and I kept saying, “Oh no, that’s not right”. I kept trying to fix it. Within a few minutes, the whole class was working with me and trying to fix it. At the end of the class, I said I was going to think about it. And I did. But as I walked away, I realized that that class was more engaged than any I’d taught. I guarantee that every student in that class knows the concept way better than any other class because they actually tried to solve the problem. I thought, “So why am I up here lecturing, if that’s not how students actually get engaged and learn?” I then started re-thinking my relationship with the students in the classroom. If I’m just standing there throwing information at them, it’s not very useful. It’s a bad use of our time together. So, I try to use that very sacred time effectively to help them dig into the material in a much deeper way than just saying “Here’s what this program does”. 

A:  Moving on to interesting career transitions, you moved from Harvard to UBC and became the Canada 150 research chair. How did that come about?

M: One of my former students, Sasha Fedorova, reached out and told me that UBC was looking for a systems person. I said, “Well, I can’t go anywhere before 2018 because that’s when my daughter graduates from high school”. They said they could be patient. So, we started what I like to call “dating”. I came to UBC and I interviewed and then we followed it up. This went on for quite some time, because I wasn’t doing anything until 2018. So, I like to say we dated for a long time.

I got this wonderful phone call in the August of 2017 where they asked me if they could nominate me for the C150, and I was like “Yeah, that would be awesome!”.  By the time that came through, UBC was a done deal and I couldn’t turn it down. Part of why I like this department is also because the department was patient and gave me the time to decide what I wanted to do. They let me wrap my head around not just leaving Harvard, but leaving my home, my state, my country, and my kids. And that took time. 

A: How did you go about establishing your own startup? What advice do you have for academics who want to start companies of their own?

M: My husband and I started the company together when we both had day jobs. We described each week of that first year as the first 40 hours and the second 40 hours. It was kind of crazy. We also had our first kid shortly thereafter. So again, not things I would plan for, but it worked out great. The company was fabulous and I love my son, so it’s all good. 

To have a successful company, you need a good idea, a lot of hard work, timing, and luck.

I think that it’s extremely easy to underestimate the importance of luck. In some ways, timing and luck are tightly coupled. I have little tolerance for people who attribute their success to strategic decisions they made. Yes, they worked hard, had some great ideas, and tried to make good decisions. But, if they had not been lucky, it really wouldn’t have happened. 

I feel fortunate that things worked out well for us. The reason to start a company should not be because you want to get rich. I think that’s a really bad idea, because most companies fail. For us, we had an idea for something we wanted to build that we thought people would find useful. It was the lure of the luxury of trying to build something that we thought would benefit people.

We were building a product for engineers, so we were working with people just like us, and that suited both our personalities really well. I was excited about building something cool that people would use. I couldn’t imagine being yet another app developer. I don’t think that would excite me unless it were an app that I genuinely believed was going to make the world a better place. If I’d been the right kind of person to work on COVID contact tracing, I would have found that appealing.

A startup is not for everybody though. My children grew up with arguments about executive decisions at the dinner table. This probably wouldn’t be in the top ten list of my parenting tips: One of the cruelest things we ever did to our children was telling them that we were selling the company before we were able to tell our employees. We had to sit our children down and explain that the information we had discussed at the dinner table was really secret information that they couldn’t talk about. At the time, we didn’t realize how stressful that would be to an eight year old. I wish we had handled that better, but it worked out okay. The day that the news went public, you could see the weight of the world lift off my son’s shoulders. 

I would encourage you to do it if you’ll be sad that you didn’t try.

Do it because you can’t imagine anything more fun than working on the idea you have. If it meets those criteria, then go for it. We’re in a field where the downsides are: “Oh, so it might not work”. And then, you can just go back to being a professor or get another job. The downsides of our field are just not that bad [pauses]…except, you know, building the next thing that leaks people’s data. Now, *that* would be bad.

A: What are some of the biggest challenges you faced in your career, and how did you go about overcoming them?

M: Remember that luck thing? I was pretty lucky. [winks]

This is going to sound really trite, but I think it’s figuring out when work just isn’t the most important thing and family is. And being comfortable with that.

I remember a conversation with someone who said, “Well, don’t you want to be a Dean?”. I said, “No, I’ve got two kids under the age of 10. Why would I do that?” And he sort of smiled. He said that that was the right answer. Had I chosen a different path when the kids were little and really tried to work my way up the academic ladder, I could have been something else now and I could possibly be, who knows, the Dean, the president, whatever. I’d probably enjoy those jobs, but it would not have been worth the trade off. 

I think the biggest challenge was figuring out how to be both the parent I wanted to be and the professional I wanted to be. Unfortunately, the thing with being a parent is that you get to find out how well you did only after 20 years or so; there are no report cards. There’s not even a paper acceptance. I look at the kids now and I think they’re pretty awesome. So I feel okay. But, you could imagine a different outcome where they might’ve wanted nothing to do with me, and I wouldn’t feel okay about that. 

A: What do you like the most about your job?

M: It’s probably the interpersonal interaction. COVID has been tough because I’m a people person. I could have been an engineer at a company since I really like building systems software. But, the whole reason why I do what I do is because I also like to build systems of people. In many ways, I find both of these system building projects equally enjoyable.

A: You’ve been a part of the USENIX community since 1989 and have held various leadership positions. How has the systems community evolved over this period? What are some stark differences you observe compared to when you attended your first systems conference?

M: Okay, I’m going to sound like an old lady complaining about things now! When I attended a systems conference in the late eighties or early nineties, the systems community there had both academics and practitioners, i.e., people who delivered products. That really appealed to me because I’m a pragmatic person. I had worked in industry. I used to joke that I tend to not try to solve the problems that start with “If pigs could fly…”. I’m more like the person who says, “Show me the flying pigs”. That community really felt right to me and I liked it. So, that was my chosen publication venue for a long time, because it was where you found people who were building real systems that had impact.

You could talk to people about the real problems they were trying to solve.

Ironically, in our effort to make USENIX conferences more well-respected, we ended up making them less relevant to practitioners.

When you see industry involvement in conferences today, it’s almost always researchers from industry as opposed to product people from industry. The biggest transition I’ve seen is that the academic, research, and product communities used to be the same. But now, they’re very different. There is little reason for a typical software developer to go to an academic conference. I think there’s just too big a gap there. I feel like we’ve lost something in that respect. At USENIX, we struggled with this for a long time. But, I do feel that we’ve lost something by that separation.

A: How do you think we can bridge this separation?

M: That’s a hard problem. SIGMOD has a big industry presence too. But, I think the onus is mostly on academics. Most academics feel that whatever industry does is not sufficiently novel. In program committees, when you have industry papers that might take a dozen different known ideas that have been put together in a really interesting way, the papers never got in. Now, sometimes they do, if in fact they can demonstrate that they’ve had ten million users. But, more broadly, I think it gets down to the question of what counts as research.

I feel like we’ve gotten a little bit narrow in what we think counts as research in a way that excludes people who are building interesting products. We spent a lot of time at USENIX trying to fix this and reproduce what we viewed as the success in the FAST community or the other conferences that encourage industrial interaction. But, it is unclear what the right approach is to solve this problem.

A: What is it like being a woman in the academic systems community?

M: In many ways, I feel lucky in that it never occurred to me until I was fairly senior that it was a problem being a woman in CS or a woman in systems. I partially attribute this to my upbringing. We have this joke in my family. My two older brothers were both second in their class in high school being beaten by the “smart girl”.

I grew up *knowing* that girls are smarter than boys and that I had to be the smart girl because our family had lost twice.

It was not a question. It was not a goal. It was just the truth. It had never occurred to me that there was a gender problem, which in retrospect I feel really lucky about.

When I got to college, there weren’t that many women in CS, but I didn’t notice that because I’d always been a tomboy. I hung out with the boys. In fact, when one of my teaching fellows said, “You know, every time I try to talk to you, you’re surrounded by a bunch of guys”, I was like, “Yeah, they’re my classmates. What’s the problem?” So, I proceeded mostly obliviously. In fact, I remember when I got to grad school, there was a special group for women in computer science and engineering, and I was like, “Why?!”  I was happy that they gave us free food once a month, but I literally couldn’t figure out why we had this group.

I was taking a standard grad theory course and walked out of it one day and turned to my office and said, “Wow, there are a lot of women in that class”. My office mate looked at me and asked, “How many? Six?” I said, “But, that’s 20% of the class because there are 30 people in that class”. He was like, “Is that a lot?” I responded that I was taking the operating systems class that just had two women (including me) of 90. That’s when I noticed the discrepancy in the numbers.

As a junior faculty member, I would attend gatherings where senior women faculty would tell the junior women what tenure was about and how things worked. I would immediately share these strategies with my male colleagues. To me, “I was getting all this good info while they weren’t”. Long story short, I was clueless for a really long time in a very privileged way. Then, as I became senior and started to see things happen to my junior colleagues, it didn’t seem quite right. That’s when it really struck me and I was like, “Oh my God! We have a problem!” [slaps forehead].  I then started looking back at things that had happened to me in hindsight and realizing that they wouldn’t have happened to me if I had been a man. 

I vividly remember this incident that happened during my first job outside of college. This was back in the day, before companies fed you twelve meals a day; they would typically just have a big coffee maker. The coffee was usually pretty horrible, so a bunch of us got together and bought a little Mister coffee pot to have our own coffee. A new guy joined the company, and we invited him to join our coffee circle. One day, he sticks his head in my office and says, “Oh, we’re out of cream”. And I reply, “Oh, I do the coffee, Alan does the cream”. He comes back later in the day and says “Oh, we’re out of cream”. I was thinking, “We just had this conversation!” I say, “I do the coffee, Alan does the cream”. He said, “Well, how can I bother him with that?” [?!!!]. I was stunned … “You just bothered me twice!” I didn’t think much more about it. Later that day, I was walking down the hall and he was coming the other way. He said, “Oh, could you get me a cup of coffee?” I looked at him, turned around, walked into my manager’s room, told him what happened, and told him to make it stop. The good news is that they did make it stop (even though this was back in 1984). Somebody actually sat down and talked to him and said, “You’re not allowed to do this”. I took a couple of things away from this experience. One, you have to speak up even if it’s stupid and small and just a cup of coffee.

You’ve got to speak up, because if you don’t speak up about the little things, such as the coffee, it’ll then be about the project and who is running it. It snowballs from there. 

Whether you are the person who’s being mistreated or you see somebody else who is, you have to speak up. If you’re the person being spoken to, then you darn well better do something about it.

It’s as much a part of your job as writing the next line of code.

I feel fortunate that the person who was my manager did the right thing. They sat him down and said, “Dude, you’re being a jerk. Don’t do that”. And this experience pales in comparison to, “Well, if you want the next promotion, you’re sleeping with me” (which also happens).

As I started seeing these things happen to junior people, I was suddenly like “Oh no, no, not on my watch!” One of the things that upset me the most in my last couple of years at Harvard was when I learned that the spouse of one of my students had been sexually harassed while she was a graduate student. From my perspective, this happened under my watch. It wasn’t anybody in my department. I didn’t know the person either, but as a faculty member, that was under my watch. I took that personally. I had a responsibility. I wish everyone took these things personally.

I’ve had black students who face a whole set of other issues. As a community, I feel like we don’t talk about these systemic issues as much as we should. We pretend like their experience is the same as ours, but it’s not. Not one of my white colleagues has ever been stopped by the police because they happened to be in the wrong part of town at the wrong time. My black colleagues have. I am a woman and underrepresented in this field, but there are lots of other ways where I am totally included and feel comfortable.

I’ve started to realize what a privilege that is and how much I take it for granted. When I look at my diverse group of students, I wonder, “Do they actually feel included here? Do they feel like they belong?” That’s important to me: that they feel like they belong in our lab. I think we’ve created an environment where everybody feels like they belong, but I wonder whether they feel like they belong in the department, or the university, or the city? I don’t know. And the fact that I’ve never had that conversation, that’s on me.  We live in interesting times, and I’m trying to take advantage of that and figure out how I can do better. So many of the students I work with are marginalized in one way, shape or form, whether it’s by their gender, sexual orientation, socioeconomic status, or race. I think we need to be more cognizant of that. 

A: I have personally seen how you consciously make an effort to create an inclusive space for everyone in the lab. What advice do you have for someone who is starting a lab of their own and wants to establish a good lab culture?

M: I want to give credit where credit is due. Radhika Nagpal, who was my colleague for the last 15 years at Harvard, single-handedly did more towards helping me understand the importance of establishing good lab culture than anyone or anything else. She is someone who talks the talk and walks the walk. Her lab is both extraordinarily successful and extraordinarily inclusive and supportive. So, in large part, I watched what she did, and I stole her ideas on how to make my lab an inclusive environment.  

There are two other people in my former department, Harry Lewis and Barbara Grosz, who would never turn away a student who was facing a challenge. So, it never occurred to me that you could be any other way. As one of the grown-ups in the room [as an aside, says, “although I hesitate to use that word”], you have to be willing to go to bat for your students when something is wrong. I actually wrote a blog post about this. What is the responsibility you have towards your students? If you’re not going to go to bat for them, why are you in academia?

In my mind, that is the minimum bar: your job is to advocate for your students. 

At UBC, I am responsible for building a big systems group. So, I want to be extremely thoughtful about creating a good culture. I stole a bunch of ideas from Radhika and spent a lot of time thinking about these things on my own. I volunteered to serve on our committee on diversity and equity. I learned a ton from the queer support group on campus. I remember the day when they came into my office and we were talking, and I confessed that I didn’t think I’d have to put my pronouns on my website because it’s obvious what my pronouns are. As I was saying it, I realized that my speech was coming from a position of privilege. I ended up putting my pronouns on my website. Just realizing the fact that “I’m a part of the norm,” makes it harder for someone who doesn’t want to be called “she/her”. I learned a lot from my students. 

I try to listen and stay on top of things. We have had incidents in the past where people have behaved in a way that made other students uncomfortable. When I know that, I take action. It’s not about telling them that they’re bad people. But, just making them realize that we don’t do this here. Those are definitely hard conversations.

I would like to shy away from them just like anybody else, but I realize that I cannot because it would directly be in conflict with my responsibilities as a professor.

If you’re uncomfortable having the whole conversation, I’d simply speak to the student in question and let them know that “We don’t do this here”—this simple phrase can go a long way. 

A: What would you be doing for a living if you weren’t in CS?

M: A soccer player. Assuming I had the talent. I am a huge fan of the US women’s national team and I’m now a huge fan of the Canadian team. I had been rooting for Christine Sinclair to break Abby Wambach’s goal scoring record for a year and a half!

A: Thank you so much, it was wonderful chatting with you!

M: Nice talking to you too!

Bio: Akshitha Sriraman is a PhD candidate in Computer Science and Engineering at the University of Michigan. Her dissertation research is on the topic of enabling hyperscale web services. Specifically, her work bridges computer architecture and software systems and demonstrates the importance of that bridge in improving the performance, cost, and energy efficiency of modern hyperscale data centers. Sriraman has been recognized with a Facebook Fellowship (Distributed Systems), a Rackham Merit Ph.D. Fellowship, and was selected for the Rising Stars in EECS workshop. She hopes to enter academia after her PhD program, and will be on the academic job market (for tenure-track faculty positions) this upcoming cycle.

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.