Apply suggestions from code review

lenucksi · rrrutledge · web-flow · commit 9acabf4da874 · 2019-08-07T13:35:27.000+02:00
Co-Authored-By: rrrutledge &lt;rrrutledge@users.noreply.github.com&gt;
diff --git a/product-owner/01-opening-article.md b/product-owner/01-opening-article.md
@@ -2,6 +2,6 @@ Hey, middle managers, product owners, and program managers. Do you want to lead
 
 Through the InnerSource process, we also reduced decades of cumulative internal backlog features in less than a year. The key element of InnerSource is being open. This breaks down the silos that most corporate teams are trapped in. We will talk about the basic InnerSource techniques that enable this to happen, saving us countless management and developer hours. 
 
-Hi. My name is [? Selena ?] [INAUDIBLE], and I'm a director at PayPal. I have successfully trained over 40 teams and 1,500 people in the InnerSource process I also participate and speak regularly at the Inner Source commons. Please come join us. Check out innersourcecommons.org. You can also get a copy of the booklet I wrote with O'Reilly there at innersourcecommons.org/checklist. It has even more details in this video. 
+Hi. My name is Silona Bonewald, and I'm a director at PayPal. I have successfully trained over 40 teams and 1,500 people in the InnerSource process.  I also participate and speak regularly at the Inner Source commons. Please come join us. Check out innersourcecommons.org. You can also get a copy of the booklet I wrote with O'Reilly there at innersourcecommons.org/checklist. It has even more details in this video. 
 
 Please watch the other videos first. See the links below. It helps to be familiar with the Agile or Lean processes, and it's really important that you understand the roles of the trusted committer and the contributors before watching this video. Thank you. 
diff --git a/product-owner/02-how-difficult-it-is-to-be-a-middle-manager-article.md b/product-owner/02-how-difficult-it-is-to-be-a-middle-manager-article.md
@@ -4,10 +4,10 @@ Here are the stats. Middle managers have higher rates of depression and anxiety
 
 To paraphrase a common complaint I found, middle management is often responsible for upper management's vision without getting to participate in its creation. I can't really think of anything less motivating for someone that needs to have leadership abilities. 
 
-The top five complaints that I found after reading several studies are number one, inheriting product chaos and dysfunctional teams, number two, no flexibility and little room for creativity-- often, this includes no clear path forward-- number three and the one that I personally have to work on the most, stress of dealing with politics and infighting. 
+The top five complaints that I found after reading several studies are: Number one, inheriting product chaos and dysfunctional teams.  Number two, no flexibility and little room for creativity.  Often, this includes no clear path forward.  Number three, and the one that I personally have to work on the most, stress of dealing with politics and infighting. 
 
 Number four, middle managers rarely get credit for the work. This isn't just about achievements. Upper management is only focused on what is next and often ignores the facts that they changed objectives or chose impossible deadlines. So it seems to be more of a complete credit issue. 
 
 And number five, lastly, most feel like bookkeepers or enforcers, instead of having the freedom to be a true leader. Did I get this right? Do you agree with me? Let me know in the comments below what I forgot. 
 
-These complaints are the reasons I decided to work on InnerSource, because as a middle manager, I've walked more than a few miles in your shoes. So let's talk a bit more about how InnerSource can help you with some of these issues. 
+These complaints are the reasons I decided to work on InnerSource, because as a middle manager, I've walked more than a few miles in your shoes. So let's talk a bit more about how InnerSource can help you with some of these issues. 
diff --git a/product-owner/03-major-benefits-are-built-into-the-innersource-process-article.md b/product-owner/03-major-benefits-are-built-into-the-innersource-process-article.md
@@ -2,7 +2,7 @@ In the InnerSource Commons, we talk about the concept of open in the lessons we'
 
 First of that is open code. What do I mean by open code? Basically the fact that code is visible by all of the company, and there's a process for other developers to be able to submit pull requests on other code bases and get them accepted. To understand this more, please see the videos about trusted committers and contributing agreements for more details. 
 
-Open code for a manager also means no more waiting or escalating to get bugs fixed or features implemented on other teams' code bases. You can start to implement and plan more effectively. Often, your team's problem, or feature, may not be the highest priority for that other team. You no longer have to lean on escalations to upper management and politics to get access to that team. Instead, you have more power to determine priorities with your team and have your dependencies on others. Sometimes it may take longer because of the learning curves. But if it is a team that is a constant bottleneck, you can get those stories out of a backlog that's been sitting there for years. 
+Open code for a manager also means no more waiting or escalating to get bugs fixed or features implemented on other teams' code bases. You can start to implement and plan more effectively. Often, your team's problem (or feature) may not be the highest priority for that other team. You no longer have to lean on escalations to upper management and politics to get access to that team. Instead, you have more power to determine priorities with your team and have your dependencies on others. Sometimes it may take longer because of the learning curves. But if it is a team that is a constant bottleneck, you can get those stories out of a backlog that's been sitting there for years. 
 
 Open planning-- this is where everyone publishes their planning process in an open and standardized fashion. At PayPal, we have the UPE standard. It stands for Unified Product Experience. It includes a tech hub where all the teams publish their roadmaps and spreadsheets for sprint planning. Everyone knows where those documents are by individual product. 
 
diff --git a/product-owner/04-new-roles-and-responsibilities-article.md b/product-owner/04-new-roles-and-responsibilities-article.md
@@ -1,17 +1,17 @@
 Being an InnerSource leader comes with new roles and responsibilities. One of the first one of those is supporting your TCs. TCs are the trusted committers. One of the first things that you're going to be doing is probably helping to choose who those new TCs are going to be and supporting them in their job. If you want to know more about what the TC role looks like, please watch the video. 
 
-They are the gatekeepers to your code database. Typically, they are lead developers who are good at code reviews and have a deep understanding of the code base's architecture. They will need your support. They will also be key for you in regards to collaborating with other teams. They'll be your right-hand person in regards to estimations and integrations. Remember to support them. They have some crazy new responsibilities and may need mentoring to help with those contributing teams. Developers are not often taught how to negotiate. I recommend the book Getting to Yes, and for you to use that with them. 
+They are the gatekeepers to your code base. Typically, they are lead developers who are good at code reviews and have a deep understanding of the code base's architecture. They will need your support. They will also be key for you in regards to collaborating with other teams. They'll be your right-hand person in regards to estimations and integrations. Remember to support them. They have some crazy new responsibilities and may need mentoring to help with those contributing teams. Developers are not often taught how to negotiate. I recommend the book Getting to Yes, and for you to use that with them. 
 
 Secondly, other product owners. Now, you're going to be dealing with the other product owners, especially to meet new time commitments in regards to negotiation and collaboration. It takes time. You're going to need to mentor. You may need to mentor other product owners, especially that are new to the process. Your processes might be different from theirs as well. That's OK. 
 
 I like to think of project code bases as being like houses. Some older houses need more rules and directions than others because they're quirky. For example, hot and cold wasn't a standard in houses a long time ago. So nowadays, you document it so that the guests know that hey, in the shower, the cold is actually the left hand instead of the right hand. 
 
-Thirdly, documentation time. At the beginning, you may have to sink a fair amount of your time in regards to the open documentation, and going beyond just your open roadmaps and other open processes. I'm also talking about things like UX and UI standards, API standards, or even testing requirements. With that, of course, you're going to want to [? sync up ?] with your trusted committers as to what they need to feel safe in regards to some of their coding requirements. It'll be worth it, promise. 
+Thirdly, documentation time. At the beginning, you may have to sink a fair amount of your time in regards to the open documentation, and going beyond just your open roadmaps and other open processes. I'm also talking about things like UX and UI standards, API standards, or even testing requirements. With that, of course, you're going to want to sync up with your trusted committers as to what they need to feel safe in regards to some of their coding requirements. It'll be worth it, promise. 
 
 Once you start working with those other teams, and when you onboard new developers and get so much more done than you'd gotten previously, remember those new developers-- you can also get them to help you write some of this brand-new documentation. If your tool is one of those bottlenecks and is really important to them, they may even offer to help you do a lot of the heavy lifting in regards to the standards, because they want to integrate in with your product. 
 
 Lastly, internal marketing. There's some projects that everyone wants to contribute code to. Oftentimes, these projects are the bottlenecks. I find that people start working on InnerSource projects at first because they must get something into one of those bottleneck projects. So they can progress their own projects forward. But what if you aren't one of those projects? If that's true, and you really want to get free help from others in the company, then you're going to need to market your code base to them. 
 
 Sometimes you can market it as a new skill to learn-- say, for example, the Android team got a lot of contributors because a lot of people wanted to put mobile on their resume. Also, good Getting Started documents will help other teams be ready to contribute and work with you on it. Another thing that you can do is go look for other teams where you may be doing things that are redundant. So if you find that there's a bunch of different tools that are doing a similar functionality, you can all work together and divide out those features so that you can collaborate, use less time and resources. Be sure to reflect that up, so that way they understand how much money you've saved them by doing InnerSource. 
 
-We also have several other patterns at the InnerSource commons. So please go and check out innersourcecommons.org to learn more. Two really good examples that I can think of off the top of my head are the Code-a-Thon and doing different types of announcements saying that your code base is ready and open for business. Thank you. 
+We also have several other patterns at the InnerSource commons. So please go and check out innersourcecommons.org to learn more. Two really good examples that I can think of off the top of my head are the Code-a-Thon and doing different types of announcements saying that your code base is ready and open for business. Thank you. 
diff --git a/product-owner/05-recap-takeaways-article.md b/product-owner/05-recap-takeaways-article.md
@@ -2,6 +2,6 @@ Just to wrap up what we talked about in this video, I'd like to do a quick revie
 
 Also, you get to collaborate more with your peers to accomplish more with less, so that you can actually deal with those redundancies. The open processes also means that you get more credit for your work than you were probably getting previously. By going through and publishing those planning processes, it also means that you can deal with less politics, because everything becomes so much more clear. 
 
-And lastly, you've got those new roles and responsibilities, such as supporting your new trusted committees. They're really going to need your help. Also, working with those other product owners so that you can both get more of your work done in a faster time frame. Going to have to [? spend ?] a lot of time in regards to the new documentation, but that's OK, because you're going to get more credit for it. 
+And lastly, you've got those new roles and responsibilities, such as supporting your new trusted committers. They're really going to need your help. Also, working with those other product owners so that you can both get more of your work done in a faster time frame. Going to have to sink a lot of time in regards to the new documentation, but that's OK, because you're going to get more credit for it. 
 
-Also, with internal marketing, you've got a new skill that you've got to learn there. But once you master it, you'll have a lot more resources in which to get your work done. 
+Also, with internal marketing, you've got a new skill that you've got to learn there. But once you master it, you'll have a lot more resources in which to get your work done. 
diff --git a/product-owner/06-closing-and-contact-article.md b/product-owner/06-closing-and-contact-article.md
@@ -1,5 +1,5 @@
 Please contact us at innersourcecommon.org, and join us online. We have a very active community of over 80 companies. Many of those are Fortune 500 companies. 
 
-You should also watch the other videos if you haven't yet. They contain some of the first steps that you'll need to implementing and inner-source process at your company. They also go over some of the roles like the trusted committee and also, some of the documentation, such as creating your first contributing agreement. 
+You should also watch the other videos if you haven't yet. They contain some of the first steps that you'll need to implement an InnerSource process at your company. They also go over some of the roles like the trusted committee and also, some of the documentation, such as creating your first contributing agreement. 
 
-If you'd like to read my book, please check out innersourcecommons.org/checklist. And for all of you product owners, there will be many, many things to go in and do and implement in regards to the back part of that book. Please find us at innersourcecommons.org, or you can also find us on Twitter, Facebook, and LinkedIn. Also, if you'd like to contact me to talk further, please find me at silona.com S-I-L-O-N-A. I'm also on Twitter a lot. 
+If you'd like to read my book, please check out innersourcecommons.org/checklist. And for all of you product owners, there will be many, many things to go in and do and implement in regards to the back part of that book. Please find us at innersourcecommons.org, or you can also find us on Twitter, Facebook, and LinkedIn. Also, if you'd like to contact me to talk further, please find me at silona.com S-I-L-O-N-A. I'm also on Twitter a lot. 
