Write It Down: Brendan O'Leary from Prefect.io

Brendan O’Leary shares his journey from helping GitLab scale to IPO to his current role at Prefect.io, focusing on Pythonic orchestration. He explains why Prefect chose Python and how orchestration tools like Prefect complement CI/CD platforms like GitLab CI/CD and Harness in DevOps workflows.

We discuss the evolution of Developer Relations, its ROI, and tips for building sustainable open-source communities. Brendan also offers advice on balancing a tech career with family life.

In closing, Brendan shares his key lesson learned throughout his career: "write things down", emphasizing its importance for clarity and progress in tech.

For further insights, check out the articles Brendan suggested:

• Measuring Developer Relations
• What I Learned at GitLab That I Don’t Want to Forget

Transcript

1
00:00:54.380 --> 00:01:17.039
Dewan Ahmed: Hello, everyone. Time appropriate greetings. Good morning. Good afternoon. Good evening. This is ShipTalk, podcast and I'm your host, Dewan Ahmed, I'm principal developer advocate at harness, the AI-native software delivery platform. And with me today I have Brendan O'leary, Vp. Of developer relations at Prefect.io. Hey, Brendan, how's it going.

2
00:01:17.370 --> 00:01:20.190
Brendan O'Leary: Hey, Dewan? So so nice to be here! Thanks for having me on.

3
00:01:20.190 --> 00:01:39.790
Dewan Ahmed: Absolutely so. You are a known face in the tech landscape, a known technical leader. But for those listeners and viewers who are not familiar with your work. Could you please give a quick background about yourself, how you came into software industry and then your transition into developer relations and product strategy.

4
00:01:40.420 --> 00:02:08.839
Brendan O'Leary: Sure. Sure. Yeah, thanks. I you know, I got my start in my career. I thought I was gonna go into like kind of traditional it. And then I I met somebody who ran a small like bootstrapped medical software company. And I've been kind of in software ever since. I spent a lot of years there and in other bootstrapped companies. And then I started working for startups when I was lucky enough to get the opportunity to join Gitlab in 2017, when they were about

5
00:02:08.979 --> 00:02:20.491
Brendan O'Leary: about a hundred 50 ish people solid grow over the next 5 years to like 2,500 people and was there, for the Ipo is like kind of a fantastic ride.

6
00:02:21.100 --> 00:02:49.159
Brendan O'Leary: And then since then I've gone to a couple other smaller startups, I worked for a couple of years in cybersecurity. And then, most recently, as you mentioned, I'm at Prefect as the Vp of developer relations, so much more focused in the data space. And yeah, developer relations is something I kind of got into while I was at Gitlab. I say, when you're at a small startup like everyone's a part time evangelist or developer relations person, especially in an open source startup

7
00:02:49.533 --> 00:02:54.979
Brendan O'Leary: and then eventually, when you grew, you know, I kind of had to specialize, and

8
00:02:55.120 --> 00:03:08.910
Brendan O'Leary: I actually got talked into it by Priyanka Sharma, who's now the executive director at the Cncf. But at the time she was at Gitlab Running Devrel, and and for almost a year she was trying to talk me into it, and I finally said, Yes, and

9
00:03:09.060 --> 00:03:11.719
Brendan O'Leary: now it's it's what I've made my career doing really.

1
00:03:13.170 --> 00:03:36.609
Dewan Ahmed: What you mentioned about getting to work in companies who's going from, let's say, A to A or B to C to Ipo. Not many of us have those opportunities. It's like sometimes called like a rocket ship. Right? What are some valuable lessons for folks? Maybe they're in these situations where they're at a Rocket growth company, hoping to go to Ipo like, what are the lessons that you learned.

11
00:03:37.050 --> 00:03:57.299
Brendan O'Leary: Sure. Sure. Yeah. I mean, I think I think the lessons that I learned it's it's interesting. Get lab, you know, was kind of remote before it was cool, or or had to be right, like we were all remote for almost the entire life, and and the entire time I was there for sure. So 2017 was obviously before the pandemic and before kind of everyone had this idea of like, hey? What if we? What if we went remote.

12
00:03:57.450 --> 00:04:25.280
Brendan O'Leary: and I came to learn, I think, that the most important things for doing remote well are also kind of the things that companies have always aspired to do well. And so it's things like like writing things down. I think I think it's like a superpower that people underestimate right. But a single source of truth, for documentation is something that not only helps you today, but like helps you when you're onboarding people right? There was a time at Gitlab, where

13
00:04:25.590 --> 00:04:31.980
Brendan O'Leary: I had calculated that in my tenure we had hired more than one per work, one person per working day.

14
00:04:32.220 --> 00:04:58.149
Brendan O'Leary: and and so the ability for people to self serve and find the information they needed to get their job done was like really critical. And it, you know, it reduces meetings. It reduces like the like weirdness around, like who's making a decision. It makes it like this effective like decision making process. And this fast decision making is kind of the number one thing in a startup that's like really trying to scale out and so I think that's the number one thing.

15
00:04:58.800 --> 00:05:19.919
Brendan O'Leary: And then I think with that is like giving trust and agency to a team right? Like, I say this, it kind of sounds weird, but like it's true. It's like hiring adults and expecting them to act like adults like there's no process in perfect world, especially in such a dynamic thing like software development. That's gonna let you, you know.

16
00:05:20.330 --> 00:05:34.402
Brendan O'Leary: make a perfect process right? But if you hire people that are smart and give them ownership over the decisions that they that they need to own again. It allows you to, you know, accelerate decision making. And then, I think, lastly,

17
00:05:34.870 --> 00:05:49.320
Brendan O'Leary: transparency that comes along with writing everything down is really critical. The more information that you can give again to all these people who you're trusting to hire the better, and then shipping with a low level of shame is like kind of the last thing. Gitlab is pretty famous for this like

18
00:05:49.760 --> 00:06:01.690
Brendan O'Leary: ship something, and and that's that's the advantage of startup has. Even if you're growing, you still have that advantage that you can ship faster, and so don't ever try to never lose that that advantage.

19
00:06:02.280 --> 00:06:14.210
Dewan Ahmed: 100% agreed. And I think that's something both like gitlab and harness has in common that like get ship done is also one of the mantra of harness like, just get it done. You don't need to ask for permission if it's something feels right

20
00:06:14.210 --> 00:06:35.129
Dewan Ahmed: just. And one of our leaders say this like, you have to be operating at all levels, just like, let's say, if I own a subway like the restaurant, I should be able to know how to make a sandwich, how to mop a floor, how to clean the washroom, like everything I should be able to do as an owner of a subway in case someone's not there, I should be able to do

21
00:06:35.130 --> 00:06:51.279
Dewan Ahmed: anything, and I think similar models apply for for these giant companies, or even startups like a leader who has walked in everyone's shoes. Of course they don't need to know about every single detail, but they should be able to understand how the actual work gets done.

22
00:06:51.840 --> 00:06:55.249
Brendan O'Leary: Yeah, exactly. Exactly. It's really, it's really critical.

23
00:06:55.555 --> 00:07:18.950
Brendan O'Leary: And and the other way, too, right? Like, you want your team to understand. You know the the pressures that are on leadership, so they can contribute to it. Right? The mantra or the the mission of Gitlab for a long time was, everyone can contribute. And that was true. It's like everyone can contribute. And then we have this concept of a dri where it's like. But this is the person that's the directly responsible individual to make the decision.

24
00:07:18.950 --> 00:07:26.120
Brendan O'Leary: And so yes, everyone can contribute, but also balancing that with like, this person is going to make the decision, and we're all going to get behind them.

25
00:07:26.460 --> 00:07:30.430
Brendan O'Leary: Was, it was like again. It's a really powerful way of operating.

26
00:07:31.010 --> 00:07:55.700
Dewan Ahmed: Absolutely so shifting gears towards Prefect. So when I check the website like Prefectio, it's a pythonic orchestration for modern teams, which is a very nice, like catchy term, like pythonic orchestration. I didn't exactly know what is pythonic orchestrations, but I'd love to know, like what is pythonic orchestrations, and maybe a follow on that would be like, why do you think like orchestration is so critical for modern teams.

27
00:07:56.350 --> 00:07:56.670
Brendan O'Leary: Yeah.

28
00:07:56.670 --> 00:07:58.160
Dewan Ahmed: Buy python for that.

29
00:07:58.570 --> 00:08:10.480
Brendan O'Leary: Yeah, yeah, that's that's a lot of great questions. Yeah. So so Prefect is is open source as well. It's an open source tool and the the goal is really to marry the business logic that data teams are writing

30
00:08:10.720 --> 00:08:40.060
Brendan O'Leary: to the right compute resources making sure that, like the code that they're writing gets the same compute when it needs it, and and scaling up and down so that that sounds a little bit like a lot of things right like that kind of makes. This orchestration is kind of a very generic term. Right? Like Kubernetes is an orchestrator like, why like, why does this exist. But this, this 2 things is the pythonic nature, and then the the differentiate nature of what data teams need when it comes to orchestration. So.

31
00:08:41.880 --> 00:08:55.059
Brendan O'Leary: you know, the python is the language of of data science and and of of data engineering and rather than like having folks have to rewrite that code.

32
00:08:55.568 --> 00:09:04.640
Brendan O'Leary: In some way, right? Whether that's to like fit into a specific Dsl or a yaml, or some sort of very specific dag structure.

33
00:09:05.180 --> 00:09:33.849
Brendan O'Leary: The idea around Prefect is it just takes your python code, wraps around it and makes it production rate so that you can add things like retrying and monitoring and scheduling without having to like, learn a whole new world right? And so by by staying pythonic, it allows kind of the right separation of concerns. I would say, between like infrastructure teams and data teams, right? Because data teams are often kind of

34
00:09:33.850 --> 00:10:02.200
Brendan O'Leary: left behind or like kind of the last thought, right, everybody. When we think of deploying infrastructure we think of, you know, application teams, and we're going to deploy these docker images to Kubernetes. Great. Well, those are for great, for like long running applications. But data teams have this like very different need, where some things might have to be batch. Some things have to be scheduled to happen at certain times. Some things, you know, might require specific kinds of compute for specific you know, use cases right? We might need

35
00:10:02.200 --> 00:10:12.790
Brendan O'Leary: a massive set of gpus to train a model, but then afterwards, you know, a much different lower kind of cost hardware to to run it and productionize it. So

36
00:10:13.340 --> 00:10:35.220
Brendan O'Leary: that's kind of what prefect helps to to bridges that gap and create the right level of separation where a platform team can deliver to data teams what they need with what they know. You know, kubernetes and and those kinds of things, you know other, you know, cloud native scaling. And the data teams can just do what they want to do, which is, write python. And then Prefect is kind of that bridge between the 2.

37
00:10:35.990 --> 00:10:56.789
Dewan Ahmed: And I like how we're reusing that abstraction. It's just one more layer of abstraction like even Kubernetes. It's the abstraction. So the power of abstractions comes into play. I know you touched on the choice between work workflow engine versus ci. CD. Briefly. But I'd like to double click on that.

38
00:10:56.790 --> 00:11:15.879
Dewan Ahmed: How, let's say, an engineering team. They have heard about all these different tools. There's harness Cicd, github actions, gitlab, workflow, airflow prefect. How do they choose about choosing a workflow engine. For let's say, there's data pipelines. They have Cicd pipelines. How do you do that?

39
00:11:16.300 --> 00:11:42.110
Brendan O'Leary: Yeah, I mean, I think I think that you know, it's it's kind of as you specialize that things that those decisions become more more critical. Or you know, that's where the it depends. Kind of comes in right? I think if you're doing, you know, I if you're doing basic anything a tool. Many many tools are are useful, right? Like, if you just want to run a pipeline one time, there's lots of tools you could choose off the shelf.

40
00:11:42.220 --> 00:11:59.679
Brendan O'Leary: But if you want to deploy software, okay, now, you've got to look at tools like a harness or gitlab Cicd Github actions, tools that are kind of more gained towards. Hey, I have code that I want to get running in a production environment, right? Those tools are great for that.

41
00:12:01.300 --> 00:12:22.480
Brendan O'Leary: and if you have a more specialized thing like I was saying about data teams that have this more specialized, hey? I've got to run batch jobs, and I've got to schedule stuff, and I've got to do some, maybe event driven stuff and some schedule stuff, and this kind of weird amalgam and some of the stuff. It has to be real time. Right? Like most of the time, application developers are like, well, everything's real time. It's an application. Users are using it.

42
00:12:22.480 --> 00:12:41.979
Brendan O'Leary: Data team is very different. It's like some stuff needs to be real time. Because, oh, this is a recommendation algorithm that's running that our application developers are actually hitting an Api for right as people are on the website versus this is model building that needs to happen, you know, once a day or once a week. Right? And so those kinds of

43
00:12:41.980 --> 00:13:00.039
Brendan O'Leary: differentiated use cases. Then start to say, Okay, I need a more specialized tool that's really focused on what I'm doing, not just always kind of running the same pipeline. And so I think that's where the the bifurcation comes. And I think I mean, I'm biased because I come from the Dallas world. I'm in the data world. I think you need both right, like, I think

44
00:13:00.040 --> 00:13:12.789
Brendan O'Leary: you should be using a Ci CD tool to deploy your code to where it needs to be to to run it. But then I think you should use an orchestrator to actually schedule and run those jobs once they're live.

45
00:13:13.181 --> 00:13:28.809
Brendan O'Leary: So I think you know, for scenarios that require sophisticated scheduling dependency management between chass like data driven conditional logic moving data between things. That's where you need like a data orchestrator. But if you need, you know, to deploy.

46
00:13:29.030 --> 00:13:37.140
Brendan O'Leary: test, build, deploy automate. That's where you need, like a pipeline tool, like a harness or a gitlab. Csd, so I think

47
00:13:37.370 --> 00:13:42.930
Brendan O'Leary: most teams are doing both of those kinds of things that that have a sophisticated data architectures. They probably need both.

48
00:13:43.680 --> 00:14:02.690
Dewan Ahmed: Yeah. And I'm wondering about the maturity model or or the right time to choose these tools. So both of us have been like in the tech space for a long time. And we have seen teams battle between build versus buy like, should we buy this or like this open source? So let's just build it. So it's not easy, by the way, so.

49
00:14:02.690 --> 00:14:03.090
Brendan O'Leary: Yeah.

50
00:14:03.090 --> 00:14:13.509
Dewan Ahmed: Then how do you choose when to, let's say, just build your own. If you have an army of engineers versus you, you buy something. You build something. What's the balance? Here?

51
00:14:13.510 --> 00:14:17.409
Brendan O'Leary: Yeah, I mean, I I think the balance comes from.

52
00:14:17.650 --> 00:14:22.100
Brendan O'Leary: You know what you are, you know.

53
00:14:22.430 --> 00:14:26.899
Brendan O'Leary: It's it's like oversimplification. But like, what are you paying your team to do right like

54
00:14:27.050 --> 00:14:29.069
Brendan O'Leary: in in many cases.

55
00:14:29.090 --> 00:14:54.230
Brendan O'Leary: what you're paying your team to do isn't to maybe go learn kubernetes at a really deep level and deploy it to bare metal servers and get it running right like you're you're paying your team instead to deliver an application to your your end users right? And so that's that's maybe the full range of of like the what it would be like. Oh, am I paying somebody to really learn to Kubernetes? Or am I paying someone to like deliver value to my customers?

56
00:14:54.230 --> 00:15:00.519
Brendan O'Leary: And it it's a journey for, and it depends on the size of the team and the size of it right at some point

57
00:15:00.590 --> 00:15:07.600
Brendan O'Leary: right like, if you're all your people are paid to do this, then you should probably be buying a lot of off the shelf stuff and not building much of anything.

58
00:15:08.268 --> 00:15:16.859
Brendan O'Leary: But there's a there's a trade off time where you say, okay, now, I've got to optimize the compute that I'm using in in my cloud. Because

59
00:15:17.100 --> 00:15:43.349
Brendan O'Leary: yes, I'm delivering to a customer. But like some of this value comes from like, how much am I spending to do that right? Or Oh, well, I have so many developers that are doing this that I need a team that's focused on their productivity right? And now they're gonna help, you know, kind of build some tooling on top of what we might have to do that right versus. Oh, I'm you know I am a hyperscaler. So I've got to understand Kubernetes inside and out, right? So I think it depends on where you are kind of on that journey.

60
00:15:43.440 --> 00:15:47.290
Brendan O'Leary: and and what the team's mission is right. If the team's mission is to make

61
00:15:47.420 --> 00:16:03.530
Brendan O'Leary: get code delivered, then, like you should probably not be building much of anything if the team's mission is to make that team more efficient. Okay, now you're talking about, you might be building some more, you know, abstraction layers right to your point between that team and the compute to help them help them be more efficient at their job.

62
00:16:04.230 --> 00:16:11.820
Dewan Ahmed: Totally agreed, both on the on the point of mission. Both of our mission have been to to take

63
00:16:11.880 --> 00:16:31.059
Dewan Ahmed: what our engineers have been building and take it to the developer world. Work as a two-way feedback mechanism. Tell the world that awesome tools and projects they're building, but also hear their feedback and then bring that back to the company and the product teams, which is typically called developer relations. So on developer relations.

64
00:16:31.060 --> 00:16:43.359
Dewan Ahmed: A very controversial question, do you think developer relation is still relevant to all teams or all companies, and especially in 2025. How it has changed!

65
00:16:44.018 --> 00:16:49.990
Dewan Ahmed: In the last 1015 years, like from the twilio days, and then I have a follow up. After that.

66
00:16:49.990 --> 00:16:50.730
Brendan O'Leary: Okay.

67
00:16:50.780 --> 00:17:09.150
Brendan O'Leary: yeah, no. There's lots of controversial questions. And like you, if you've met me before, you know that I'm don't really shy away from them. I mean. Yes, I think I think it is right, like I I and I think the the reason is maybe the most controversial part of my opinion here, which is like, you know, folks will ask like.

68
00:17:09.150 --> 00:17:24.759
Brendan O'Leary: where does developer relations belong? And you know what I I think developer relations at the end of the day is developer marketing, which, like a lot of my fellow developer relations, people might not like me saying that. But like it's true. And and I'm not. That doesn't mean that.

69
00:17:25.130 --> 00:17:32.100
Brendan O'Leary: But but why is it not just like any other form of marketing? Well, it's because developer marketing is not.

70
00:17:32.550 --> 00:17:58.829
Brendan O'Leary: is not like anything we traditionally think of in marketing right like. If you looked up marketing in a dictionary and looked at the definition, none of that fits with developer marketing. What developer marketing takes is understanding where developers are meeting them where they are and understanding their problems, and then applying a set of tools to those, to those problems that may or may not result in commercial success honestly for your company. But

71
00:17:58.960 --> 00:18:06.140
Brendan O'Leary: so it should have a opinionated view of the world. Probably that matches what your what your company is trying to build. But

72
00:18:06.200 --> 00:18:30.840
Brendan O'Leary: that opinion doesn't is is like is what developers are looking for, right? They they want to understand. How are other people solving these problems? How can I solve this problem better? And but they're going to evaluate that very directly right. They're not going to evaluate that by reading. They're going to evaluate that by hands on keyboard. And so you need people there to help them understand that. And so I think developer relations is just as relevant today as it's ever been.

73
00:18:31.126 --> 00:18:36.560
Brendan O'Leary: I think you'll see companies that have completely decided. Oh, it's not relevant, and it's cut it out like.

74
00:18:37.020 --> 00:18:41.249
Brendan O'Leary: I don't think you'll see those companies succeed in the long run.

75
00:18:41.766 --> 00:18:48.939
Brendan O'Leary: And I think the biggest companies that that are successful right now are still very heavily invested in developer relations, and that that is an example of it.

76
00:18:49.530 --> 00:19:16.740
Dewan Ahmed: Yeah, absolutely the way I phrase it, as like, we're not in the business of selling shoes. If it was simple as selling shoes, then all I have to do is just say, like, this is our shoe. It bends. It's long lasting. It's affordable. Buy our shoes. We're in the business of selling or providing complex products like complex technical products. And the end user have to know how to use these products. And someone has to do it. You can use any title you want. You can even have.

77
00:19:17.070 --> 00:19:34.790
Dewan Ahmed: Ito or CEO could do the work. But someone actually has to do the work of building the documentation writing, the content creating videos so that those complex ideas can be consumed. So you can have your devrel team do it. You can have one person, multiple person. But someone has to do that work.

78
00:19:34.930 --> 00:19:38.520
Brendan O'Leary: Correct. Yeah, that's a really good point. It's a really good point. Yeah, the title.

79
00:19:38.810 --> 00:19:51.990
Brendan O'Leary: yeah, we we can and always have debated the titles for forever. But the work has to happen. Yeah, it's like you are going to have to market to developers. You're going to have to show people how it works and why it's important to them.

80
00:19:52.406 --> 00:19:56.860
Brendan O'Leary: And and without that, yeah, you're not going to succeed. So you're 100% correct.

81
00:19:56.860 --> 00:20:12.450
Dewan Ahmed: Yeah, and one other common like for for maybe some listeners who haven't heard developer relations before, or developer advocacy before. Think of it as like Gmail versus Google Cloud. So if you're using Gmail, it's like a end user consumer product, you just open an account. And you send emails, you send email.

82
00:20:12.550 --> 00:20:27.359
Dewan Ahmed: But Google Cloud is what you use to build like software and applications. So of course, we can't expect everyone to know how to use Google cloud. And that's why you need people who are engineers or who are still engineers.

83
00:20:27.540 --> 00:20:29.920
Dewan Ahmed: to show other engineers on how to do that.

84
00:20:30.950 --> 00:20:35.399
Brendan O'Leary: Exactly. It's a really good point. And Google Cloud has a massive developer relations team, right? Like.

85
00:20:35.400 --> 00:20:35.800
Dewan Ahmed: Yes.

86
00:20:37.930 --> 00:20:52.939
Dewan Ahmed: So I mentioned about the follow up the follow up, and you like this, follow up is about Roi. The other controversial part about developer relations, that where's your metrics? So so you're saying that you give a talk. And now we don't have 10 paying users for our product. How does it work.

87
00:20:53.540 --> 00:21:06.699
Brendan O'Leary: Yeah, no, that's a great question. And again, I think, I, so so I, I start with my my theory, that it is developer marketing right? And then I apply kind of more traditional marketing terminology to it, because I think

88
00:21:06.820 --> 00:21:19.039
Brendan O'Leary: it is at the awareness stage, right? For the most part awareness, and then education stage. And so because of that, I think that's why it's so hard. You cannot directly tie

89
00:21:19.060 --> 00:21:37.570
Brendan O'Leary: quickly and easily attribution to things that are awareness marketing plays right like that. That's just kind of known. If you, you know, ask any marketing, Mba, and they'll say, Yeah, that's top of funnel is really hard to to measure, for that's not to say you shouldn't measure, for, because I also think that

90
00:21:38.010 --> 00:22:06.569
Brendan O'Leary: we, my my next controversial take is that we, as developer relations, professionals, got a little bit lazy right in in a world where we had Zerp, and we had, like these massive startups that were growing so fast that we said, Yeah, like, developer relations is a given so like I don't have to, you know. Prove my, prove the worth of it like, that's not a great idea, either, and that's, I think, what got us into the situation we are now, which is where folks are kind of like, Wait, what is the value of developer relations?

91
00:22:07.250 --> 00:22:30.609
Brendan O'Leary: And so actually, the 1st thing I've done at both of my leadership roles that I've taken since I left Gitlab is establish. This is how we're going to measure it. There's a really great article written about this that I'll share with your your team that, basically, you know, talks about all the different ways you can measure it, you know, contributions to Github, or or, you know, again, talks given, or people that we've given talks to, or

92
00:22:30.660 --> 00:22:39.269
Brendan O'Leary: views of, a blog post. But I think that all of those things really roll up, and this this makes the argument that I agree with that. It rolls up to

93
00:22:39.280 --> 00:23:04.509
Brendan O'Leary: how many people are using the tool right? Monthly active developers. It calls it right. And this is this is how github measures developer relations, too. It's like how many people are using the product monthly, that in the end is the thing that you're going to have to measure against. Because if you're if you agree with my theory that it's an awareness play that means that things that you do will necessarily lead to more awareness will lead to more adoption.

94
00:23:05.034 --> 00:23:21.760
Brendan O'Leary: So I think you have to measure that. Now, should you measure other things like how many people are viewing a vlog, or how many people do you reach in a talk? Sure, yes, but you can't over. You could easily overcorrect for those things, and so measuring as your kind of key performance indicator.

95
00:23:22.340 --> 00:23:37.609
Brendan O'Leary: Monthly active developers is, I think, the only way that you can be successful. And and we had this concept again to get lab of key performance indicators and then performance indicators. So a key performance indicator is the one that you're really measuring yourself against and trying to push.

96
00:23:37.660 --> 00:23:57.160
Brendan O'Leary: But then you can have performance indicators that have like, oh, our theory is if we build up our Youtube subscriber base, or if we go to, you know, 14 conferences this year that will lead to other outcomes. But you have to. You have to start, I think, with saying, hey? The key number we're gonna look at is is users.

97
00:23:58.890 --> 00:24:16.130
Dewan Ahmed: And I think everyone can agree that you need to continuously improve process. And you can't improve something that you can't measure, and that goes not before, like talks, or, let's say, blogs. You write, it's even, let's say, if we have 20 different conferences we can go to.

98
00:24:16.130 --> 00:24:38.289
Dewan Ahmed: We have a proven model with weight base, like, what's our target? Audience? Okay, how long is the distance you have to travel to the other part of the world and based on factors. You can rate out of 10 or 100 that if it doesn't meet those threshold, then it's a no, I think in the past a lot of teams have burned by just traveling

99
00:24:38.290 --> 00:24:49.140
Dewan Ahmed: to all over the places which might not relate to their to their end goal and company goal. And that's where the clusters happen that like, why did you spend $10,000 going to those conferences?

100
00:24:49.460 --> 00:24:56.090
Brendan O'Leary: Yeah, yeah, it's very expensive to attend a conference or sponsor a conference. And so yeah, a hundred, you've got to understand.

101
00:24:56.190 --> 00:25:04.629
Brendan O'Leary: And and yeah, it might not be a dollar for dollar roi that you can put on it. I mean, maybe it is. If you're sponsoring right, you're gonna expect to get leads out of it. Now.

102
00:25:04.740 --> 00:25:08.753
Brendan O'Leary: that may or may not be the devrel team ideally. It's it's not. But

103
00:25:09.310 --> 00:25:33.980
Brendan O'Leary: If you're going to an attend a conference. You have to have, you know, an outcome that you expect. That that is, gonna make it worth that investment right? And I just think that's true true anywhere, right like we. Again, we had sorry to go back to get Lab again, but we had this concept called Spend company money like, it's your money, and so like on the on the spending company. Money page. That was Rule number one, and then rule number 2 was no really and that sounds like

104
00:25:34.544 --> 00:25:57.810
Brendan O'Leary: a free for all. But it's really not right, like what it what it means is like, hey? Would you spend your money to go do this thing? If it was your money, would you spend it? Because you think it's valuable enough to do right? That that makes you kind of make that connection right? And so I think that's a connection that we we all have to like, think through into your point, like, have a plan for before we just go and spend $10,000 to go to a conference.

105
00:25:58.330 --> 00:25:59.100
Dewan Ahmed: Literally.

106
00:25:59.360 --> 00:26:21.310
Dewan Ahmed: And I think whether it's conference or events. One thing that's deeply tied to that is is community like what are the communities targeted, and and you have been heavily involved in open source committees, both at Gitlab in project discovery. How would you say that if someone wants to build a sustainable community, or maybe even

107
00:26:22.070 --> 00:26:23.859
Dewan Ahmed: join another community.

108
00:26:24.390 --> 00:26:25.640
Dewan Ahmed: What would that look like.

109
00:26:26.810 --> 00:26:36.850
Brendan O'Leary: That's a great question. And and it's 1 that you get asked all the time. I think I think part of the beginning is, it's it's it's hard to menu. It's key. You can't manufacture it out of nothing.

110
00:26:37.482 --> 00:27:05.019
Brendan O'Leary: As much as you'd love to do that and so I think the number one right, the most successful open source communities. What? What do they start from? They started from people solving a problem that they had right? Like again, you know. Bias a little bit. Let's talk about get like not get lab, but the Open Source project get like, where did that come from? Well, Lance Torval was developing Linux and needed source control that worked for teams that were distributed right. And

111
00:27:05.020 --> 00:27:09.049
Brendan O'Leary: at the time he was using one that went proprietary and then built.

112
00:27:09.140 --> 00:27:12.576
Brendan O'Leary: you know. Legend has it in a weekend. Get right?

113
00:27:13.210 --> 00:27:36.429
Brendan O'Leary: And why did it? But why did it take off? Well, it's because that he was solving a problem that a lot of people had, and solving his own problem at the same time. And I think if you look at any successful open source community. You'll find the same thing right at Prefect our CEO and co-founder and our CTO. Co-founder, like they had problems with. You know, how do I operationalize all this data science that I'm doing right?

114
00:27:36.700 --> 00:27:46.689
Brendan O'Leary: And it's hard. And I and I don't want to learn another Dsl and put it into like some sort of crazy structure. I wanna I wanna make it simple for people and just use python.

115
00:27:47.071 --> 00:28:14.678
Brendan O'Leary: Right? They solve the problem for themselves. So that's step one. And then, once you've got that, and you have a little bit of a momentum where you can say, Oh, people, you know, do have this problem and are using it. There's lots of ways that you can then sustain and grow it right? So I think the number. One thing that's really underestimated for people is just acknowledging folks contributions to the community, whether that's through code or a lot of other ways.

116
00:28:15.000 --> 00:28:21.729
Brendan O'Leary: you know, like people really underestimate the value of acknowledging people's contributions.

117
00:28:22.530 --> 00:28:36.560
Brendan O'Leary: Early on in in my, in my tenure at project, my tenure here, like my number one job goal was to like, go out and meet people in the community. And we had this one person who's like, Oh, I'm just a student like they were very confused. Why, I was contacting them.

118
00:28:36.560 --> 00:28:55.757
Brendan O'Leary: I was like, no, you wrote this great thing. You showed this example of using Prefect like that's amazing, like, Thank you. And I'd love to meet you and say, Hi! And like, just just doing that, had this massive impact on that person who then now they're like, really active in our slack community. And they're, you know, sharing more things. It's like that kind of leveraged

119
00:28:56.564 --> 00:29:14.120
Brendan O'Leary: kind of work only comes when you're willing to actually acknowledge what other people are doing right, because they're taking time out of their day to spend time in your community. So I think I think that's really the number one thing, and I think that has a compounding impact. There's lots of like tactical things I could talk about after that. But I think that's the number one.

120
00:29:14.700 --> 00:29:22.370
Dewan Ahmed: And, as let's say, maintainers, people want to see like contributions, as you say, like reaching out to the student and encouraging them to contribute more.

121
00:29:22.760 --> 00:29:44.309
Dewan Ahmed: but it can also sometimes create some sort of overwhelming effect where you're like a few maintainers or few leads of these open source projects or communities, and you're bombarded with requests. So how would you say? The the challenges or reality of these burnouts? And what are some of the some of the ways to resolve those.

122
00:29:44.780 --> 00:30:04.409
Brendan O'Leary: Yeah, I mean, if I had all the answers I'd be, I'd be doing something different. But I think I think that the the number. One thing is, eventually you have to have an opinion about what a project is and isn't right. And that that ranges for a lot of things like that applies to the technical side, right? Like

123
00:30:04.620 --> 00:30:26.439
Brendan O'Leary: this is, gonna solve this set of problems. It's not gonna solve this setup. And like, you just have to be okay with that and and kind of stating that. And it's okay like you, you don't have to make. You can't make everyone happy all the time. And so, because of that, you have to choose, like to to focus on the things that you really do want to solve. With this, with a given project, right? Like, I think.

124
00:30:26.600 --> 00:30:47.009
Brendan O'Leary: And and then just being really clear and nice, you don't have to be mean about it. But you just have to say, Hey, we're not gonna do this because, like this is, gonna be outside the scope of what we want to do for this project like you're welcome to to take it and build it on top of it. But like, we're never gonna accept this as a contribution, because it's just not something we're looking to to add, I think that I think that's the number one

125
00:30:47.459 --> 00:30:50.149
Brendan O'Leary: thing to do. It's just to kind of really

126
00:30:50.380 --> 00:30:52.689
Brendan O'Leary: handle the scope of the project. Well,

127
00:30:54.350 --> 00:31:02.330
Brendan O'Leary: And then, after that, I think you have to have, you know, a code of conduct and community guidelines that are really clear and enforced right? Because I think

128
00:31:02.870 --> 00:31:31.550
Brendan O'Leary: it's okay for folks to be excited about your project and want to contribute and want to have it do more for them. That's great. But it's not okay for that to turn into like a toxic relationship where this person is like not happy, and and making the rest of the community miserable, making you as a maintainer, miserable like. You need to have guardrails in place that really make it clear that you're not going to accept that kind of that kind of negativity, or or you know, the wrong kind of contributions.

129
00:31:31.620 --> 00:31:34.059
Brendan O'Leary: And then, lastly, I think you know

130
00:31:34.180 --> 00:31:50.450
Brendan O'Leary: again the going to scope. It's like you have to be really clear with people like, is this a side project that? Yeah, I'm going to get to every now and again? Or is this something that I am trying to build into something bigger? And and then people should have expectations that align with that?

131
00:31:50.560 --> 00:31:53.510
Brendan O'Leary: So I think I think those are the kind of the key things.

132
00:31:54.050 --> 00:32:11.399
Dewan Ahmed: Totally agreed. And as you're like in the early days of your open source, communities like the people you're working with, they can be your champions, like the active contributors, let's say only few maintainers. They don't have to take on all the work they can delegate, and an active community means that other people are also

133
00:32:11.400 --> 00:32:27.010
Dewan Ahmed: responding to threads, and besides, like the code of conduct you mentioned, people can take use from those tools like stalebot, like you have a bunch of issues. Those are old issues. You don't have to go and close it yourself. There are like other tools out there

134
00:32:27.010 --> 00:32:27.520
Dewan Ahmed: not to help.

135
00:32:28.130 --> 00:32:30.280
Brendan O'Leary: Exactly, exactly.

136
00:32:30.280 --> 00:32:40.099
Dewan Ahmed: All right, switching gears to to personal and work life so that of 4, I believe. How do you balance a high profile? Tech carrier and your family.

137
00:32:41.456 --> 00:32:49.040
Brendan O'Leary: Yeah, that's a great question. I think you know, I think I learned a lot at at Get Lab about this, too.

138
00:32:49.477 --> 00:32:55.050
Brendan O'Leary: Because we had a we had a saying there that it's family and friends, 1st work second.

139
00:32:55.170 --> 00:33:05.452
Brendan O'Leary: and I think you kind of have to have that attitude eventually in your life. I I have not had it my entire life, like I I I say that I'm an in recovery workaholic right?

140
00:33:05.790 --> 00:33:18.927
Brendan O'Leary: and and then developer relations in an open source. That's like very easy place to feed that demon right? Because there's always something more to do. There's always another issue that somebody's hoping there's always, you know, another another thread to read

141
00:33:19.240 --> 00:33:42.059
Brendan O'Leary: And so I think I think that you know for me it has been 1st accepting that there's always gonna be something more to do at work. And and 2, I've got to put, you know the family first, st because with 4 kids. It's like, it's like, really like, kind of not an option, right? There's just too much to do for me to be, you know, disconnected from that, and you know it. It means that I'm you know.

142
00:33:42.390 --> 00:33:47.140
Brendan O'Leary: I I kind of have embraced what I call like a nonlinear workday. So

143
00:33:47.150 --> 00:34:08.240
Brendan O'Leary: I'll you know. At 3 30 my kids get home from from school. I won't work from 3, 30 to 4, 30, maybe right? But I may come back at at, you know, 8, 30, and do something if I'm if I want to or I won't right. It just means that I've you know, found ways to kind of fit work into my life rather than the other way around.

144
00:34:08.239 --> 00:34:26.479
Brendan O'Leary: Now, having said that, you have to have leadership support for that, right? So like it's gonna matter who you who you work for our CEO? He's got 4 kids as well, which is helpful. But he picks up. He has, you know, a couple of days a week that he's he's doing school pickup right? And so he's like, I'm again 3 o'clock. I'm not gonna be around for a couple of hours.

145
00:34:26.923 --> 00:34:36.400
Brendan O'Leary: And so that kind of, you know, sets a tone, I think, for a business. And so you've got to. If you're a leader, you need to set that tone really clear and and not just

146
00:34:36.863 --> 00:34:43.536
Brendan O'Leary: I think the key thing for leaders here is not just doing it, but like being really public about it.

147
00:34:43.949 --> 00:35:07.659
Brendan O'Leary: We had our a cro at Gitlab, who again had small children, and now now we're in the pandemic era. And for those folks that had children in the pandemic, you became like also like substitute teacher, right? Because school was at home. And our Cro right? We're this high growth startup that's got to hit numbers right? Like, you know, sales numbers, as everyone knows at a startup are always like, you know the number one thing.

148
00:35:07.660 --> 00:35:23.359
Brendan O'Leary: but the cro at the time would say, Hey, I'm gonna be off this afternoon because I got to do homework with the kids right. And he would say that in a public channel like on slack, and that makes such a huge difference, because then people can see and absorb. Oh, no! This is the way I should live my life

149
00:35:23.380 --> 00:35:26.359
Brendan O'Leary: right, Sid, the CEO

150
00:35:26.790 --> 00:35:50.459
Brendan O'Leary: would say. You know, if you're the one that works at gitlab. You should be the one picking up the kids from school right? Like you gotta have that that mentality from the top down. And so if you're a leader. You need to lead with that. And if your leaders aren't supportive of that kind of balance like, you know, that's that's it's gonna be hard but you can try to lead from the ground up, or you can try to find a leader that that does support you.

151
00:35:51.390 --> 00:36:03.970
Dewan Ahmed: Lot of valuable insights and fantastic lessons. If you want to sum up what we discussed today for our listeners like 3 key takeaways, they could take from you, and you can see, like from your combined

152
00:36:04.290 --> 00:36:08.760
Dewan Ahmed: years of experience in working in tech, what would be some lessons be.

153
00:36:09.550 --> 00:36:33.259
Brendan O'Leary: Yeah, I I again, I think writing things down is a superpower. Right? I wrote about it when I when I left Gitlab, as as the thing. I didn't want to forget. And I think that applies to a lot of things right that applies to having work like balance right? If I write something down, I know it exists. It applies to how our open source community is gonna work together right? Like that. Writing things down, you know in github or gitlab, wherever you're collaborating, is really critical. And

154
00:36:33.280 --> 00:36:47.199
Brendan O'Leary: then it also helps your decision making right? We talked about the decision making process of like, how do I choose a tool? Right? I think again, writing things down can really help articulate to the team. What? Why, we're choosing to build versus buy, for instance.

155
00:36:47.718 --> 00:36:53.441
Brendan O'Leary: So I think that's the one thing that I would say like, write write more things down. It's gonna help you out a lot,

156
00:36:53.740 --> 00:37:04.800
Brendan O'Leary: and then, like again, I think the next the the other takeaway would be, you know, giving trust and agency to your team. If you're a leader. You know, if you're you've hired people because they're smart people.

157
00:37:04.800 --> 00:37:23.969
Brendan O'Leary: let them go do their job, you know. Give them ownership over decisions, trust them to spend their time and money wisely enable them to work flexibly. I think that builds loyalty better than any other incentive that you can. You can offer people and it's gonna make them, you know, that much more efficient.

158
00:37:25.060 --> 00:37:26.209
Dewan Ahmed: Couldn't agree more.

159
00:37:26.400 --> 00:37:27.090
Dewan Ahmed: Oh.

160
00:37:27.410 --> 00:37:53.630
Dewan Ahmed: for folks who are listening or watching this, please start your personal blog if you don't have one already. When I started my personal blog. One of the best decisions I made as Brendan shared like, write more. You can't write enough, and I think once you have your own blog, sharing your own thoughts. Not only you can look back, but other people who were in your shoes. They can read from your experience and learn.

161
00:37:54.300 --> 00:38:02.509
Brendan O'Leary: Pretty sure people would love to like, connect to you. They'll learn more about your work and get involved with the projects you're part of how they can do that.

162
00:38:03.080 --> 00:38:19.800
Brendan O'Leary: Yeah. So I'm at O'leary crew. Most places on the Internet, or you can get to my website, which is B. O'leary. So BOLE a RY dot dev, that's my blog, and then it also has all the links to to, you know blue sky and Twitter X. And all the other places she can find me.

163
00:38:20.340 --> 00:38:36.250
Dewan Ahmed: Sounds, fantastic thanks, so much Brandon, for joining ship talk. Podcast we'll link all the links you mentioned in the video, description or in the podcast, this was shiptalk podcast, and we had a fantastic episode, learning from Brandon's

164
00:38:36.250 --> 00:38:51.929
Dewan Ahmed: experience, working in product strategy, working developer relations, sharing his insights about open source as well as how to strike a balance between family and work. Thank you so much for listening, and we'll see you in the next episode