Talking Postgres with Claire Giordano

CLAIRE: 00:00:06
Welcome to Talking Postgres. I'm your host, Claire Giordano. And in this podcast, we explore the human side of Postgres, databases, and open source, which means why do people who work with Postgres do what they do and how did they get there? Thank you to the team at Microsoft for sponsoring this conversation about Postgres. And now it's time to introduce our guest, Bruce Momjian. Bruce is co-founder and core team member of the PostgreSQL Global Development Group. He's worked on Postgres since 1996, is employed at EDB, based in Philadelphia in the United States, and is probably one of the most prolific Postgres conference speakers on the planet. He's earned a master's degree in education and has an honorary doctorate as well. Welcome, Bruce.

BRUCE: 00:00:55
Hello!

CLAIRE: 00:00:56
So glad you're here. So glad you said yes. Today's topic is open source leadership. And the inspiration for this came from PGConf India, which happened in Bengaluru back in early March of this year, when you and I were chatting about what would make for a good podcast episode. And you suggested open source leadership, and we're going to dig into why in just a little bit. But first, I wanted to start with your origin story. Can you give us the story behind how you first got involved with Postgres?

BRUCE: 00:01:30
Sure. I was an early user of Unix back in the early 90s. I actually had a home Unix server, which was at that time very rare. And of course, at that time, there was very little software available for it. So most everything you ran was open source, compiled it yourself. And I was a consultant in law firms at that time. I was using relational databases for my work, and I was always curious how the internals of those databases worked. So over the next few years, in the early 90s, I believe I actually tried to write two relational databases from scratch. Got into trouble with bootstrapping and basically gave up. But in 1996, I downloaded something called mSQL out of Australia at the time. It was kind of primitive, and it wasn't really like the relational systems I used. But then I downloaded Postgres, and that was much closer. I was very familiar with Ingres, and Postgres obviously had a similar interface. And Informix as well, and Postgres had similar features to Informix. So I was able to look at how a relational system worked. And I realized that this had potential, software potential, but it really lacked leadership. It lacked management. There was one person working on it part-time and they really weren't putting out regular releases. So I decided I was going to kind of help out, kind of gather some of the old patches and help put out a release. Marc Fournier was hugely involved at that point. I did all the infrastructure and kind of managed everything. So that's how I got started. And I just found out that as I worked with more and more people in the community, I was learning really valuable skills as an engineer. So I thought maybe, you know, maybe someday this the skills I'm learning will be useful. Not really realizing that Postgres itself would become what it is today. But that's how I got started. And I was a volunteer for the first four years of our three years. And I wrote a book and I've been working since 2000 full time on Postgres.

CLAIRE: 00:03:50
What was that book? Remind me.

BRUCE: 00:03:52
PostgreSQL: Introduction and Concepts by Addison-Wesley.

CLAIRE: 00:03:56
Okay. And then is the writing of that book what prompted you to then kind of travel around the world and give talks and give people that introduction to Postgres? I'm remembering that Daniel Gustafsson was a guest on this show back in January. And he talked about how he was at a conference in, I think it was in Sweden. No, but it could have been in Copenhagen. And you were [Copenhagen, yeah.] giving a Postgres introduction session. And he just, by happenstance, ended up attending. And that was the moment his life changed. So was the book connected to this?

BRUCE: 00:04:36
No, the book, what I basically realized early on was that, two things really. I was a good engineer in my field, but once I got on the world stage where I was working with the best people in the world, you start to look pretty small and you feel pretty small. So what I started to realize is that the smart move was not to work hard, but to enable other people to work. So, you know, if I can get 10 people to do one thing a day, I get 10 things done instead of one thing, which is what I would normally do if I was doing it myself. So enablement of coding, enablement, getting people excited about technology, creating a framework where people felt valued and that they felt their contribution was helping others and promoting open source. I saw that as a much richer goal and a more fruitful goal than sort of working myself on the technology completely. So I started to basically work in the early years on FAQs and making the code easy to understand and trying to help create materials so other people could get used to the Postgres code and could improve the Postgres code as easy as possible. One of the stories I say is that if you're working for a company, you have to work on the code. You don't have a choice, right? But with open source, you really do have a choice because they're all volunteers. So you have to make it as easy as possible. So that was, I guess, one of my primary goals. The other thing I realized early on, probably in 2001 or 2000, I went to a conference in San Diego. It was the O'Reilly Open Source Conference, OSCON. And I went there and I spoke to maybe 40 people and had lunch and, you know, it was nice. And I flew home and I told my wife, I said, I said, I don't think I'm going to do this again. It just really wasn't very fruitful. And I basically, you know, talked to a small number of people. When I sent an email out, you know, thousands of people will read it. But at this conference, it just doesn't seem like a very useful investment of time. But the week or two after the conference, all of a sudden our community was much more active. We had a much smaller community back then. And what I realized was that it was people I had lunch with at the conference that were now active in the community. And I started to understand that the personal touch of spending time with people and having lunch with them is actually a really key part of motivating. And email only can go so far. Zoom calls only go so far. We saw that during COVID. The in-person part is very important. And that's why that travel became pretty significant for me.

CLAIRE: 00:07:52
You know leading up to the show and if we go back to our conversation at PGConf India you talked to me about the different types of leaders and a couple things you just said about enabling other people really connect to that. So I don't want to take away your thunder. Tell us more. Tell us more about the different types of leaders and what kind of leadership you think is so important in an open source community.

BRUCE: 00:08:21
Yeah, I've always been a sort of self-taught person. Not that I can't operate in a classroom, but I was a teacher for five years, obviously, but I've never had any real formal computer science training, and I've never had any formal leadership training either, but I mean, I read the right books, and I listen to the right people, and after a while, you become good at it, and one of the, one of the leadership talks I listened to must have been 15 years ago, Obviously, leadership is a very complicated topic, something, again, I have no real training on. But I realized that I had to understand it or at least become marginally good at it. Because that's, in some ways, the role that I'm in. Or at least if I'm going to be successful and I'm going to be the best person in the role I'm in, I have to do some self-help for that. So I listened to a bunch of training materials. There's one or two online conferences I attend every year for leadership. And one of them had a speaker named John Maxwell, and he talked about the different types of leaders. And I started to understand that there are different types of leaders. There's this sort of Steve Jobs leader, which is very inspirational. There's a Jack Welch, who's my organizational. There's sort of Oprah, who's motivational. And they categorize them into different sections. And John Maxwell basically felt that the servant leader is the most effective. And you see that a lot in the hospitality industry, particularly Marriott, had a big sort of servant leader style. And particularly, it's big in industries where you have a lot of your staff interacting directly with the public or with customers, right? Like for Steve Jobs or Apple, their primary purpose is not serving customers, it's producing a product, right? So you don't need necessarily servant leadership in that case. But for a Marriott case, obviously, most of the staff is directly interacting with customers and they have to serve the customer. And the concept is that you can't expect your employees to serve the customer unless the leadership is also serving the staff. And that kind of resonated with me because when you're effectively operating in a nonprofit environment, a volunteer-only environment, which is the environment we're in, servant leader is really the only effective way to be a leader because you don't have any of the organizational structures like salaries, positions, and so forth that are normal trappings or normal mechanisms for leadership. You basically have the ability to serve, the ability to help the people that are working with you on this project to be most effective and to help them harness their strengths as best they can. And also in some ways to help them avoid weaknesses, help them to either overcome weaknesses or help them to be put in positions where their strengths are magnified and their weaknesses are minimized. So that concept made sense to me and I started to understand that every leader isn't different, every leader has a different, necessarily, set of mechanisms that they can use to be leaders. But probably the most effective leaders, the leaders who get the most out of the people they work with are the servant leaders who are not really interested in their own success, but interested in the success of the overall endeavor that they're in. And is interested in the success of the people that are working with them and not necessarily in their own success. I think it was Truman who said, "it's amazing what you can get done if you don't want credit for it." And that's certainly a servant leader style of doing things. And it helped to, I guess, for me, sort of separate out and to sort of highlight, identify, first what type of leader you want to be. And then that sort of drives how you make decisions and how you spend your time.

CLAIRE: 00:12:49
You would definitely categorize yourself as a servant leader, right?

BRUCE: 00:12:54
I would hope so

CLAIRE: 00:12:55
Yeah, I think it's a fair depiction. The other thing that happened in PGConf India is you told me about a talk, which I didn't know you gave. I don't think I was there that year. And it was at FOSDEM in 2023. And at FOSDEM every year, the Postgres community does this really cool thing, as you know, because you've spoken there a bunch of times. We have a PGDay, a whole day, single track of Postgres talks the day before FOSDEM begins. And then at FOSDEM, which is in Belgium, usually late January, early February every year, big open source developer conference. There's also a PostgreSQL devroom, which is another track of Postgres talks. But this talk that you gave was called Building Open Source Teams. And I think it was on one of the other stages or one of, was it on the main stage or one of the other devrooms at FOSDEM in 2023?

BRUCE: 00:13:50
They basically have a lot of these devrooms, they have an open source leadership track and it was in that track that I spoke. Actually one of the people really well who used to work at OSCON as one of the organizers so I always pop over there even when I was there last year, I popped or this year actually I popped over to see how they're doing.

CLAIRE: 00:14:09
Is that Shirley?

BRUCE: 00:14:10
Shirley, yeah, to see how they're doing and just to you know catch up because I don't see them anymore except at FOSDEM. And I guess they just picked the... I submitted it because I do have some more general talks that are not database specific. And that's one of them. I have given that talk a couple places, but again, it's ideal for open source leaders. And again, it's sort of an open ended talk, where I explain what I've learned, you know, having done this for so long. And again, the goal is to help other leaders to be more successful.

CLAIRE: 00:14:49
I really enjoyed it. It's about a half hour long for anyone who wants to go listen to it. But you cover a lot of ground in it. And I think you do mention servant leadership in that talk. So it kind of gave me a little bit more background beyond what you just spoke about. you covered like understanding open source motivations, and the OSCON 2003 story as well, [Mm-hmm.] right? Where you felt like it wasn't a good use of time. And then you found out that, oh, it was a good use of time. And that those lunchtime conversations really influenced people and, you know, motivated them to get involved. So my favorite bit though, is you talked about gratitude. I think you even went on a rant at one point. You're like, it does not cost you anything to show appreciation to people. Do you want to?

BRUCE: 00:15:44
Yeah, that I remember, I do remember. That talk is kind of, it goes in different directions depending on who the audience is now, what what things are sort of going through my head at the time, but but the specific thing was that, and I guess it gets back to the idea of not taking credit. So if your motivation is to help people feel valued and show them that what they've done has made a difference and obviously show gratitude to them, that's a zero cost thing to do. In some ways, it's humbling for you to do it because you're highlighting someone else. And I think some people chafe at that or they feel like they're demeaning themselves by highlighting other people, but effectively it is an incredibly good motivator. And, you know, not only in open source leadership, but, you know, in general, in life, in leading your family, leading whatever you're doing, whoever you're working with, showing that what they have done makes a difference in appreciating that. Yeah, it's a huge thing because in a lot of everyone knows in a lot of the things you do, nobody, nobody cares. You know, you don't get a pat on the back. You just continue doing it and you do it and you do it because you think you have to do it. But if somebody comes along and shows gratitude for that, it's an incredibly big motivator because we don't get a lot of positive feedback in a lot of the work that we do. So, you know, I think we've done a pretty good job at that as a community. You know, we can always do better. But again, yeah, it does not cost anything just to come up to somebody and say, hey, you know, that thing you did or that email you sent. Or sometimes I'll just see an email that just really motivates me or gets me excited. And I'll just personally reply to that person. I'll say, hey, off list, that was an amazing email. I really, you really, you know, I learned some things from it. Or you really were able to crystallize the problem that we're talking about in a very effective way. Or I thank you for submitting this patch, or applying this patch, or answering this person's question that frankly I never would have been able to answer. And those type of things really do help. And a lot of people I think overlook the power of that.

CLAIRE: 00:18:15
Well, I know from personal experience and relating to this podcast specifically, when I was at PGConf India, I met an engineer from Fujitsu who she told me that this podcast inspired her. And she didn't just use those words as platitudes. Then she specifically told me why. And she named particular episodes. And oh, my gosh, like I danced a jig when I got back to my room that night. [Yeah.] And then I went and I gave a talk in one of the local Microsoft offices in Bengaluru. And afterwards, I got a chat message from Rahila Syed, who is a Postgres contributor, someone who's working on the codebase itself. And she wanted to reiterate how she felt about this podcast. And it just made my day because part of why we create it, like Aaron and I spend time on this because we want to take conversations with people like you and make them available more broadly so that maybe tomorrow's future committer, tomorrow's future Postgres contributor, might be listening to the show and might get inspired by it and might be motivated to go check out the project. And kind of like you, you said you had lunch with a bunch of people at OSCON in 2003. And then you were blown away the next week when they started to work on Postgres. Is that, am I remembering that right?

BRUCE: 00:19:42
Yeah, I don't even know if they came to my talk, honestly. I know I had lunch with them, but I don't remember if they were even in the audience. Yeah, and again, Daniel Gustafsson is an interesting case because I don't remember talking to him at the conference in Copenhagen at all. It was in a very unusual venue, but yeah, you just don't know. You don't know what thing is going to hit. You don't know what impact something's going to have. You know, a lot of times, you know, having started with Postgres and even getting some pushback in my family when I was spending so much volunteer time the first couple of years. You know, I tell people, you know, sometimes, you know, a day is important. You know, you graduate from college, you get married, you know, those are big days. But there are other days you make a decision and you don't really know that it's going to be a big day, and it is. So I guess the issue is that you just don't know who you're talking to or whether that the person you're talking to is going to be impacted by what you're saying or not. I just got back from Hong Kong last week and we had a whole bunch of conversations, unrelated to Postgres, unrelated to technology, but just life lessons, things that I've experienced and so forth. Then I got some feedback from some of the people said, you know, that really impacted me. It was a story about some things that I learned when I was a kid and some experiences I had helping somebody once. And yeah, it just, you just don't know. So sometimes I guess that's very similar to what happened when I did the FOSDEM talk. You know, sometimes you have some slides you get up and you just start talking from the heart. You don't really know what's going to happen. You don't, you know, you can plan some of it and you want to be prepared and so forth. But a lot of, a lot, I think of the success is not planning, is being ready to stop and talk to somebody, you know, just because you talk. I mean, I had a case probably 15 years ago. I was at conference in New York and I decided I wasn't going to attend any talks for, for various reasons. And I just kind of hung out in the lobby the whole time or the conference, you know, space. And what I realized that in a lot of ways, I was more effective doing that than sitting and listening to talks. So what I've done now when I used to do conferences, I attend very few talks and usually spend most of my time out in the lobby or out in the public spaces talking to people. And that's probably a more effective use of my time than listening to talks, which I'd like to listen to, but this is not about me. This is about what is going to be most effective.

CLAIRE: 00:22:41
So for any of you who do go to a Postgres conference after you listen to this episode anytime in the next year, or two, or three, if you see a man in a bow tie with a big a big head of white hair that's probably Bruce Momjian. Which is not to say other people can't wear bow ties too, but typically you are the only person wearing a bow tie at Postgres conferences, so it's kind of like your signature look. Sometimes people give you feedback even saying "Bruce where's your bow tie? I want to take a picture of you, but you have to to have a bow tie on."

BRUCE: 00:23:11
Yeah, I get beaten up if I don't wear it once in a while.

CLAIRE: 00:23:20
Exactly. So anyway, but it's interesting that I see you, you are in the hallway a lot available to people, accessible to people. And you'll pose for selfies with people, you'll talk to anybody and everybody. And, and obviously, that's a very conscious choice on your part, right? That's part of how you're going to be a servant leader, part of how you're going to relationships with people in the Postgres community. Am I right?

BRUCE: 00:23:46
Yeah, you know I had a weird case, it is funny this is bringing up memories, I had a case I was flying probably two years ago I was flying from Israel to Berlin between two conferences and I was watching Wuthering Heights, it's a movie, and it was probably the old version back done in the like 30s or something. And it's about a woman who has a choice between different suitors and can't really decide, and eventually ends up kind of destroying both of them in a way, at least that was my interpretation of it, and what it actually coalesced was the concept that this protagonist woman could not really decide what she wanted and therefore was just kind of vacillating between two people and it caused a great deal of harm I got off the plane in Berlin I called my wife I said yeah I'm really down, she said "why?", I was like because usually I'm pretty up on these things and she said you know I said I watched this movie and I realized that I'm you know I'm flying between these two cities I'm doing all this stuff and I don't know if I like doing that? Like, I've been doing it for so long. I know people enjoy me doing it, and people appreciate me doing it, but do I really enjoy doing it? And I don't know. I've actually, this is like maybe a problem with being a husband and father. You kind of just do things, and you're not really thinking, probably true of a wife as well. You just do stuff, And you don't even know if you like it or not. It's just your responsibility to do it, right? I just found that depressing because not only didn't I know, I couldn't even decide if I liked it or not. Traveling, doing speaking. A classic case, during COVID, my wife, I was obviously home. I'm usually traveling 90 days a year and I was home for two years or whatever. And she said, you know, you must miss speaking to audiences and going to con. And I said, you know, actually, I don't. I don't miss it. It isn't something I feel like. I just, I don't miss it. And I guess that, I guess, hit home. This was actually around the same time, I guess, same year that I was doing this trip. And I started to realize that, you know, here I hadn't been doing this thing that I had been doing for forever. And I did I miss it? And I realized I didn't, you know, so I don't really enjoy doing that. Do I? I don't know. I do what I need to do. I do what people expect me to do. And I do what, what I'm good at, right? But is that something I enjoy doing? Yeah, there's a lot of aspects I do enjoy. I came back from Hong Kong last last week and I just felt very energized. But it's hard. You know, it's a lot. It's difficult. There's a lot of uncertainty to doing this. But yeah, I think I enjoy it. But it doesn't define me. I would say it's not something that there are certain people who just like that limelight and like getting up and speaking and they like sort of being the guy or whatever. And I just, I guess that's not a motivator for me. I guess there's other things that motivate me to do it, but it's not, it's not necessarily something that, that speaks to me, I think in a fundamental way. That's a weird answer, but.

CLAIRE: 00:27:39
One of the things that I've observed about you with myself, but I've seen it with other people as well, is that you do in the hallway tracks in these conferences, you do a really good job making whoever you're talking to feel like the most important person in the room. You really are paying attention to the person you're talking to in the hallway, to the person you're meeting. And like you said, you don't know, are they going to end up being more involved in Postgres? You know, are you going to end up talking to them and getting to know them even better or not? But you really give kind of of yourself as you get to know people in the hallway track in these conferences. And I think it's really generous and motivating. I mean, as evidenced by all the people I saw taking selfies with you at PGConf India, who were really excited to have met you. So I don't know. I want to thank you for that. It must be exhausting, though, I get it. You probably go back to your room and you just need to take a deep breath and kind of recover because you're giving so much to everybody else.

BRUCE: 00:28:51
Yeah, there's two funny stories of that. One, I told EDB this because they do a blog. They try and do a blog every time I travel. And actually, if you go on my website under India, you can see the travel report. In that travel report, it actually mentions what I told EDB staff. I guess it was around lunchtime, and I was talking to somebody about, I think they were having actually database corruption issues, believe it or not. I think it was related to the SSDs not being crash safe. I was going through whatever details, and we were talking about a whole bunch of other stuff. We finished talking, and obviously I was in that lobby area in front of it. And I look around and the door to the conference room is open and there's no one in there. And I'm looking around and there's nobody. And I'm like, where did everyone go? Like, I can't figure out. Initially, I'm trying to think of where everyone went because the day before lunch was served in the place we were talking. So I assumed that we were going to eat. And I'm like, did everyone leave? Is the conference over? Like, did everyone go out to eat? I couldn't figure it out. I asked somebody. And they said, oh, everyone went upstairs to eat. And that's why there's nobody there. But again, I guess I was so oblivious to what was going on that I never even realized that, you know, basically everyone had sort of flown the coop. And, you know, oh, yeah, that was kind of a weird, you know, sort of a weird experience where I had no idea. But, yeah, I mean, focusing on people, you know, I was I think as a kid, I had trouble clearing my thoughts and sort of being focused on things. But in my 20s, I started to realize that that's a poor behavior. And I need to be, I need to focus not on the future, but on right now, you know, being present, as they say, is what I'm saying. So, you know, I think it's important to kind of focus that way. And the other story I was going to tell you, in terms of being tired, I will say, admit, that in the morning, I don't know how many people travel with me, but I get to bed pretty early on a conference day. I try to be in the hotel by 9.30-9:00pm, and I try to get to bed by 10:00pm so I can get up at 7:00-7.30pm, kind of, you know, just decompress a little bit before I have to be downstairs, which usually around 8:00-8.30pm. But I will admit that when I put my hand on the hotel, my hotel room door to leave, I sort of pause sometimes because I realize as soon as I open that door, you know, I'm on. Right. And I might not make it down the elevator without sort of, you know, getting a chance to talk to people. And that's going to go until I come back to that room. So I have to be very disciplined about not staying out too late, not trying to do too much when I'm at these events. So that's typically the reason that you will not usually see me. I typically will not go out to eat past 8:00pm or 7:30pm at night. And I will usually leave a dinner around 9:00pm or 8:30pm just to get back to the room. And I miss stuff. I miss hanging out. I miss whatever people were talking about from 9:00pm to 11:00pm, which is typically when people are out. But that's, I have to accept that. I have to accept that I'm not going to be able to go. And some of my trips are, you know, two, three weeks long. I would run out of steam very quickly if I was to stay out late every night and then try and do a good job the next day over and over again. I would be, I'd be a mess.

CLAIRE: 00:33:10
You're like a cell phone. You need to be recharged every night.

BRUCE: 00:33:12
I need to be reached, I was in Yekaterinburg, on a I guess a 20 some day trip and it was day 16 and I'm having dinner and somebody looks up at me and they said they said "you look fine," and I'm like "what, should I not look fine, is there something I should know?" They said well, this is day 16 for you. We assumed that you would kind of not be sharp anymore because usually when people travel that number of days, every day that you get a little less sleep, it catches up with you. I even see it at four day conferences. By day four, a lot of our people are not as sharp as they were on day one, particularly because they haven't gone to bed early and they haven't sort of paced themselves. So yeah, usually I'm pretty much the same on the last day of a trip as the first day but that's only because I've unfortunately had to not stay out and had to go back you know even if dessert hasn't been served sometimes I gotta leave, you know, and just go back and and be ready for the next day.

CLAIRE: 00:34:28
I am thinking that there was a talk at FOSDEM. I think it was by Chris Travers, and it was about the importance of sleep. And it wasn't in the context of someone like you, who is a leader in the Postgres community, meeting with people at conferences, or in the case of EDB, meeting with your customers. It was in the context of DBAs and people who are maintaining Postgres databases. But it was really interesting, because at the end of the day, some of the research shows that people who do work sleep deprived, who do work that is critical to human life, like they shouldn't be doing that work sleep deprived. And he talked about medicine and rail operators and airlines all doing research on the importance of sleep.

BRUCE: 00:35:21
That's funny you say that, yeah, because when I was a consultant I worked on a lot of live systems so I would be live moving their relational data around while the app with all the people were working during the day, and you know sometimes people get a little nervous and I'd basically tell them I said the only time I make mistakes is when I'm tired or rushed I said if I'm not tired or rushed your data is fine. Because I historically, even back then, knew that when I'm rushed I take shortcuts and when I take shortcuts that's when the mistakes happen or if I'm not well rested then I'm not thinking clearly I'm not sharp and that's also when mistakes happen so that kind of matches what you were saying.

CLAIRE: 00:36:13
So let's circle back for a second to the topic for this episode today, which is open source leadership. We talked a bit about gratitude and how important that is, particularly when people are volunteering to work on a project, right? When there's choice. And I couldn't agree with your philosophy more in that space. And then you talked about servant leadership as the style of leadership that you believe is so effective and that you've chosen to adopt. Is there more that we should explore when it comes to leading open source teams, building open source teams?

BRUCE: 00:36:51
Well, you know, I think it was Tolstoy who said all healthy families are the same, and all dysfunctional families are dysfunctional in different ways. And I think that applies to open source projects as well. So there are open source projects that I will not specifically mention that I would argue do not follow some of these guidelines. And it becomes sort of a dysfunctional family that either the leadership is overbearing or not encouraging new people or arbitrary or selfish. There's a bunch of things. There's so many ways leadership can go wrong. and I think that it's sort of like you know how do you stay on a tightrope, well you know you have to you have to sort of do everything right if you do one thing wrong you're going to fall, and that's I think one of the one of the challenges a lot of people, who are leading projects, you really have to be willing to, A, be humble enough to seek help and to get advice, and to understand where your limitations are and what things you can't do and can do. You know, we just talked about the fact I can't stay out late at night, right? I mean, I can't. There's a lot of things that I can't do. And there's some things that I'm doing that I'm not even sure if I like doing, but I'm doing them because I know they're important to the project. I know that people need, they need to be done. And I'm probably a good person to do that. I'm not sure I'm a natural public speaker, I just got good at it. I was a high school teacher for five years. That helped me to think on my feet, to speak and talk at the same time, to look at the audience as... to understand, to put myself in the audience's shoes because I would give the same lecture all the time but for that audience it was brand new, so that's what motivated me but yeah, I think a lot of people, my personal opinion is a lot of people want to do leadership the way they want to do leadership. And that's not good because what you want to do is you want to do leadership the way people need you to do leadership, not the way you want to do it. And a lot of people will sort of put their stick in the mud or whatever and say, I'm not going to move and I'm going to do it this way, whether people like it or not. And those are going to be unhealthy. Those are going to be, those projects are not going to be what they could be and what they can be. I think the other surprising thing that I've noticed is how much the way leadership does things permeates down to the organization. We have no control pretty much over anybody who does anything almost in the project. But if you have a servant leader examples and your leadership is interested in the project's health and not in their own reputation or success or selfish reasons, then that permeates down through the organization very well, very quickly. And I would argue that if you have leadership that's very selfish or very strong, you know, strong-willed or arrogant or, you know, the whole pathologies that leadership can have, those also permeate down very quickly into the organization. So I didn't realize, I guess, how much the style of the leaders really does go down through the organization in a way that I didn't anticipate that. I can understand it may be happening more in a company where everyone's being paid and therefore people have a motivation to try and fit in to the leadership that is paying them. But we're not paying anybody. So why would people do that? I think a lot of it is the servant leadership in a lot of ways resonates with the way people really want to be treated. And I think it resonates much better than other leadership styles because it is a very caring and a very considerate way of doing things. And that surprisingly permeates down in a manner that's much more efficient than I would have guessed.

CLAIRE: 00:42:05
I know that a few other people who are also PostgreSQL major contributors, even members of the core team, have talked about how they've had to change their email style over time to bridge cultural and geographic and time zone distances between people. Because as you communicate with others in the community, even if you have the best of intentions, even if you have, you are not selfish, right? You share the same values. You're focused on the people on the team as well as the technology, right? The technology that we know users rely on for their businesses and for their products. Even with all those good intentions, there can be like misunderstandings very easily in email. Email is a tough medium, but it's the medium for Postgres. So other people have had to like really focus on how do I make sure my email comes across right, lands with the right almost tone of voice, right? Is that something you've ever had to focus on or did it always come naturally to you?

BRUCE: 00:43:20
For me, I've been doing that type of email since the early 90s, so it wasn't that hard. I think for me, the biggest struggle is, personally, is trying not to be frustrated when somebody points out my flaws. So when you work on a patch for weeks and then you finally post it and then somebody, in the first hour, from Brazil finds a mistake, and then the next hour somebody else finds a mistake, and you just keep getting battered over and over again. You think you've spent a huge amount of time. How can there be all these mistakes? But you have to admit that they are. And your initial reaction is, no, they're not wrong. I mean, your initial reaction is that they're not mistakes. Like, that's just, you just want to think that, right? But A, objectively, they probably are mistakes. And B, those other people, even if they're not absolutely correct, have some level of truth to what they're saying. There is some value in almost every opinion that you're getting. So even if you decide that I'm not going to follow that person or I don't agree with that opinion, there's probably something there you can learn to improve your patch or to improve your slides or to improve the way you're handling a particular situation. And that is not something for me that I'm naturally good at Because you're just battered. You're trying to help this project. And you've worked on this thing for weeks. And then you just get pummeled. At least that's what it feels like to me when the flaws of what I'm doing are pointed out. But you have to step back and say that the overall health of the project and health of the patch I'm working on, health of the slides, or the effectiveness of the slides, it really relies on me taking that criticism seriously and objectively and trying to understand what I can do to make that other person happy or at least satisfied that they've been listened to and to try and glean any kind of learning I can get out of that. And that is not something that most people are going to want to do. I've often talked to large groups And I'm like there's only 5% Of people who really want to do open source. Because 95% of people, they just want a paycheck and they want to go home. And they don't want to deal with other people criticizing what they've done, and having to pick apart a whole bunch of ideas and you just feel like you're inundated with criticism. But if you're objective, you're like, all right, that's part of doing business. This is how we get great software. This is how we get a great database. And I have to be part of that. I got to take it and not feel two inches tall, which is usually how you feel during this.

CLAIRE: 00:46:44
Okay, so I just want to repeat what you just said, because I think it's important. And I don't think it was covered in your, your Building Open Source Teams talk, which I loved, the one you gave at FOSDEM a couple years ago. If I can summarize it correctly, or paraphrase you, and you tell me if I got it right, you're basically saying that it's really important to be open to feedback. If you want to be a good open source leader, you've got to be open to feedback about your own mistakes or oversights or whatever. You can't be Teflon, right? You can't have what everybody says just bounce right off of you. Is that, did I get it right?

BRUCE: 00:47:26
Yeah, although open is a very neutral word, I would almost say you have to be ready to take a beating almost. That's how it feels when you're, to me, when I receive criticism on something I think I've worked on for weeks and I think I've done everything possible to do. And you're like, and you feel like an idiot. Like, oh my goodness, how could I not have seen this mistake, right? How could I not have realized that I'm not doing this thing the best way possible? But when you step back, you realize that the Postgres project, or even a single patch, is not really the product of one person. It's the ideas of dozens of people, effectively, all being merged together. And the patch author, although they may create the initial version, by the time that version is finally applied, a good patch will have the ideas of dozens of people inside. And that makes it much, your name still may be on it as the original author, but you have to admit that the patch would not be of the quality, the high quality it is at the end without those other people.

CLAIRE: 00:48:43
You know, I've always had this concept, this idea that feedback is a gift, because in some organizations, and this is not true with Postgres, but in some organizations, people are sometimes either too busy to give feedback, or they don't want to offend you. And so they kind of, yeah, and it's not necessarily an obvious bug. Maybe it's a bug. Maybe it's not. The feedback kind of feels optional, even if it might be really important. And so they don't give it to you because they don't want to offend. So one tactic I've seen people use is to focus everyone on a shared goal and say, look, we want to find problems with this idea, with this patch, with this fix before our customers do. So please, if you see anything, say something. But what's cool in Postgres is people already, for the most part, those who are active in the developer community, are like really focused on making sure that next release is the best it can be. And so there's plenty of feedback and you do end up, I'm told, taking a beating.

BRUCE: 00:49:57
Yeah, you know, you can ask for feedback in an organization, but there's so much power dynamics going on in terms of, you know, you're part of a development team. And if I criticize that thing, they're going to criticize this other thing. And what is the, is that going to, is the boss going to see this? And is this going to, you know, is this going to influence hiring or promotions and over there's just so much inefficiency trying to do this in an organization. You can ask for it but in the open source community basically there's no power dynamic at all, like basically anyone can say anything as you know, and because the open source Postgres community is very meritocratic in terms of listening to everyone you know anybody can criticize anybody's project or anybody's basically, a lot of the power problems go away. And it becomes really just a discussion about technology. So I feel bad for people and companies. You can try and do this. I know there's a bunch of different development sort of, or development styles that try and get this criticism concept within, but in most organizations that I'm familiar with, people are just so busy trying to get to the goal line that the type of quality issues that we deal with as a community and the type of continual refinement just doesn't happen. It's just too expensive or the organization doesn't care enough to pay enough people to do that. Or even if they could, they probably don't think they can effectively make it happen because you know the thing that i learned you know I'll write a patch and somebody from Brazil sees one thing, an hour later somebody from Germany, and you know I'll feel like oh my goodness I'm so bad how come these people are finding these problems but in fact I'll realize that they probably couldn't have written the initial patch but they have another skill at seeing a problem that I didn't see, so it's not necessarily that they are, I think the feeling I often have is they must be just better developers than I am because they saw a bug that I didn't see, but that's not necessarily true. They may be better developers than me or not, but they are better at seeing a problem. And again, you may have a thousand people looking at your patch, but it only takes one person to find the problem. So again, I shouldn't feel maybe as bad as I do when I've made mistakes, but it is part of the process. And it's possible that just organizations can't even get teams big enough to find the kind of quality issues that we do as an open source project.

CLAIRE: 00:53:06
There's something that Tristan Partin said on the chat, which is that, you know, everyone struggles with this feeling that they don't like being wrong or imperfect. and I feel it too like you feel it I think a lot of people do no one likes having their faults pointed out to them, do they?

BRUCE: 00:53:28
It's like your brain on a platter, basically. And everyone's poking little sticks at it. That's kind of the way I feel, right?

CLAIRE: 00:53:35
Ouch, ouch, and yet with an eye on the goal it's kind of part of the deal.

BRUCE: 00:53:43
It's got to happen. Yeah.

CLAIRE: 00:53:46
Okay, is there another aspect, and by the way you know I want us to talk about a little bit more about your conference speaking talent and skill and we're going to get there in just a second, [Mmhmm.] but before we do, with regards to open source leadership, we've talked about servant leadership we've talked about gratitude we've talked about quote-unquote being open for feedback which you paraphrased as being ready to take a beating. I know in your FOSDEM talk, you also covered things like how to communicate, meeting people where they are, the value of in-person, the value of building a relationship before you have a conflict to resolve. So there's a lot to this, but is there another whole section that we've missed that we need to cover?

BRUCE: 00:54:36
The other aspect of what you asked a little earlier in you said how do you communicate and those are the things that I struggle with. Now I have had the opportunity to to advise some of our community members in email style over the years and the problems I've seen, they're a little different. So in those cases, it's not so much the beating that bothers them, but just there's a sense of that when somebody disagrees with them, they may have grown up in an environment where somebody's challenging them or making them, maybe they may feel humiliated in some ways. And sometimes that'll come out in email, not necessarily as, oh my goodness, my brain's being beaten, but more of an emotional aspect. And I've tried to work with those people. Usually, hopefully I can talk to them in person or on the phone And sort of walk through why that's happening and help them understand the goal of what we're doing as a project and how the way they're handling this particular email thread is potentially hurting the project. What we don't want is people to emotionally go to an emotional level when they're trying to have a discussion because the person usually that they're emailing does not have any emotion at all. Usually they're trying to make a factual statement, but the reaction would often be one that is not necessarily feeling on a factual level, but is communicating on an emotional level. And that's really where you kind of get in trouble because obviously, as you said, these kind of things can be resolved pretty easily in person. But in email, it just doesn't come across and it gets very confusing. And there's a sense that people don't really understand what's going on. And then the email thread becomes very disjointed. And you're no longer progressing toward a goal anymore. Now it's an emotional exchange, right?

CLAIRE: 00:57:14
[Yeah.]

BRUCE: 00:57:16
And those cases, we really have to, as a leadership, we can ignore those. But effectively, and some projects do, and some projects I would argue probably have leaders who are very emotional in how they react. And that obviously is a big problem. But, you know, one of the things that we've tried to do is, you know, there's a lot of email going around. You know, I have a tendency to read almost all of it. A lot of other people do as well. And we're just looking for cases where people are stressed out. They're acting emotionally. They're getting stuck in behaviors or processes that are not fruitful. And a lot of times, obviously, we'll talk to them privately and try and walk them through how they could handle it differently. Or we may do it in public. We may not necessarily point out the problem, but try and re-steer the conversation back to one that's going to be productive and fruitful toward a goal and not something that's going to get mired in something that's kind of unsavory or unfortunate, not really blessing or benefiting the whole group. And we have very few of those, I'm happy to say, but it's not by accident. We do try. And I know that there's so many other people who try as well. So I know that a lot of times when I see something and I'll talk to somebody, I'll say, oh, yeah, well, I talked to them. And, you know, this is what's going on. And I think, you know, we're going to do better and so forth. So a lot of times showing people that you care, showing that you care about what they're doing, a lot of it is talking to people. You know, we talked about gratitude and I think a lot of people are going to interact with people on a very transactional basis. Like, okay, I'm going to spend time with you because I think you're going to do something to help me in the future. And I've tried to not be that way, that I'm trying when I'm interacting with people to just, I'm happy to be with you. Not because of what you're going to do or what you did for us, but just to be there, to get to know you as a person and to spend time with you. And if that translates into something good, great. If it doesn't, that's okay too. So when we're talking to people at this level, we're trying to do it in a caring way where we're basically saying, we're trying to help you be more, and a better person. We're trying to help you be more effective in this community. And we usually get a positive response, although I'll admit there's a handful of people that did not want to change. Just didn't. We talked to them, we talked to them, we talked to them, different venues in person, on email, on Zoom, and that person really does, they say sometimes when we talk to them that I think I understand what you're saying, you know, but the problem comes back, and then you talk again, the problem comes back, and after a while you have to decide. If that person is in leadership, then that's a serious problem because that person's style is going to permeate the organization. If that person is not in leadership, then there's not a whole lot we can do as a community. But, you know, we just have to, you know, make do. And I guess an extreme, I can't think of any extreme examples where we've actually seriously had to do anything. But that's always, I guess, a potential possibility if somebody was just so abusive that we couldn't. But we try not to get to that point because we're trying to do things early. We try and do things before there's a problem.

CLAIRE: 01:01:26
So I just realized that somebody listening who isn't familiar with the mechanics of how people collaborate in the Postgres database project. The open source project is global. There are people working on Postgres as developers, as contributors, across so many countries on the planet, certainly across all the continents. And in any given release, there's several hundred contributors, usually, who have done something. And that's just in terms of code authorship. There's also all the people doing reviews, right, and helping with testing and translations of error messages. So anyway, global project, people with, most of the communication is in English on the project, but people obviously have different native languages. And so not only are there different personality styles and communication styles, people are coming from different cultural backgrounds that probably have a very fundamental DNA-like influence on how they communicate. And so I think that's a challenge for a global project like this and I should drop a link to the mailing list in the show notes as well, but it's a challenge that for the most part the team has found a way to manage, which isn't to say that it won't get even better in the future but it's tricky. People are tricky. Human beings are complicated.

BRUCE: 01:03:03
Yeah, you know, there was a movement in the 50s to kind of make everything efficient. I don't even remember the name of it, but it was sort of a motion study guy who would try and figure out, okay, what's the most efficient setting or efficient organization structure and so forth? And I think it was Peter Drucker, maybe. And what eventually they realized was--[Taylorism.]--what's this? [Taylorism.] Taylor, yes. Taylorism. Yes. Thank you. Not Drucker. Drucker is another organization. Taylorism. Yeah. But what they really realized after decades was that you can't measure people. It doesn't work. Right? They're just so complicated that to think that you're going to measure, you know, there's things you can measure and there's things you can't measure. And the assumption in a lot of organizations is that something you can't measure isn't important. But in fact, in a lot of ways, the things you can't measure are the most important. So that's right. You can't really come at it and say, well, you know, we're going to do this or that. It's leadership, all these things, all human interaction is incredibly complicated. There is no one, you know, from psychology, there's all sorts of theories about how we process various things and how we react to different things. So they're all helpful, but they're all imperfect because no single theory really addresses the entire spectrum of human experience. And effectively, that's kind of what you have. Like you can read leadership books, you can read all sorts of books about how to be more effective, but they're always only giving you a small piece of a much larger pie that's fairly hard to coalesce into something that's understandable.

CLAIRE: 01:05:10
So as you were talking about communication, email, tone of voice, leadership, it reminded me of a panel discussion at PGConf.dev last year in Vancouver, Canada, and it was called Making PostgreSQL Hacking More Inclusive. [Mmm.] And the people on the panel were Robert Haas, Melanie Plageman, Masahiko [Sawada], and Amit Langote. And I may have mispronounced a couple of those names. My apologies. But it was really interesting because a lot of times when people think about inclusivity, they just jump to questions of gender or questions of race in terms of who's included, right? They jumped to that type of diversity. But the focus of the conversation was as much on being inclusive of people from those different cultures, right? Who have been brought up with different communication styles that have influenced like that first 20, 30 years of their maturity and growth. So anyway, it was, I'm not sure if it's recorded or not. But I've carried that panel discussion with me. What's really cool, too, is another thing that came out of PGConf.dev 2024 is there was conversations about mentorship. And as a result, just wanted to put a plug in here, Robert Haas then kicked off a new mentorship program, which has a couple of different layers to it for the Postgres developer community, and also started a Discord server for Postgres hackers mentoring, which has since evolved to be just a general Postgres Hackers Discord server where there's a lot of communication, even beyond the mentoring program happening, that I think is pretty cool. It's a little bit higher fidelity than this, well, I don't know, is it higher fidelity than the mailing list?

BRUCE: 01:07:18
I missed the talk. I think I was out in the hallways. I usually am.

CLAIRE: 01:07:23
Oh, no no no, you had to leave at like a half day early so I think you were gone

BRUCE: 01:07:27
Yeah, I did because I was speaking in L.A. Yeah, yeah, yeah.

CLAIRE: 01:07:30
Okay, anyway the point of that, the mentioning of the new mentoring program for Postgres is it started last summer so we had Robert Haas on this show, on Talking Postgres, a couple episodes back. And I'll drop the link to that episode here. But it's been really interesting to see like how this effort, and I do think this is a kind of open source leadership and deserves mention in our conversation today, because putting a little bit of formality around a mentoring program, I think is a really good thing for Postgres and for the developer community and to help get more people involved. So I will drop that link in there if I can find it. All right. So I promised we'd talk a little bit about conferences. And the reason I wanted to do that, well, first of all, you are also, let's talk about the conferences you're going to be giving talks at in the next couple of months just in case people hear you on the show and want to go listen to you as well in one of these other events. What do you have on your calendar?

BRUCE: 01:08:43
Well, let me think, let me see what I have. Currently in May I'm scheduled to be in Nepal and Germany. I'm saying scheduled because I'm not sure if that might be just too much for me because it ends up being two days in Kathmandu and then a flight to Berlin and then two days in Germany and then I have to come home. And then my daughter's getting married the next week in Dominican Republic.

CLAIRE: 01:09:15
Congratulations! That's exciting!

BRUCE: 01:09:19
I'm going to decide the next couple of days. Yeah, if that's just too much. But right now I'm scheduled to be in Nepal. The Russians have been doing that. I think it's the third year for them. They've been trying to grow the Postgres community in Nepal. It's more of an outreach because there aren't a whole lot of developers there. But I think it's a great effort, and I've wanted to go for a couple years. And because it lined up with the Germany conference, the idea was I could do both of them in the same week, which I think is kind of cool. There is a...

CLAIRE: 01:09:53
So PgConf Nepal, PgConf Nepal in early May.

BRUCE: 01:09:56
Yeah.

CLAIRE: 01:09:58
Okay. And then PGConf Germany.

BRUCE: 01:10:01
Then PostgreSQL Conference Germany in Berlin, yeah.

CLAIRE: 01:10:04
Okay.

BRUCE: 01:10:05
That's May 8 and 9. Then I'm going to be doing POSETTE, and then after that, it looks like there is a conference in Charlotte called SouthEast LinuxFest, which I really enjoy going to. It's more of the old-style hacker, just open source, pure open source conference, which I really get a lot out of. So I'm planning to hopefully attend that. I have submitted for this PGDay Swiss, which is at the end of June. So I'll hopefully go to that. And then from then, there's nothing till Austria, which is in September. And then New York. Hopefully I'll go to the UK and PGDay Lowlands as well in September.

CLAIRE: 01:11:01
Okay, you've got a full docket. You've got a busy calendar. The best, the most exciting thing on the calendar is your daughter's wedding, I think. That's safe to say.

BRUCE: 01:11:12
There you go.

CLAIRE: 01:11:14
And, yeah, that is important. Like, that's on a pedestal above everything else. But I think you are an exceptionally good conference presenter. And one of the things I wanted to spend a few minutes talking about, And I don't know if you can pinpoint the right tips to share with people, but I'm sure there are people listening to this episode who either have not yet given their first Postgres conference talk or maybe have, but want to get even better. And what can you tell us? What can you share? What tips do you have? How do you prepare? What's your process? Like, just share, please. Help make us all better.

BRUCE: 01:12:04
There's a couple fundamental things as I mentioned earlier I was a high school teacher for five years so what I got good at was talking and thinking at the same time. Because normally, when you're having a conversation like we're having to now, while you're talking, I get to think about what I'm going to say to answer your question. And then I say a sentence or a paragraph, and then I have some more time to think, right? But when you're a teacher, you're speaking for 45 minutes straight pretty much, I mean, yeah people are asking questions but in general you have to talk so you've got to not only be talking to talking live right but you've got to be thinking about the next thing you're going to say and that takes a lot of practice at least at least for me it did, so that sort of that, that dual ability to do that is interesting. It wasn't easy, but I've done it enough. But yeah, you do it. You get good at it. Probably the second thing is that you're giving the same lecture, potentially two, three, maybe four, times in a day to different classes. And as a teacher, you can really look at two ways. You can say, well, I already gave it once. Like, this is boring. I'm doing the same thing again. But you have to realize that the audience that's listening to you has never heard that. they've never heard you give this lecture. So you have to think, how, you have to put yourself in the seats of the attendees and say, okay, I'm thinking now of how a person sitting in that chair is going to react to what I'm saying. And that's what I have to focus on because it's not about me saying the right words. It's about the people who are listening to me, hearing the right words and getting benefit from what I'm saying. So I think a lot of speakers are worried more about, okay, they're so focused on what they're doing that they're not thinking that, in fact, what they're doing is not the important part. It's how the audience is reacting and how the audience is receiving benefit. That's what you're there for. It's not for what you're doing, it's how they're benefiting from it so therefore even if you ever give a lecture 40 times right the people that you're talking to are new and those people are the that's those people are the reason you're doing this. It's not for you to give a perfect presentation

CLAIRE: 01:14:53
Okay. I could not agree with you more. And it actually, what you just said fits with the concept, I think, of servant leadership that you brought up earlier on today's call. So many people, when they're giving a conference talk, particularly if they're new to public speaking, it's super easy and normal, really common to get nervous, to get, you know, you have those butterflies in your stomach. You're nervous, which makes you stiff and awkward, maybe. You're uncomfortable. And it's all because you're caught up oftentimes in like, how are people going to judge me? Or how am I going to do? Or am I going to do a good job? Or, you know, am I worthy? Right? Am I an imposter? All this stuff that's about you. But the second you switch your focus to the audience and you stop caring about yourself and you're just like looking at those people out there and thinking, how can I help them? How do I explain this to them? How do I share with them to make their day jobs better? Once you put your focus on serving the audience, I feel like a lot of that self-created stress can go away.

BRUCE: 01:16:15
Yeah I think the other thing I remember, as a school teacher, I remember I was put in some pretty high profile positions and I remember feeling that, I had I just had a dream a couple times that, the principal is just going to walk in, he's going to look at my blackboard and say, "okay, you're gone." Like, this is just not working, you know? And it used to make me feel very sort of nervous when I would go to work and so forth. But I had a very good relationship with the principal, actually. Unusually good relationship. And what I realized is that if I just said, I'm sorry, then the problem would go away. No matter what I did, if I just said I'm sorry and I'll do better, right, the problem would go away. And that sort of took the anxiety away from me a lot. Often, you're right, when you get up, you think, oh, what happens if this happens, that happens, whatever. And sometimes, you know, a classic case, your laptop reboots in the middle of your talk, right? Let's look at the crazy example, right? What do you do? Well, you know, you can look at it and you can say, everyone thinks I'm an idiot and I wasn't prepared and they're not going to think well of me and how did this happen or whatever. Or you can say, okay, everyone, laptop's rebooting. Let me talk about something that I wanted to mention anyway before it's rebooting and then we'll continue as soon as it's back, right? And that actually works well. I actually was speaking at a user group, a Hong Kong open source user group last week. And the projector kept just going off. I'd be in the middle of my thing and I'd just get a blank screen. And I remember making a joke the first time because the little logo that comes up is in Japanese, in Chinese. I joked that that was the word Postgres, or I don't remember what I joked, or something, that somehow this little logo on the thing was related to my topic. And I spun some weird story while the organizer kind of fixed it. And it was only out for maybe five seconds. But it happened like five times or four times when I'm talking. After a while, I started making jokes about the snow that was on the screen and whatever. But again, every time you have a challenge like that, you can either panic and get really worried or you can just make light of it and just say, well, we're going to get through this. And I guess that's one of the things that sort of takes the nervousness off of it. If you forget something or if you don't know something, I'm sorry, I don't know. If you'd like to email me, I'll get the answer. I'll get the answer after. Sometimes I'll pick somebody in the audience I know and I'll say, can you find the answer to that question for me while I continue my talk? No problem, right? The guy, the person I just talked to get the answer feels like I've highlighted that person in the audience and I trust them and the person's going to get the answer. And the fact I don't know the answer is not something that should reflect poorly on me. And even it does reflect poorly on me. That's okay. Like it is what it is right I can try and pretend it's not true but it is true. I don't know the answer. So I think, yeah, I guess it is sort of related to the servant leader thing. I'm not up there to look good I'm not up there for people to think I know everything. Yeah, that's not why I'm there. But then there's a lot of mechanics to it, there's a lot of mechanics of presenting that I've learned. I mean, one class example, I was speaking in France once and I was giving a talk that I had given several times previously. And so I got off the stage and I went to Magnus Hagander, who was actually at the conference. I said, how is that version of the talk? Like, was it better or worse than the one I gave a month ago? He said, you know, I was in the lobby. I didn't hear it. I'm like, listen, I need you to be in the audience so you can tell me what I did badly or well. I need you to be there so I can get feedback. So one of the things that I realized was that I was never going to know everything, but every time I give a talk, hopefully there's somebody in the audience I can go to, and I can say, how did that go? Are there things I did better in this talk that you liked? Or are there things that I did worse in this talk that I shouldn't do again? You have to, again, back to the problem of how complex human interaction is. It's going to be different. There's going to be things. Every speaker is going to have tips for you. Every audience member is going to have tips for you. If you're going to be a good speaker, then you're going to be humble enough not to seek out that feedback every time. There's been a couple cases where I actually had a typo on my slides. And I'm like, oops, I said I will have that fixed by the end of the day on my website. What else can I do? These slides are very complicated. I'm realizing, and I'm sorry, I made a mistake there. And we'll make light of it and have a joke and so forth. But the... [So.] What's this?

CLAIRE: 01:22:03
Oh, I was just going to say, so asking for feedback afterwards is something that you now do.

BRUCE: 01:22:13
I guess it's back to what you said about development that you try and have an environment of self-criticism with a development team, right? So it's kind of the same thing, Although it's a little easier because I have no relationship with most of the people in the audience. So they can be completely honest about what they like or didn't like. In an ideal world, I see somebody who either hasn't seen the talk before, they give me feedback, or somebody who has seen the talk multiple times. And they can tell me if I changed certain aspects of it, if it got better or worse because of those changes. And that's usually really valuable because then I can try different styles of giving the talk, different ways of explaining things. And I can get feedback to say, oh, that was successful or that wasn't successful. Because, again, every time you get up to speak, you really don't know what you're going to say. It's always going to be fresh because you're looking at your audience. Your audience is going to be different. You're going to be focused on them, and they're going to drive the way you usually present the material. For example, if I'm in a non-English speaking country, I will start to speak much slower. [Right.] And I will use very simple words. So I won't use any aphorisms or similes. I'll use very simple words and I'll speak very slowly. And that makes a big difference. Now, it's not natural to do that. So you have to be very conscious of it. But when you do it, it makes a big difference. I have had people come to me and they said, you know, normally I can't understand an English speaker. But when you're speaking, I understand what you're saying. This is actually in Russia. And the funny thing is the same event. I went to see an English speaker who was from the south, southern U.S. And I had trouble understanding what the person was saying. Because they spoke so fast and they used a lot of colloquial sayings that I wasn't even, that I knew, but I only knew because I was born here, that a normal person wouldn't know a lot of these colloquial sayings. So it felt very, that talk from that speaker, it was very lively, right? It kind of flowed, it had a flow to it because he used so many of these colloquialisms. And it was kind of entertaining, but I don't think it was clear. And particularly it was not clear in a non-English native speaker setting. It might not have even been clear in England or another English-speaking country even. I don't think that person had spoken outside of the United States very often. They may not have spoken very much at all to the public. I don't know. But I remember really, not necessarily struggling, I actually found it entertaining, but I had to concentrate on what they were saying because there were so many colloquialisms in the talk.

CLAIRE: 01:25:32
Well, and accents can be a challenge to understanding different English types of accents. Even within the United States, there's different accents. And so that's actually one of the reasons why I'm, well, the first time I heard of the curb cut effect was probably five or six years ago. But I am a big fan of live captions, in conference talks, like big font on a big screen up in the front because even if I don't quite understand that person's accent in English I've got the captions there and I can read them and of course you're talking about a whole nother level which is, wait this person is using aphorisms, or colloquialisms, that might not make sense too, so there's different layers of understanding I guess

BRUCE: 01:26:21
Yeah. I've rarely seen conferences that have the luxury of live captions. I mean, I've seen it a couple times, but I don't normally see that.

CLAIRE: 01:26:30
We did it at, or when I say we, I was on the talk selection team. I wasn't one of the organizers, but PgDay SF a few years ago had the big screen. I think White Coat Captioning did it for them with big font and live transcription. And of course, now people are using more and more AI software to do it, but it was fantastic.

BRUCE: 01:26:52
They did it in New York. New York did it once, and I thought it was pretty cool.

CLAIRE: 01:26:57
It was pretty cool, but those were smaller fonts, so hard to read if you were in the middle or in the back of the room. But you know, we all keep getting better. Okay, so the key takeaway is ask for feedback. And I am a plus one for that. And also don't just ask for generic feedback. Maybe sometimes I will say, you know, can you give me one thing I could have done better? Because otherwise you might just get positive feedback, right? They might just give you a compliment because they might be uncomfortable saying something critical.

BRUCE: 01:27:27
Yeah, the people I usually ask are pretty ready to give me critical, so they're they're happy to find something wrong with me so that's usually not a problem. I think another thing is discipline of writing the slides way ahead of when they're due so I will usually finish the slot, I'll usually work on the slides maybe starting a month or two before the event, and will finish them, probably spend a week maybe 10 days on it and I will then sit on the slides for maybe a couple days where I'm just sort of like mentally sort of thinking about them. I don't know why but for some reason I will write a slide deck and then the next day or next two days I'll get ideas, oh this one slide is awkward or I could do this other slide in a better way. And it's just, just come to me, I guess, because I've been working on the slides. And then I will send the slides to the Postgres IRC channel for review, because that's kind of a neutral environment. There's obviously we have tons of people there and I will get, usually, a number of corrections. Maybe I've spelled a word wrong, maybe I've got something a little confusing, and I'll usually get very good feedback from that. So if I pass that, then I'm probably done. So I will be done five weeks before maybe the event. I will not change those slides in the week before the event, because I find that by changing the slides, I'm often, often by changing the slides, and I know a lot of people who work on the slides the week before, and a lot of times the night before or the morning of, I think you're actually adding more confusion to your mental model of the slides than you are improving the experience for the audience. Because as you add slides the day before or you modify them, then your mental model of those slides really hasn't settled into your brain, at least for me. So that would just be totally confusing to me.

CLAIRE: 01:29:56
Okay, I'm going to have a respectful no comment on that. I couldn't possibly comment on modifying slides the week before or the day before. Wink, wink. Obviously.

BRUCE: 01:30:07
I think people feel like, you know what, when I used to write a, I'll tell you, when I was writing for college, I would often procrastinate because I thought that I'm going to get some amazing idea that's really going to make this paper be great. And I would wait until the end and then I'd like, okay, I guess I didn't get an idea and then I'd write it. And I'd often finish it the day before it was due and so forth. And what I realized doing that is that, you know, it's very rare for an amazing idea to just pop up in your head, particularly, you know, on something you've been assigned to work on. And you're better off just taking what you have, spending time on it, and then just doing your best. And if you have a great idea later, then you can modify it, right? Or you can change it. But just get it done. Let it sit in your head. Get the IRC channel or somebody or some group of people to kind of eyeball it for obvious mistakes, and then give the talk and don't worry about it, and there's going to be things that you don't like about it, there may be a bug there may be a mistake in that slide, and you just publish, just push an update for it. I mean almost in in every case, probably the first five times I give a talk I will make a small modification to those slides after every time I present it. Because I thought, oh, you know, this word should be bold, or I should italicize this, or, oh, there's a comment that, I should add an SQL comment to this one line, so it's clear for the audience. Because somebody in the audience asked, what does this line do? And I'm like, oh, I should have a comment there on the slide. So again, you're always in that mode of constant improvement, but again, you're not trying to get it perfect the first time. You're just trying to get something that's stable, something you're going to be able to deliver confidently, something that's going to flow well, something you're not going to get confused by. Because if you walk in, and those slides aren't settled in your head, and you're not sort of confident about what you're doing, that's going to reflect much worse than whatever little improvement you think you're going to make the night before.

CLAIRE: 01:32:29
So there's there's two things you've just said and I agree wholeheartedly with the first one which is that starting earlier gives you more time for iteration, or for the talk to marinate, if you will, if you want to use like a cooking analogy. [That's right.] And that iteration can be in your own mind and almost in your subconscious, [Mm-hmm.] even when you're asleep, [That's right.] as well as iteration with other people and your examples of sending it to the Postgres IRC channel, for example. And then that feedback from other people in turn has to get iterated on in your own head. And I'm a big fan of the edit cycle and all the value. Like my first drafts in comparison to my final drafts, my first drafts suck, right? And they get so much better as I move through this cycle. And so I, I think you're spot on on there. And the earlier you start, the more time you allow for that iterative process. The part where I don't know that I agree with you is I am making edits for the first time I give a talk in that week before I deliver it. And, you know, maybe because I'm deadline driven, maybe my edits might seem material to me, but in fact, they aren't changing the structure of it. So my brain isn't getting confused. You talked about how those last minute changes could confuse your delivery. For me, it works. But maybe if I were to go look at it, the changes I'm making that last week are not huge. So maybe that's why it works. I don't know.

BRUCE: 01:34:10
Why would you have ideas the last week that you wouldn't have five weeks earlier?

CLAIRE: 01:34:15
These are mysteries of my brain, Bruce. I can't tell you. I can't answer that.

BRUCE: 01:34:20
The way I look at it is a lot of the edits that would be made closer to the presentation are more panic edits that like, oh, I better do this or maybe I'm not ready or whatever. You know, the way I look at it, you know, I'm not writing the Magna Carta here, right? I mean, I'm writing a presentation about Postgres. I want to get a couple key points across. And that's it. This is not, you know, I'm not writing some amazing thing that's going to change the world. I'm just basically giving. And the bottom line is that people are only going to remember two things from your talk. Right? And that's the other thing. Like, you can think that everything that you say and every word that you say and every point you make is somehow going to have an impact, but they've done studies and people pretty much only remember the first thing they say and the last thing you say. So the slides are there, particularly for them to go back. My slides have a tendency to be very information dense with a lot of links to external sources. So a lot of people will say, I watched your talk and then I have to go back later and go on your website and click on some of the stuff and really run some of the SQL to understand how it works. So again it's not that you're going to really have some kind of everything's going to be perfect on that slide, I think you have to almost walk in assuming that your slides are never going to be perfect in a million years and all you're trying to do is just get it closer and polish some of the rough edges off of it. But when you realize that you're going to make a bunch of edits but in fact the problems that are going to be brought up by your first and second and third audience are going to be improvements that you never would have thought of in a million years and they're going to propel that presentation far more than you obsessing about it would ever do. So there's been there's many times where I will give a talk and I will say, if somebody will ask a question, I'm like, that is an unbelievably obvious thing I should have had in the slides. And I apologize for that and I will add it. So I guess it's back to humility. I can think that I'm going to keep improving it and somehow find all these things that really should be in there. But it really is the process of delivering it and getting questions from the audience that really take it to that next level. It's not me. I can only take it so far and I can try maybe and add a little X, Y, Z to it, but the people in the audience are going to take it much farther. And my little, my little additions are pretty much going to be negligible.

CLAIRE: 01:37:26
So you are, and I think this is obvious for anyone who's been listening to every one of your words in the show, but you're a fan of giving the same talk multiple times and continuing to almost improve it through each of those experiences.

BRUCE: 01:37:44
Yeah, it would be pretty impossible if you're doing 30 events a year and you have a very information-dense presentation, right, which takes let's say two weeks to make but then you have to have the idea for the talk too, right, so that would be that would be 60 weeks plus the you'd have to have 30 ideas as well in a year and historically having done this for 25 years or whatever 29 years I only probably have two talk ideas a year, two to three. If you look at the, if you look at the slot, I have 62 slide decks, but that's over 29 years, and statistically it says I do two a year. So I know a lot of people do talks for specific conferences. I have done that in the past for a conference that I feel that if I can understand would be unique for that conference, I'd love to do it. But in most cases, I don't even understand the audience really well. So I've never figured out how to basically do a one talk per conference life. And I don't know how I would effectively do that because I don't have that many ideas.

CLAIRE: 01:39:16
Well, even if you did, I actually agree with you that there's value in giving the same talk multiple times. Because first of all, if you only gave it once and it wasn't video recorded, then you're not getting the same ROI. You're not helping as many people, right? [Right.] Because that one time you gave it, however many people were in the room, that's the limit of that influence. Although maybe they might have each had a takeaway that they shared with some of their friends or teammates, right, or colleagues. So maybe the influence goes beyond the people in the room. But it goes way beyond the people in the room if you give it a few times, a bunch of times.

BRUCE: 01:39:55
Or if it's video recorded, right? For me, one of the key things is taking questions. So I find that the discussion that the talk usually engenders is sometimes the most interesting part of the talk. So that's what I try and focus on. I try not to have, aside from the fact most of my talks seem to have an umpteen number of slides, more than I probably should have, I will take questions during my talk. Either I'll break at each section or I'll just stop and ask for questions and so forth. And I think that really brings a, that's really where I think the secret sauce is in terms of having the audience really feel like you've spoken with them, not necessarily talked to them. Like the joke I've tried to explain people is your goal is not to tell people what you want to tell them. Your goal is to tell people what they want to know.

CLAIRE: 01:41:01
Or maybe carry that a little bit further from what you said earlier. Your goal is to give them something that they can hear, give them something that will sink in, that they will take away, that they will benefit from in the audience,

BRUCE: 01:41:15
[Right.]

CLAIRE: 01:41:17
which means not just talking, but them hearing, digesting, and retaining something.

BRUCE: 01:41:23
Yes. And every time you're you're stopping to take questions, that's another opportunity for that information to sink in. Right. Because we're stopping and then we're starting again. So that's really a start and stop time. And then, yeah, some of the questions are just really interesting. So, you know, it gives me a chance to take a break. Right. I don't have to talk while they're talking.

CLAIRE: 01:41:45
Take a sip of water.

BRUCE: 01:41:47
Yeah, I think so. And it's usually really, really good questions. And if they're asking it, somebody else will probably have the same answer. And sometimes that's your opportunity to improve the slides. So somebody asks a question and you're like, oh, gee, I should have that on my slides. That's an important point. and then you add it for the next audience and then the question doesn't happen anymore. But then you did another question, which might be another opportunity to improve the slides.

CLAIRE: 01:42:23
All right, Bruce, I think we are near the end. I have one last question for you.

BRUCE: 01:42:29
Mm-hmm.

CLAIRE: 01:42:30
We have had several guests on the podcast who had interesting cheese stories. Either their beginning, their origin story in Postgres came out of a cheese factory, for example, in the case of David Rowley. And I'm just curious, does cheese have something to do with your work in Postgres? Is there a connection?

BRUCE: 01:42:50
There is a connection, and I'll tell you what it is. So I went to a conference in the Netherlands, and it must have been about 12 years ago. And the speaker gift was cheese. And it was all these different types of cheeses. And they were all, I think they were all basically three year aged cheeses. And I brought it home, and I think it must have been a PGConf.EU because it was right before Christmas, so maybe November, October. And I brought the cheese back, and my wife said, oh, this is a great speaker gift. Yeah, it's kind of cool. And she said, we'll keep it for Christmas. So obviously we had a bunch of people over for Christmas. And my wife brought out the cheese, and this cheese was amazing. Now, the amazing part was that it was probably four or five different types of cheese, all very much aged. And I think we came to appreciate, as a family, different types of cheese much more from that experience. So that is my cheese story. The one criticism I have of the cheese industry is it's very hard to figure out what a cheese is by looking at it. Because they're going to look the same. I don't know how they can fix that. But it feels like a design problem. That the cheeses kind of all are yellow. And it's really hard to remember what something is unless you taste it. And we end up having to label a lot of cheese because you can't tell just by looking at what it is.

CLAIRE: 01:44:34
I find that if I ever to be able to answer people's questions about what kind of cheese is that I have to make those little labels kind of like place cards.

BRUCE: 01:44:42
Yeah, that's what we've been doing here, that's exactly what we've been doing here. Yeah, but that was a game changer for us because I think that probably the coolest thing I remember was a lot of that cheese had crystals in it, kind of crunchy little crystals, because it had been aged for so long. And I thought that was just fantastic. That there's, I can still remember, and we've found other cheeses that have it, but I remember going to a couple of cheese places and I'm like, do you have any cheeses with like those crystals in it? Oh yeah, this one has it.

CLAIRE: 01:45:17
All right. Well, I know that people put a lot of thought into speaker gifts at a lot of Postgres conferences. And it's one way for the organizers to show gratitude to the speakers because the speakers have to do a lot of work that they don't always get paid for, right? It's oftentimes that work can happen on the weekends or in the evenings. And so anyway, it is a nice expression of gratitude.

BRUCE: 01:45:42
I thought so.

CLAIRE: 01:45:44
Okay, well, speaking of gratitude, thank you for joining me. I know you're not a podcast person per se. You told me that you don't regularly listen to a lot of podcasts, but I appreciate you coming and sharing your perspective on leadership in open source and as well on conference speaking with all of us. So thank you, Bruce.

BRUCE: 01:46:07
Well thank you for inviting me.

CLAIRE: 01:46:09
And for those of you listening, if you liked today's episode and you want to hear more of these Talking Postgres episodes, you should subscribe on Apple, or Spotify, or YouTube, or wherever you get your podcasts. And please tell your friends too. If you leave a review, that helps more people discover the podcast. You can always get to past episodes, get links to subscribe on the different platforms at TalkingPostgres.com. And you can find transcripts on all the episode pages on TalkingPostgres.com too. A big thank you also to everyone who joined this live recording and participated in the live text chat on Discord. Thank you.