 Welcome everyone. Let's go ahead and get started. So hopefully you're in the right room or on the right stream for our talk about your open source program office, your program management and you. I'm Dwayne O'Brien. I am the director of open source at Indeed. I've been working open source program offices or OSPOS. Hopefully you know that acronym. If not, you'll hear it a lot today for about nine years. I get really excited about open source sustainability. My opinions are my own. I'll say some things here that I think that maybe Indeed doesn't think. And I'm basically Professor Farnsworth from Futurama in that I have a lot of mad science ideas. I love delivering good news to everyone. And left unchecked I would do all of my work and bath robes in a slippers. And I'm Talia Tepling. I'm a director of technical program management at Indeed. I've been working in program management organizations or PMOs for about 12 years now. I am really excited about the Seattle office. Unfortunately, it's called a soccer club in the U.S., not football club. We're working on that still. My opinions as well are my own and reflect my experiences working in PMOs. And I'm also a Queen of the North based in Seattle. So how many folks are a part of a PMO here? Awesome. More than we thought. How many OSPO folks are here? How many of you think companies that have a PMO and OSPO are both? Good showing. Good showing. More PMO folks than we thought which is super exciting. We're really glad you're here. And OSPO folks we hope you bring your PMO folks with you next time. So this is sort of the genesis of the talk. This is a thought that keeps me up a lot at night. I run a program office that runs programs that look nothing like the programs run by program managers to whom I bear little resemblance. And if you've worked in and around OSPOs, if you've been an open source program manager, you have felt this pain. I saw some nods as I was going through. I think about this late into the night at least once a week. So a quick rundown of how we're going to talk about the subjects today. Talia is going to give some PMO fundamentals for those who may not be familiar with those organizations or deeply familiar. I will give some OSPO fundamentals so that we're all on the same page and have some shared understanding of what we're talking about. And then we'll talk about the friction points that we found when we started working together and four examples of how we fixed on those and worked on them. So, PMO fundamentals. You've got this thing called the PMO. Some of y'all are birds of a feather in here with me and you'll know what I'm talking about. Everyone else who doesn't go tap these folks while they're in here. They're great resources. So let's define a project. But before we can even tackle that a project is not an open source project, we've got to talk about the three types of projects in PMO organization. Project, program, portfolio. So let's now jump into project, not an open source project. They're time bound and they deliver results or an output very concrete. And then program, not your open source program office, but within the PMO programs are time bound. They are groups of related projects that benefit from being managed collectively to maximize a business outcome. And then portfolio. That's a collection of projects, programs, other work that group together because it's effective to manage them together to meet strategic business objectives. So we go from a result or an output to an outcome to business objectives. So there's a laddering trend that you'll see. And then how do you go find your PMO? This image here kind of shows the different mashup of how organizations through their levels of authority or types. You have your project management offices, your program management offices, portfolio management offices, spans of control across different levels you might run into in your organization. And your company might have only a project management office, only a program management office, only a portfolio management office, or a mashup of any of these. And then what else do you go look for? So say I can't find it across that span of control. There are three different types, the supportive, controlling, and directive. And the supportive PMOs are really kind of best practices, are templates, tools, some ways to work. Controlling PMOs are really about that compliance and adhering to those templates and best practices. And then directive PMOs bring all these pieces together so that you can manage a piece of work to a successful endpoint. And at Indeed, we are a mix of all three. Here's some real examples. So our PMO members at Indeed, and I know I've got at least one in the audience, can attest to this. We drive cross-company efforts that deliver our top organizational priorities, so company-wide goals, multi-business unit goals and projects. And those are the priorities that are specific to the company and in partnership with specific business groups and usually an executive sponsor at the vice-president level, sometimes even higher. And for a hard, concrete example for y'all, I led the migration to our primary cloud provider that got rid of data centers, that changed how every business developed and pushed code to production. In partnership with the VP of Engineering, any massive group of different roles across the company. So that's the reach, scale, and impact we're talking about when we talk about a program management organization. Up here I've got a bunch of resources for y'all for access later. They're really common MSP managing successful programs is more common in the U of Princeton as well, and then the PMI or Project Management Institute is more common in the U.S. But I also recommend checking out any of your local academic institutions or online courses. There's a ton of resources available if you want to grow your skills here that have really become accessible, available, and quite affordable or even free at some times across the last five or six years. Before I jump in to Ospo Fundamentals, I want to check in with the tech crew in the back. It looks like you were having some issues. Are we good? All good? Great. Thank you. Cheers. So let's talk about the fundamentals of an Ospo if you're a little less familiar. As defined in a definition developed by the Todo Group and Open Source Program Office, Ospo is designed to be the center of competency for organizations, open source operations, and structures. Typical responsibilities will look like defining organizational policy. What can we use? Where can we use it? What are the rules for giving back to open source? Ensuring license compliance. Are we honoring the terms of the software licenses for the software that we're using? It's very simple. Are we making source code available when we need to make source code available? Engaging with the community, showing up for the community either by hosting and sponsoring events like this, by hosting and sponsoring meetups, by otherwise interfacing with the community around projects that we use or we develop for ourselves. And then managing sponsorships, our engagement with foundations, events, projects, people, do we run booths, how do we run them, etc. Typical responsibilities and very in line with the kinds of responsibilities we have in the Ospo at Indeed. We took these responsibilities and we boiled them down to these three initiatives. Enable the effective use of open source, sustain our open source infrastructure, and tell compelling stories about our work. All the work we do in the open source program office at Indeed boils up to these three initiatives that our ongoing multi-year may never be done. This is the categories of work that we do. Enabling the effective use of open source, Indeed has always used it, as have most other companies. We want it to be easier than writing code. Using open source should be easier than writing code. And every piece of open source code that we use is just another piece of software that we can write to help people get jobs. That's our core mission, that's why Indeed exists. For sustaining our open source infrastructure, we rely on it, so we want it to be well maintained. And we support by playing an active role as sustainers, sometimes with code, sometimes with financing and money. And then telling compelling stories about our work, coming out to conferences like this, talking about our successes, our failures, sharing our code where it's useful to other folks. Both for the recognition that we want, but also to help other people along their journey and to get feedback on the work that we're doing. So let's talk about friction points. And maybe a little background on the story here. I started that Indeed in November of 2017, and Talia started in July of 2018. I always get that off by a month. So I was on the job for maybe six months or so before Talia and I had our first chance to meet and engage. So we came in and we had this lovely conversation, our first call, because there was somebody already from the Parable Ground Management Organization working with the team, and she wanted some information about that. Before we jump into there, I was hired and I inherited this lovely team of individuals and I only had one partnering with our open source program office and I thought, no one can show me what the goals are. No one can tell me exactly what they're out to accomplish. I know our open source program office is new, but you should be building towards something, so show me that traceability. Here we go. Talia and Dwayne. Hi, I'm Dwayne. I pay attention to the open source ecosystem. I've learned from open source peers and mentors across the community. I have lots of great ideas. We should absolutely do them all. Every one of them is important. And I'm sure that we need to be going that-ish way. Hi, I'm Talia. I have questions. I would be delighted to answer your questions. So Dwayne, what are the goals you've committed to for the open source program? So Jack and I have had a number of conversations, you know, the executive sponsor who brought me in and we understand the importance of showing up at conferences and being part of the community that way and really an understanding that the open source work that we do it indeed is going to be focused on helping engineers get closer to the projects that they use and sort of growing contributions through there and a couple of sponsorships that we're doing as well. You have an understanding? Yes. So what do you do with this understanding to ensure that the open source program is working on its most important and impactful goals? Well, Jack and I sat down and I conveyed to him the events that I know are important. There's a lot of them out there. There are ones that we can probably miss because they're language specific or maybe domain specific, but ones where there's a lot of people and we should go there. So I know the most important places that we should be going. I've got a really good read on the landscape and the ecosystem and Jack and I talk about this a lot. So you have tea? Yeah. How will the open source program be measured and evaluated through these tea chats that you often have with Jack? This isn't something that Jack and I really have talked about. We know that he's committed and really on board with the idea that this is a term plan. This is not something that's going to bear immediate fruit. We're looking at a 3-5 year long commitment that you can't spin up an open source program office and then expect magic in a year. You've got this open source program office. How does it communicate its value back to the rest of Indeed? Most of this actually Jack and I cover in our one-on-ones. We meet every other-ish week where we talk about how things are going both with the program and with myself. Sometimes not every other week but he's got 17 directs and we download a lot of that information in those conversations. Very casual. So with all of this approach how do you know who your next most important hire should be? I'm really glad you asked that because there are so many people that I think would be great for the program. We really have a need for someone to come in and do some community gardening for us. It's written so that we can collect some measurement on how contributions are flowing from Indeed and out to the outside community. This is a great idea for a research project and someone who would be stellar to execute this research project. Actually what I did is I put together kind of an a la carte menu of who we could hire and gave to Jack so that he understands what I think the opportunities are there. He gave him a list of people. So what about everyone who's not Jack? He came to a screeching halt. This conversation wasn't one conversation. This was over a couple months getting to know each other as I was onboarding to Indeed. The purpose of that was to show you a lot of y'all are open source program office leaders. You have a big commitment out in the community. You're developing something from the ground up or you're evolving it to the next level. You can't do it all. And I was hooked. I thought this is PMO's bread and butter. We have so much we can give to you. We can so much we can add. Really to set you up to go do a lot that play to your strengths. And this began a multi-year journey between Dwayne and I by y'all. I really want to connect you back to the do you have goals? Do you know how you're measuring them? Like we have a single point of failure within our organization that is a vice president that you chat with every couple weeks. What if that person takes a new job? And so those are the things that if you think about pulling that thread through of visibility, consistency, understanding in your company so you can go make greater impact in community, that's where the compelling piece was for me. And I thought, yes, let's go. Dear reader, he did take a new job. So this became very important over time. And I love that line about you being hooked because it really highlights that Tali and I have very different reactions to chaos. I am a self-acknowledged and admitted bouncing ball of chaotic elemental energy. I know that I function best when I'm partnered with a strong process person. And so when I see the kind of chaos and I know some of it is in the room, I'm not looking at all of you directly. I sometimes get hooked on it myself but also sometimes run away and chaos is just like brings you to the table. It's delightful. Let me wade through it deeply and put the pieces in the boat, put the oars on the boat and let's row together. This is, I see chaos as something to be made beautiful. Now in Duane's defense, not that the devil needs an advocate, but a lot of us who have taken roles or grown into roles as leaders of open source program offices have either been hired for those roles or recognized in those roles because we are out here plugged into the space. But I want to call back to a definition or at least a paragraph that was offered by the to-do group guide on establishing an open source program office where they're talking about who you should hire for this role. It says regardless of how your planning starts, it's important to find the right leader to help develop and then run the fledgling program office inside a company. The top candidate will have a detailed understanding about how open source works along with some technical chops from working as a developer, contributor, or a committer on existing open source projects. They should have a broad understanding of your company's business along with the business acumen and management skills to help inform strategy and plan across business units and they need to be sociable so they can convey enthusiasm, knowledge, and information to others and help them understand how the open source initiative is going to transform, change, and improve things for the company. The head of the program office needs to be able to talk with people about the deep technology but they don't have to know the ins and outs of every technology in play just because there are too many to master. So in the kindest way possible what I think we're looking for is this. Hi, I'm the OspoCourt. I have a magical ability to tick all of your boxes. Business goals spring from my horn fully formed. Everyone in the community knows and loves me. All of your stakeholders intuitively understand and love what I do. I also sneeze glitter and stickers. Now as an aside before we jump into the thing you want to say here, that list of the top candidate will, we know from research that when you see a long list of qualifications, people like me will say I meet most of those and I will go ahead and apply. And people from other dynamics, typically women, will not apply if they don't meet all of those qualifications. So that extensive list of qualifications has some bias coded into it. Those eight pieces there if I look at, you know, there are a ton of capable people in this room. I'm an incredibly capable person. There are more capable people outside these walls that will probably be great heads of open source at whatever level your company decides to build, grow, or establish one. And simply by looking at those eight big highlights we pulled out I'd look at that and be like, whoo, am I really ready? Could someone ever be that fully formed and ready? And that's something I think to pay attention to as we look at becoming the OspoCorns we need to be. Apologies to Anna who has always already developed a wonderful mascot through the Ospo space. But anyhow. So looking across these, you know, eight big areas when you go to find a leader like Duane, you're strong in some areas, you're weak in others. That's the affliction of being human and finite. Knowing that we're not infinite, you'll see the ones that we've crossed out here, understanding your company, showing business document, planning across business units, core competencies that at PMO or program management office should be set up to help you. Understanding your company, if they're out having conversations with senior leaders about their priorities, organizing that work, partnering across business units to plan, to understand the trajectory of that work, bring it together at the late risks around it. That really should lend a hand to your open source office. And then that business acumen we have tools, techniques, methodologies, and approaches that can streamline processes that can make your goal setting easier that you can adopt and then integrate from in a way that serves your open source program office and the impact you would have internally at your company but more broadly in the community. So your PMO really can be there to take you and those big ideas from strategy to execution. We are great at navigating cross-company landscapes and unifying plans and driving progress toward those plans. Every day I unsufferably live this craft. It's wonderful and terrible. I'll be freed from it maybe never. I don't know if you would know how to stop even if you quit. So really once we had that screeching halt hook conversation, I figured there were three most important energy opportunities to partner with Duane and indeed Osville from a PMO perspective. The first really is around goals and measurement. You'll dive into some of these more as we get into our examples but we now have a way to clearly articulate our value as an off-vote, progress toward goals and we can do it on a quarterly basis and it's repeatable and now it's built into just the way the team works. The second one, prioritization. Here I am waiting into chaos. We turned that mix and mash up of things. I know what conferences we're supposed to be at. I know kind of what long-term plan we want to do too. Okay, here's some big targeted opportunities to go after earlier. Here's how we want to mature as an open source program office. We can prioritize a quarter of a quarter around what's the most valuable work to do now based on what's going on in the community and the conditions inside our company and we can set that team up to work on things. We are lucky to have a sizable open source program team. Probably unique for a company of our size but that means that people need to know what they're up to and then scale you may have felt this. I know Duane felt this that you can be a single point of failure as the sole head of open source and now we're in a place where I can go look at goals as a team member. I is not a team member of our OSPO. Can go figure out what they're working on chat with anyone on the team about it and understand what that's built is folks know what to look forward to go do next. They also know what they're contributing to indeed the OSPO and then Duane's out there, you know, OSPO Corning finding the next big thing to go after. So let's jump into some examples. We've got four people on the cover that are a little more tangible on ways the PMO helped us get better. I think I said on Twitter my proposed alternate title was how Talia and the PMO helped me suck less at my job and that's a bit of what we'll see over the course of this. So the first one is about the FOSS contributor fund and how we execute it. Very quickly, who's already familiar with the FOSS contributor fund? Okay, less than half of the room. So very briefly, the FOSS contributor fund is indeed a blueprint for how we provide financial support to our open source dependencies. On a regular cadence it was monthly, now it is quarterly. Open source contributors at indeed get a chance to nominate and vote on open source dependencies that we rely on. The dependencies that carry the most votes receive a $10,000 no strings attached, cash injection for their project they can use for anything to pay maintainers, for warning new contributors, security audits and so on. You can talk to me afterwards if you want to know more. We've released all the details about how to run one. There are FOSS funds running in other organizations. It's something that we developed and we've been running now for about four years. Four about four years is where we hit our first friction point. I proposed the FOSS contributor fund early in the budget planning cycle. I found out I had funding for the FOSS contributor fund around the middle of December and the launch date was January 1st. We operate on a calendar year planning cycle, friend. At that point we did. The decision to launch on January 1, all mine, it felt like a non-arbitrary date. There was nothing forcing us to try to pull this together in two weeks actually over the holiday season to do it. But that was the choice that I made at the time and along the way I asked for all kinds of things. We need a blog post to announce it. We're going to need some promotional slides to get up on this network of monitors that we use internally to tell people about it. We should run a civs poll to make sure that we're selecting the most optimum dependency to make sure that the right thing carries the votes. Also we need a form to collect those nominations and we probably actually need four blog posts a month. One to say who won, one to say the vote's coming. One to remind people to do nominations and one to remind them that we exist. That's all the requisitions. Nobody else should have to deal with that. I'll just do them all myself. Somebody has to reach out to the winners and tell them they want and ask them how they want to get paid. We should also explain all the nominees to the people who are voting because some people are going to be very familiar with those dependencies and some people who don't use it to those technologies won't understand why they're important to Indeed. Let's do all of this for January. We didn't get it perfect in that two week window. But this is a big place where you saw all that scatter shop, contact, things we should be doing, processes we got to handle, paying people, requisitions, that. What we boiled it down to, the program manager in place who was actually still with the team several years later now, is you got a lot of communications. We should have a communications plan. Maybe we should make a playbook now that we've done this a couple of times that first two weeks when you roll rough. But we learned some things. Then we got to create a public way to let people know about this, access it, and let's go after a repeatable nomination, selection, and voting process. We've got to offload some stuff. Dwayne or one member of the team cannot be the only person that helps make this process run effectively. We can also automate some pieces. And then let's look at how frequently we are launching the FOSC Contributor Fund and the value it's creating in the community. And we actually learned we should do it a little bit less. It turned out I don't have to do every step of the requisition process myself. There's maybe one or two that I need to do from an authority standpoint. But most of that can be done by other folks on the team. The second example is how we go about setting goals and how we go about handling OKRs. Who is familiar with the OKR framework? About half the room again. Talia, explain OKRs in three seconds. Objectives and key results, common goal setting method across the technology industry. You set an objective, which is a big ambitious thing. And you know you're done with that objective and you can say I've measured it by these couple often metric driven key results or outcome driven key results. That's the framework we use it indeed. Awesome. So what comes next will be very funny to some of you. And the rest of you will eventually understand why everyone is laughing. So as we were putting this deck together, I keep, I have one document that has our OKRs going back four years, five years now from the beginning of the program. So I can look at how we were setting goals from the very beginning. We used this framework starting in Q1 2018. So I went back as we were putting the slide together to see what did they look like in 2018. They were all written by me. There were four objectives to be completed in Q1 as measured by 19 individual key results. And all of this was just run by me and I had been on the job five weeks. And the 19 key results were things like create a three to five year strategy. Write, post, and vet with legal all of our policy documentation. That could take years in itself. I appreciate the audible laughter from the front of the room over here because it really is that funny. And this was actually Talia's reaction when I told her. Yeah, I was like, what are you going to do? Alone? Really? Really tell me about these 19 key results because that's more than one per week of a quarter. Just so we're clear. And then all we have to run reviews in this cycle too. During some of which I was traveling. Precisely. You're definitely going to get all that done. So I have been rightfully accused sometimes of having a radically optimistic about these superhero-like qualities of future DeWayne. And this is just a good example. If we look at Q3 2022 I didn't write most of the OKRs at all. They were largely written by the team. I might have given a language tweak here or there or picked between two. We still have four multi-quarter objectives. It's not something that we're whittling at, but clearly has an end state that will be done. As measured by seven key results, arguably still too many. But we have a team of eight who is executing against those key results. So slightly less than one per person as opposed to slightly more than one per week for one person. And considering that they're now multi-quarter, not one quarter with 19, this is something that you can break down and make achievable by a team over time rather than like, yeah, more than one per week for one person. Okay, fine. And this is a spot to really, like, how did we get to this point, right? Because I mentioned before we had someone from the PMO who was dedicated to the team. And this was clearly a multi-year journey to get us from where I was to where we are now. And a lot of that was having a dedicated person from the PMO embedded in the team. And they did several things for us. One of their roles is to have broader visibility across the goals and key results and initiatives that are in play across the entire organization, both because of their read on the organization but because of their own PMO network. And so not only did our goals get better as this person on the team helped us refine our process for setting them over time and helped us, they also helped us bring them in line with what else was going on in the rest of the organization. And having that person on the team, ultimately ultimately reporting to me has been a huge shift. I don't know if you want to say more there. That's something that, you know, early on in our relationship, this person reported directly to me. You know, organizations change, they shift, they evolve. You won't always have a centralized PMO or a distributed PMO. We were going through an evolution where I was clearly able to understand the value and articulate to that that through our centralized PMO. And as we broke up and became more decentralized as the PMO's organization shift, I clearly understood the need, the impact and the value. And it was very easy for me to make a case of absolutely we need at least one person with our OSPO. Why would we change that when we change an organization structure? The impact is there. And that's a, you know, if you think about objectives and key results, impact is one of the pieces of wording you often hear around that. And that was easy for me to broker in the forms and circles that I had access to that Dwayne wouldn't be in. And so when we ultimately shifted the organization yet again, I said this one goes with our OSPO. We will, as we decompose the organization, Dwayne, this is your program manager, steward their career. Hi, I'm still going to be here. I'm an arm with you. So the third example is how we went about building the organization. Talia mentioned we have sort of a large team for an OSPO our size. I mentioned earlier it was eight people and many times when I speak to other folks who lead open source program office, they say, wow, how did you manage to get eight people in your open source program office at your size? Some folks are lucky to get a couple, right? And we'll talk a little bit more about that. But first let's look at the friction and the evolution, that a la carte menu which is true by the way that I wrote and I put together for Jack. I had some, these are people we really should hire and these are people that you can choose to hire if we want to. That list of names? That list of names, yeah, yeah, yeah. Roles I proposed hiring in 2018, an inner source evangelist, a community gardener, a community organizer, and an open source program operations specialist, like lifted straight from the dock. Now, some of you in the OSPO space might know what some of these mean, who is absolutely certain I know what I mean by community gardener. Richard may, Alyssa, but like because we had conversations about it I think. And so these didn't align to anything that indeed understood. No one knows how to pay them, no one knows how to review them, no one knows how to set expectations for them, no one knows how to hire them, no one knows how to source candidates for them. Because these roles don't exist. Inner source evangelist getting closer now. When I look at roles that I've proposed in a little more recently, technical program manager with inner source expertise. Okay, we can work with that. Software engineer at various levels, product manager, systems administrator. These are well defined roles with rubrics, pay bands, hiring funnels, processes, TA specialists, like a whole language that indeed understands. And that was the role that PMO helped me understand. And that was more of a role that I specifically played with getting to this point. But the thing I want to add is, you know, Ospo's are small, they will be small, especially at large companies. Indeed, just over 13,000 people now. If you think about an Ospo of eight and that proportion into your company, well maybe someone doesn't work in an Ospo forever. Technical program manager, they have opportunities to move around your company. Say their passion changes, their next interest area pops up and it's not with your Ospo. The company knows what to do with that role. They're not getting a shovel out and digging holes for seas and being like, yeah, I did that with a community. People are like, what are you doing? That a company knows what to do with. Software engineer, a company knows what to do with. Systems administrator, very, very relevant. And so that shared understanding within your company and your Ospo that leverage that common language really make it impactful. And then when we go do annual planning, budgeting, headcount requests, that's a simple justification because you've got a lot of that common language. The company's like, oh, yeah, looks normal. Great. Of course you need these roles. I think the other thing I would bolt onto the end of this is that one of the ways we were able to build and grow the organization that we did rolls directly back to that previous slide around how we set goals because as those goals and objectives and key results aligned with what else was going on in the rest of the business, it became easier to explain to people how this particular person, not role, how this particular role was going to roll up and support objectives that were beyond the open source team. And notice how it shifted from Dwayne's list of favorite friends to roles and skill based to deliver the goals. And there are probably some favorite friends that are still going to make it in that door because they are the right skill set, they are the right thing. But then the company doesn't look at it as like, Dwayne, why'd you just hire Jack? There was a thing that would happen occasionally where I would come to Talia and say, I need to hire this person to do this thing and I need your help to sell this internally and she would say, I'm not and you don't. And we would have to have the blunt and hard conversation about the many ways in which I was wrong and usually I was wrong, not always usually. The no wasn't a hard no, it was go back and tell me the why and what they're going to be doing and the value that they give and show me where they map to your goals or you have a new goal you need to tackle. And I'm like, homework is time, no until your homework is done. So the last one we'll talk about is how we handle prioritization and if we look back again to this 2018 OKRs with four objectives and 19 key results, that is still funny every time I look at it. When I first came in to indeed, there was someone at a PMO role that was flown out and to spend a couple days with me in San Francisco and they said OK, sit down and spread it out, what do you want to do? And so I got the post-its and the white board and I put it all up there and all of it was important and we had to do all of it. This is the distilled version. And Beth was wonderful, she looked at it like the whole time, OK, and at the end of it she just said, so that's a lot and just let it hang there. And that was the beginning of me coming to a more well-rounded understanding of what it means to really prioritize and in particular prioritize in the context of what else is going on elsewhere in the organization. Now Jacob Green from Moss Labs and deeply involved in the Ospo plus plus network has gifted us all this concept, this phrase that the open source program office is the API from organization to organization. And so what that means is if I'm dealing with some kind of open source issue and I need to talk to somebody over in Google, what I'm likely to do is reach to my friends in the open source program office and they are going to facilitate and enable that connection. And so I think it's a very valuable metaphor and I'd like to extend it here because if your Ospo is the API that enables effective collaboration, effective external collaboration, then your PMO is the API that enables effective internal collaboration. If you're leading an Ospo or working in an Ospo you cannot hope to have a total view on your own of everything that is going on in your organization above a certain size. That's what the PMO does. We are a wide network that reaches very deeply and widely across an organization and we can bring and share that perspective. And we are that phone of friends internally. So this isn't without risk, right? Your PMOs that you interface with or connect with or have access to are not all created equal. Yours may not look at all like today's example. If you have an awesome PMO that looks like a lot of what we've shared, go engage with them. Make that first connection with the API. Share those keys and secrets. Get in there and build that relationship because they can bring you a lot of value and really bring order to that chaos because that's one of our biggest strengths is waiting into the pool of chaos and saying look, there's some really cool tools in here and we're going to shape it for you and with you. But if you have a PMO that doesn't work like this, you're not stuck. And my guidance would be to go seek out the same characteristics but in different roles. You may have business operations. You may have strategy in operations. You may have a strategy office. You may have a business management office. You might have a random director of communications that's excellent at all this. We'll seek out these people with these characteristics and relationships and connect with that. There might be a senior manager of marketing that has a PMO background and they can go really, really start you up. So that's the thing that I would say is just because your PMO doesn't look like the massive questioning that you experienced today with Dwayne and I, you can still do this. It's not impossible. Anyone, I guess the thing I would say and the thought that I want to leave you with, anyone who's worked with me or around me for any length of time that's heard me talk about PMOs may have heard me say in the past that the PMO's job is to take weird things with weird edges and sand them down until they all look the same. And OSPOs are a little weird. Open source is a little weird, especially compared to other business programs. I still believe this and I'll still say it in front of Talia. Generally, like program offices exist to bring order to the chaos and sand the edges off of things that look weird, but I think there may be another perspective here that we can offer, which is that a PMO can instead help you fill in the gaps around those weird edges and put a polish on the work that you're doing and taking that weird thing and help the business understand that it is valuable like a pearl. And with that last metaphor, we have a couple of time for question. Thank you all for coming. Thank you. We have a couple of time for question. I see a question over there. I'll repeat the question and then I'll give you a first shot. The question is, I have the sense that we had an advantage because Talia was in the PMO with some authority and interested in what we were doing and wanting to help us solve it. What do you do if you don't have a Talia in your own PMO? So that's only partially true. I inherited a situation where there was a senior manager that preceded me that had just been kind of staffing people out and I walked into the situation. Before I met Dwayne I knew nothing about open source except for the bottom stack of our company. I was like, great, we got people dealing with that. And then the other person that Dwayne mentioned that had been like, you have got a lot and distilled you down to 19. Engaging with your PMO on a consult is always possible. They may not be able to embed deeply, but go after that consult. Hey, look at my world with me. Can I get a couple of hours of your time? That's usually a service when you're fully centralized as a PMO that folks are willing to offer. So if you package it right or make your ask sizable enough, you can usually find that door that opens just a little bit and wedge yourself in. Also, if you don't get what you need out of the first person, try someone new. You've had four or five folks rotate through now, right? Three, I think. Okay, four or five folks. The thing that I would say is that your PMO doesn't feel anyway. People within your PMO do. And so to bolt on to what Talia says, if you aren't getting a good response from the first person, keep trying around. And in particular, pay attention for people who are at inflection points or transition points in their career, who are looking to make a case for promotion. They have a little more intrinsic motivation to show that they're having an impact somewhere and might be a little more willing to dive into the problem. I've been told to stop. It was a big red sign that said stop. We will continue to take questions, just not with microphones in our hands. Thank you so much for coming to the talk. We're blessed and grateful. Thank you. An extra applause for Talia. This was her first conference talk ever. Thank you all.