 Hi all welcome Ben Cotton while he presents his talk herding cats program management and communities with us We'll be starting shortly Hi, welcome to herding cats program management and communities. I'm Ben Cotton I'm the Fedora program manager at Red Hat. This is kind of my day job here that I'm going to tell you about As want to be clear This is herding cats as in getting them cats to go in the same direction not herding cats Which is bad and you should not do no hurt the cats so If you have nice things to say about the talk you want to interact. I'm happy to talk with you about it There's my Twitter handle. I'll be around for Q&A after the talk, etc If you have not nice things to say you can just keep them to yourself because nobody is harder on me than I am All right, so let's get started What is program management? You might be asking yourself that maybe it's why you came to this talk to learn a little bit about it and I'm here to answer that as soon as I ask this question What is project management? similar different let's ask so The dictionary Doesn't really talk about it, but I've come up with the dictionary here for you Projects have single focus results and a defined end a project is over at some point It's really focused on producing an output. Here's a thing that we made. Isn't it nice? Okay, we're done Programs are made of made up of projects. They are composed of projects But they don't have a defined end and they're really focused on an outcome world domination for example and while Things like the Fedora project are called a project They don't actually have a defined end and that's just because people who don't understand the distinction between the two came up with the names and project is a common word in open-source communities like The Thora project this project that project and they're not really projects in this sense And we're gonna be okay with that Because words are flexible and they don't have to conform to our very strict interpretation So the question I asked what is project management? So I asked the project management Institute and it seems like the kind of thing that they would know and they say The application of knowledge skills tools and techniques to project activities to meet the project requirements That's not helpful. That's not helpful at all Okay, so I came up with something for you It's basically working with project teams to balance these constraints time cost scope quality If you adjust one the others are connected and they will have to adjust in some way A lot of times time cost and scope are considered the iron triangle of project management So you have this triangle and then like you tie a hot air balloon That's quality But apparently quality wasn't in a lot of the early project management literature because I guess it was either taken as an Assume that yes, we're not gonna make crap or that they just didn't care You can look at the state of the software industry and decide for yourself, but Everyone does project management some just do it poorly None of things none of the things in this talk are gonna be like particularly new like Even if you're not thinking about project management or program management You're probably doing the activities in some way or you're failing to do them Which is also a form of doing them. So what is program management? Well, once again, I made the mistake of asking the program project management Institute And they said the application of knowledge skills tools and techniques to meet program requirements Why they took out program activities in this one. I don't know But once again, not a helpful answer So I answered it for you again so basically it's like project management, there's just more of it and It's at a little bit of a higher level generally So it's more about coordinating between projects and activities Sort of the intersection the boundaries between silos or not silos if you will And it's less about involvement in the specific details Like you don't necessarily care that on this day this activity happened and on this day this activity happens If it's all internal to one team basically you want to know when does this thing affect the other parts of the program? except turns out when your day job is this thing and You just paying a lot of time volunteering yourself a lot So even though my job is program manager, there are still some project manager kind of things that I do sometimes because It makes the overall program successful And there are things that are totally outside the scope of my job that I do like edit for Fedora magazine or update website Or all kinds of random things that I sort of pick up here and there because nobody was doing them and now all of a sudden I'm doing them Responsibilities accumulate without bound. All right So what is program management, right? That's why we're here. Let's look at the constraints here. We have time time is about managing schedules and managing the schedule doesn't mean you set the schedule. So if you're acting as the program manager for your Program your open source community your project You know, I say the one that sets the schedule But you're sort of in charge of just knowing where we are in the schedule and knowing where we're supposed to be And it very much does not mean being held responsible for executing the schedule Because there's only so much you can do Managing schedules is building out the schedule Communicating it updating it and consulting on schedule related decisions. So I talked about, you know, things being interconnected and One point I had a conversation with but or a release engineering about oh Can we move this milestone a little bit because it always conflicts with our conference? And I said, yeah, that makes sense Here are like four different scenarios that we could do and one of them involves shortening, you know, the Time for beta testing one short, you know Shorten the amount of time developers had to complete their work and it turns out there's just a lot of complexities when you move one point in the schedule because now you're affecting other things that have to be done as dependencies or as downstream activities and Being the one who manages and wrangles the schedule puts you in an ideal position to be able to speak on the impacts of those things So why would you even have a schedule? Well, users care because they might want to know when this new feature that you're working on or this bug fix It's bobbing them is gonna come out. They might want to time their upgrades to You know, make sure they have your latest version before they do their thing or whatever Your downstream scare so if you're you know writing a programming language the Linux distributions that package it up will probably want to know when it's gonna be available desktop environment stuff like that if you're say a community developed operating system and you have a Corporate enterprise operating system that is built from that. They would like to know When you're gonna release and when certain activities happen in your schedule Your up streams probably don't care, but they might You're a major downstream for that upstream if you're the reason that a lot of people if that's how they interact with your software They might want to make sure that they have their release in time Release especially for Linux distributions like, you know, a desktop environment or you know, major package that you know provide some sort of user Interfaces or like database servers or things like that things that people would want in their distribution You want to be able to not have to wait till the next distribution rolls around And there's a little bit of like how else will you know it's done because software will keep adding features Until it can read email and then it'll keep doing more and it'll slowly just take over the whole world So if you have a schedule, you're like, ah, yes, the schedule says we're done today So there are a couple different types of schedules. These are very broad brushes here But there is the calendar based schedule like fedora uses there is a feature based schedule Which is basically we'll release when we get this this this and this done and they're sort of the it's done, I guess Uh model which, you know, isn't necessarily super helpful but for small projects, especially with a development team of one That's probably fine you could do worse So calendar based schedules To build those out you start with the target release date and you work backwards So if you say we want to release on february 30th Here's all the activities we need to do to get up to a release and how long those take and you find out You needed to start work three months ago. You say, uh, oh You probably planned a little head a little better than that So how do you pick that that target release date? Well, you might have upstream or downstream release dates that are important So you look at those schedules and say, all right, well, we need to have this done by then so we can Incorporate that or our stuff can be incorporated into that release You might just have tradition, you know, we've always released on january 32nd, so we'll release on january 32nd this time too You might have conferences or events that are important to the ecosystem you're in And you'd really like to be able to get up on stage doing your keynote and talk about this great thing that you've just added And it's available go download it now But it has to be like available to download so you want to have it done by then There might be some fun dates. So like if you're developing stuff around raspberry pi pi day is a very, you know, popular day because it's pi day It's like writing the name, right I already made to say well, you know In eight months, we typically have something that's different enough that we feel justified in calling it a new release So we'll just release every eight months because that sounds nice Or we'll do it once a year because by the time of year rolls around things will be different enough and that's a new release then That's fine. You can also do feature based schedules That's what that you start with your target feature set and you work forward You say here's the list of the things we want to do. How long will it take us to do that? Okay So how do you pick the feature set? Well, how different do you want the next release to be? What justifies a new release if you fix one bug where it's like you had a comma in the wrong place in a GUI menu Is that justifying new release? probably not If you've rewritten everything in a whole new language and everything's brand new from scratch. Yeah, that probably justifies a new release So then you think about how interdependent are your changes? if you change a Do you depend on bc and d to also get changed for things to work? All right, that should all go together If everything's just sort of independent and modularized and microservices and all that cool stuff that the kids say these days Things kind of pick some because you might say well We don't really want to make it a calendar based release, but we also don't want to wait seven years until our next one Because you can't avoid the calendar Sorry, even with feature based releases calendars still exist And then you can have the it's done. I guess schedules where you just wake up one morning like it's release day I've decided and like the the command line twitter client that I supposedly still maintain That's basically how releases work. I'll sit. I'll have some time I'll sit down and get a few things done and then I'm like, all right. Well, I don't see myself doing anything for Hey, it's a release now And that's fine If that's what works for you and it works for your user community So here's some things you want to consider about as you develop a release schedule Even think about what milestones you need are there deadlines for proposing features or having code complete? Do you have merge windows or branch days where you you know bring in the changes into the main trunk? Or you take the existing branch and you branch off this release so that you can Continue doing forward development in the main branch Or however you do it Do you want to have testing windows or you basically have a freeze and you say the only thing that gets in or Fixes for these bugs we find Do you want to have certain releases like, you know alpha and beta or do you want to go straight to ga? How far apart should those be stuff like that? You want to think about conflicts? So interesting quirk of the fedora schedule is that it turns out that the mass rebuild always starts around For the odd numbered releases It starts around flock, which is our annual contribute fedora contributor conference For the even numbered releases it starts around dev con check That's just sort of an accident of the schedule and it turns out that moving that things around it just became a little bit of a problem for other reasons But you want to be aware of if there are conferences that are relevant to your Community that you maybe don't try and get a whole bunch of stuff done During or right after people are you know traveling back as you know conferences used to be like back in the day Uh holidays are important to think about but holidays are really interesting Especially when you have a mix of paid contributors and volunteer contributors Because your paid contributors will often go off and do something else on holidays because they're not there to work anymore Your volunteer contributors might actually show up and be doing more stuff Because they're not at work. So they have time to work on their hobbies Your paid contributors sometimes are also volunteer contributors. So they may just keep working the same no matter what happens So it's interesting that you look at like the fedora activity. You can see a remarkable drop in activity the last week of december red hat has a holiday shut down And people who aren't working for red hat are also doing things like traveling to visit family or just spending time with family And some people are doing stuff to escape their family whatever But for the most part, especially with You know international communities There's almost always a holiday somewhere going on and so things just kind of smooth out But you want to be sure that if there's you know, if you have a really strong Uh contributor core in a certain region and there's a major holiday then Don't plan on having a lot of activity for that You also want to think about schedule changes. So if you move one date Others get impacted. You're either shortening a window until the next milestone, which might be important Or you're lengthening one or you're moving up a deadline And again, this is not a thing where you can't do that But you want to be considerate of what that actually means for your development cycle And here's a fun one Public perception is something to consider when developing a schedule Because not all one week slips are created equal Uh the marketing and the public perception matters whether you like it or not And so using fedora as an example again Um a while back we decided that we were just going to basically use the same cookie cutter schedule Release after release because that all basically looked the same anyway So why bother going through the whole approval process every six months when it's going to be the same thing? But as part of that what I did was I decided that the third Tuesday of april and october would be our target release dates Because that made our alternate target The fourth tuesday and you're like, okay If we moved it back one week so we're alternate target or you know initial target was the fourth Tuesday then all of a sudden That one week slip moves into may or november and Historically fedora has had some problem shipping on time Um my predecessors last release was our first one where we you know shipped on time and we haven't broken that since knock on wood but you know we have Unfairly now a reputation for being late and so if we can Slip one week and still haven't been the same month that sounds a lot better to people and it's less public perception That's reality folks So what to do when your schedule is wrong? Well, if it's calendar-based you can cut your troublesome features Or you can slip the release date If it's feature-based you can again cut your troublesome features And if it's mad It's done I guess then the schedule is always right because it doesn't exist and you just wake up one morning and decide it's release day But what you say if I was too pessimistic And I will tell you to stop lying to me because you're never too pessimistic Um in that case you can release early. You can add more stuff. You can just relax. You can do more testing Realistically, it's not a problem that comes up very often. All right, so let's talk about cost cost is people Community projects don't only have a budget necessarily Um, they don't have a lot of dollar costs. I mean there are costs in keeping things going But you know, it's not like you're losing out on revenue or whatever But people their time is valuable whether they're doing this on their own time or somebody's paying them to do it Like you want to respect the time they put into it Ah, but you don't have control over the people do you? So your job as the program manager is to help the people coordinate And make sure that we're not Running behind because we weren't talking to each other So communication is key and you'll see this word a lot more in the rest of the talk There's so much information out there, especially in a large project say the size of fedora So much going on on a variety of different mailing lists So distilling things into highlights helps meetings meetings meetings meetings meetings It turns out meetings can be good Not necessarily fun, but the productive and they advance, you know work You can do them via text via phone video, whatever works Think about what works for your community though Because in some places People don't have the bandwidth available To connect to a video meeting and have it be reliable People might not be comfortable if you know if your project runs on English and people You know who are English as a second language or third or fourth, you know non-native English speakers It might not be comfortable with their spoken English, but they might be better written But no matter what format you use you want to take notes It's one thing I really like about IRC meetings is there's a bot that takes notes for me I just give it a couple commands and it does all its thing. It sends out an email. It's great But you also want to make sure you have an agenda and that you stick to it It should be clear why you're bothering to have the meeting and keeping people on track can be hard But it's important because sometimes things will just go on forever and ever because some people like to talk The other thing too is to you know, don't let decisions Or don't let meetings be the only place decisions get made Because not everyone can attend your meeting Some people have to work. Some people are asleep. Some people don't have the bandwidth to join you know Decisions are best when they're made asynchronously and you want to make your synchronous meetings As accessible as possible to your community But you don't want to shut people out of decision-making process because they can't join the meeting So speaking of channels I'm a really big fan of having one asynchronous tool and one synchronous tool So a synchronous tool like a chat like IRC or telegram Or whatever chat system you want to use And then one asynchronous tool so a mailing list or a discussion forum, but not both Because you really don't want to be splitting the conversation Well, we talked about that in telegram and that in IRC and that on matrix And that was on the mailing list, but that was in the discussion forum It's hard to keep up and yeah, you can bridge those things together and maybe that's a solution for your For your community But really having a single play safe. This is where we communicate Is uh going to make life easier for people You want to keep the barrier to entry low No matter what tool you use It's good to have archives. Those are usually your friend There are times when you need to have private conversations that aren't archived, but the The default should be we're logging this and it's going to be available later Because not only is that helpful for people who want to learn more about your community to see how it works or to You know people who are going to write news articles about your releases or something that can see what's going on But it's also really helpful to you So I can I lost track the number of times I've had to go back and look at an email thread from six months ago I'm like, oh, yeah, that's why we decided to do that. Okay. I can do this then The other thing that's really important. I talked about there being a lot of information out there So moderating a channel for important messages Is important you want something where the assumption is Everyone's going to subscribe to this and if it comes out on this channel, we expect you to read it The the other side of that coin is only the really important stuff is going to get through here And it's going to be low volume So for fedora, we have a development mailing list where lots of discussion happens on a variety of things Then we have an announced mailing list where every message has to be approved. So accidental replies Those go away Basically, only things are like big important announcements. You must pay attention to this goes through there That allows people who don't want the deluge of all the messages to still still see the important announcements So let's talk about scope And scope is really like managing your changes or your features or whatever you want to call them I'm going to use the word change here mostly because that's the process we have in fedora We used to have a feature process the changes process replaced that it's better. I've given a talk about that Talk to me about it later So I have it communication You're receiving feedback and then more communication. Like I said, this word comes up a lot Now the process is going to vary by the size and when I say size here, I'm not talking about lines of code That's the number of contributors who are participating So you want the weight to be proportional to those sides Because what happens is the number of communication channels the connections between individuals is exponentially related to the number of people doubling the size of Of group more than doubles the amount of communication lines between them So if you look at this graph You have really big project with a relatively heavy weight process like fedora's My command line twitter client has an effective development community of zero, but really but one And so it has a very lightweight process, which has basically been did a thing. Okay Your project probably fits somewhere along that axis And so you when you think about it think about what's appropriate for your community for the the volume of people and the work you're doing So if you're developing this kind of process, what do you want to think about? Um, who should validate the change check it out to make sure it's reasonable. There's release engineering. We'd be like, yep, we can do this Do you have a legal person who's like, yep, that license is good. Nope. We can't do that. We're going to get sued Do you put it in front of the community for a general review? Who defines what the community is? How do they review it? And then separately that's this is important. Who approves the change? Because people can have input without actually being allowed to vote on it So you could put it up to a community vote where everyone gets to say yes or no and you take a majority vote or you have two-thirds majority or whatever You can have some sort of technical steering body Who is a small group of people that makes these kinds of decisions? You can have a single project leader who, you know, speaks with authority on all things and they decide On their own what goes in and what stays out So my opinion, and again, this is probably colored by this being what fedora does Um, democracy is really messy. We may have learned over the years Um, and some people will only show up to complain but then not actually make contributions to your community And maybe that's okay with you. Maybe it's not Um, but if you want to get decisions made in a Reasonable-ish timeframe Having an elected technical body to approve the changes is a good approach Assuming your project is, you know, big enough to justify it. If there's three of you, you two, you three can argue it out If there's 300, you might want to have a few people who get elected every few months or every year or whatever And they are the ones that votes on things because then you're still and the elected part's important Because that still gives the community a vote. It becomes a representative democracy instead of a straight democracy And if people don't, if your community doesn't like the direction that the technical body is taking it They can vote them out. You don't have to do it this way. This is my opinion Again, so some considerations you want to think about here Is what happens if changes can flip if you and I both say I want to do this thing But these things are mutually exclusive. Who decides what goes forward or how that gets resolved? What happens if I make a change and it breaks something which would never happen? But if it did You know, who decides what to do about it? Who has the authority to back it out? And what happens if changes are undelivered? If I said, yep, I'm going to do this thing and then I go off to the beach and disappear and never actually do it Quality tests are good. It's good to have tests preferably automated because that people are expensive. We went back to, you know, people have costs Um, but you know manual testing is important for some things and whatever But more than that, you want to have some release criteria. You want to have, you know We must be able to do this this and this and this thing may not happen in order to release it So you may have a criteria that says when the user upgrades It will not remove all the data on their system and turn their computer into a giant molten pile of metal People will appreciate that and having release criteria can be helpful for, um Building trust with your users because they know that you've done at least some degree of validation But it's also important to consider that not every bug can block the release because otherwise you will never release So you do want to have some way to sort of triage these important But not enough important enough to block bugs and maybe prioritize getting those fixed first after the release All right, so how do you do all this program management stuff that I've been talking about? And there's a lot more that isn't covered because I only have so much time to cover a whole lot of different things But it's the time being how do we do this? communicate Communicate communicate That's the core of my job. I send email. I receive email. I publish blog posts. I review blog posts I attend meetings um, one of the first things I did when I Uh became a thorough program manager I made a list of all the meetings that are going on and tried to make it to almost all of them At least once just wave my hand say hi. I'm here. I'm paying attention. I know you exist come to me if you need help And I am on a lot of mailing lists where I don't actually have any intention of ever doing anything In that part of the community just because there's only so much I can do or I just don't have the skills for that But it's still important for me to know what's going on and to be able to Spot issues and try and help people out So there's a lot of listening that goes in. There's also a lot of talking outward communication Um, so I do a weekly blog post where I say here's all the stuff that's happened this week That's sort of a high level, you know Here are the changes that were submitted and here's some upcoming important meetings and conference deadlines and scheduled milestones and all that stuff I have regular office hours, which people almost never attend But that's okay because sometimes they do when we talk about things and the rest of the time I'm there if they need me, but it's important to be available and visible to the community And then also public issue trackers or can band boards or something So that people can see what you're working on and they have a way of letting you know Hey, something's broken. I need help with this thing or whatever So most of the things I've talked about here Are just program management in general Whether it's corporate programs or community programs. So how is it different in communities? Well, like in companies people don't really appreciate process and bureaucracy for the most part They want us to be able to do their stuff and not worry about making sure they checked all the boxes and did things and blah, blah, blah Also, like in companies, you might have any direct authority over the people who are working on stuff And the job is really all about communication and coordination So here's what's different communities You can really only lead by influence so It took me about six months before I was comfortable saying no Go go redo that because that's not what you need to do for this process Before that is like, you know, I'll fix that up for you before I send it along. It's fine And that's because it takes time to build credibility and even though I'd been a contributor to fedora for a long time I was sort of off on the side a lot. I wasn't necessarily very visible And people aren't going to listen to you just because you have a title you need to establish that Yes, you know what you're talking about and you're going to be helpful and you're here to make things better You have to show the community your value Because you can't go complain to somebody's manager when they're not doing the thing Because there's not a manager for them to complain to because they're doing this in their spare time So the most important thing to remember If you take away nothing else Is that whatever process you develop the process is here to serve the community The community is not here to serve the process And if you find yourself trying to adjust the community to serve your process that means your process is long And so with that we are out of time So I will stick around for your questions and I appreciate your attention Once again, if you have nice things to say There's my twitter handle. You have not nice things to say you are cordially invited to keep those to yourself Thank you very much Thank you so much ben for an amazing presentation and now we would like to have some questions if there are any And if you have a question and don't feel like typing feel free to request to Join with audio and video So neil ask what was the hardest thing for you when you started being a program manager? I think for me it was Knowing all the connections You know fedora is a huge community A lot of people have been around for a long time and you know So even though i've been contributing and there are a lot of names. I'd recognize over the 10-ish years that I have been a volunteer There are a lot of parts of the project that I just hadn't touched yet And so learning all those connections and trying to Understand them and you know insert myself or appropriate without getting in the way Was really hard Carsten asked do you network with other program managers who work on other open source projects both inside and outside of red hat? so From an hr perspective i'm on the team At red hat that does all of the program management for rel Specifically so not any of the things layered on top of it, but just the various red hat enterprise linux distributions One of the things i've really wanted to do And it just haven't done yet because it's a big undertaking and there's only so much time in the day Is to sort of put together an informal group of people who are um You know doing similar roles in other community-driven uh operating system distributions or other you know very large projects And sort of build a community of practice i guess around that Um because there are a lot of things i think we can learn from each other Um, but if there is one of those it's very secretive and hard to find so um I would have to start it or talk somebody else into starting it um, but i think you know like i said in the talk Even if you don't have the program manager title and even if the functions aren't done by one person The work is being done somewhere in the project So it's uh, you know It's good to build that knowledge especially for people who don't have the benefit of Having sort of a formalized role I think there's a lot of things that you just sort of start doing because you realize it needs doing but you don't get the benefit of You know the interaction and some of the historical knowledge that gets handed down Uh from like for example from my predecessors Yes, uh, definitely be happy to talk to you later about bringing that into the open source way Or talking to you about it now if there are no other questions Hi friend Hi there. Wow. Apparently I can just make myself join Cool. Um, yeah, that just if I don't want to take over, you know other things But but I hadn't even thought about this and necessarily tell you said it and I was like, oh, yes That's like that's community of practice stuff. I mean, I don't know um, I do we have other people we know I mean Amy scovarta comes to mind right away who's you'd experience program manager in another organization There's a lot of people out there doing very similar kinds of things so You know, I don't know if we'd be happy to facilitate that or coming up low Jesus Hi, neil. Hey neil. Yeah, I think that'd be good because like, you know Certainly in my role and I think Fairly broadly across red hat I may be the only person whose full-time job is being a program manager in an upstream community Uh, you know, we definitely we have people working in like community architect roles who you know, they do some of this work We have people Involved in other upstreams in different ways, but I don't know that we've formalized any other upstream role like this anywhere and the Projects that red hats involved with so I was actually just a little unique about that because You know, you know my experience operating in so many different communities is that I think you're actually one of a kind um, yeah, like uh, so Before those who may not know I actually operate in lots of linux, uh and operating system communities and Ben's particular role is unique to To the governance of fedora because in other linux distribution communities even large Semi-corporate backed ones or fully corporate backed ones There isn't an equivalent position held by anybody in open susa community manager project owner and and Director whatever you want to call it like these all these little functions that that in fedora are split up across four different people one person And then there's in ubuntu where they have the community council thing which has been um, I don't know if you saw recent news Uh, it's not much of one at the moment But hopefully it will be again, but like that was an all volunteer position that operated um that function of the of of the ubuntu community and debion being a um Essentially owned by a charity right spi owns them. That's how they operate. They don't have And their culture does not permit them to have such a role at all They don't have a way for people to coordinate at scale in the same way that you do But what is interesting though is that you're right people who don't necessarily have that title Wind up doing it anyway, right? It just shows up because it kind of needs to be done so I wonder one thing that I wanted to ask and it just didn't it was too slow to type was Have you tried reaching out into the other community to see who those people are? And to see what is similar and what is different between the formal program manager and the informal Like it kind of just happened program manager type Not really. That's you know That's kind of part of what I what I was talking about like wanting to do is you know Seeing what other communities are doing and how they do it. Um, I've talked to lubos a little bit at open susa um And like we've compared notes on a few things a few times, but you know, there's not really like a Like I'd love to start a mailing list of you know people who do these sorts of things and just You know get together every once in a while and and talk about the things we do in our jobs Um, but it's kind of hard. It can be hard Especially from outside the community to try and figure out who are the people in that community doing the job especially, um when it's split across, you know, three or four different people doing the same thing that that I'm doing Right, but the least if you start gathering practices together and start gathering people who are doing parts of those jobs This is just because that's kind of Yeah, that's what happens with open source where people take saunt take on multiple roles Well, um and to some degree you might because I remember how this world started in fedora It started because somebody started to pull the practice together and was doing the job Sort of not exactly formally, but wanted to get to that wanted to kind of Untangle those bits from the from the project lead who was having to do all that stuff too And then in that untangling to find a role for themselves that move forward And so this is other people can do this if we give the people those untanglings to some degree. So and I see this question Yes, that's true too. I see there's a question from david and chat I don't want us to take over from so he said um, he said he finds one of the big issues that come up here Is that of not having influence in places where you have responsibility? How do you identify and track that in a way that makes sense That's a hard one. Um, you know, I influence There are places I don't have influence and You know, I try um Sometimes you just have to be very patient over months or years to build that a lot of it is Volunteering to do things that you hate doing because somebody else hates it and like, you know I'll take this work off your plate for a little bit And you can focus on that other thing um And you know, it's very much like an exchange of favors kind of thing um You know, I think a good program manager is always owed a few debts by everyone Um, because then you can call those in at some point um And you know, some of it is just being Sometimes you have to stand up and assert yourself even if you know, you're going to get ignored Uh, and then you go back and say, you know like I did it. I did what I could um it is helpful within You know within fedora that there are a lot of people Who work at red hat? um And are working on fedora at least in part on their day job because those like in those cases I can't escalate things to managers, especially when it's, you know, release criticals. I can go to them and say Hey, I need help and it's not it's very rarely a hey your person is a screw up It's more of a hey, this is a big priority. Can you reallocate their time a little bit for another week or two? um, and you know one thing that my manager made very clear during the interview process and when I first came on board was I'm not going to be held responsible for the timing of fedora releases Because like I could do my job poorly and things will kind of fall apart a little bit like we'll still manage But it may be maybe won't run as smooth But there's nothing that I can do if everything else is falling like I cannot fix, you know The the process, uh more generally um, and so um I think sometimes you have to be willing to accept that You've done your best and everything still went wrong um, and it looks like uh We're closing in a few minutes so Yeah, you can go for a few minutes more if you want okay Okay, uh, are there other questions and if you want to continue the conversation We also have breakout rooms under the expert tab. I just linked it in the chat. So feel free to head there after All right. Looks like there's no more questions for you, Ben. Thank you so much for that talk Thank you