In the InnerSource Commons, we talk about the concept of open in the lessons we’ve learned in open source, and how we might reuse what we know or have learned in an enterprise environment. Let me step through a few of those from a manager’s perspective. I’ll talk about how they’ve benefited me as a director, and my product managers - that’s what we call product owners at PayPal.
First of that is open code. What do I mean by open code? Basically, the fact that the 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 articles 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 reduce 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 their backlog that’ve 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.
Some of the benefits is that it helps you and your teams get credit for the work that’s done. You can also cross-team coordinate more effectively when you know what the other teams are working on and what they’re prioritizing currently. Open planning allows for more effective negotiations between teams.
One of the things we work a lot on in InnerSource is open documentation. This includes the planning process, the standards, things of that nature. A key element of this is the findability and the fact that there’s a certain amount of centralization, so that everybody knows where to go to find the documentation to figure out how to collaborate with you better.
It has a lot of benefits in regards to your success. Some of that is the open planning and the open standards, so that you can collaborate better. But there’s also the credit aspect where upper management can see the different paths you’re going through, and what you are doing in regards to these projects moving forward and the previous history.
While at first it may seem a bit time intensive, collaborating becomes way more effective when you have open processes, open standards, and open documents. These documents need to be openly published in a standardized place. This enables them to be discoverable. They can be enforced via a standard or a good search engine as well.
The benefits are - you and your team get more credit about the work being done. You also have an obvious history. The reason priorities are changed are obvious. This helps a lot with the credit issue that we talked about earlier in regards to the stressors for middle management.
It also increases the velocity on your collaborations. You can easily research teams you’re interested in collaborating with, and you can kind of see how they do things. The biggest bear of them all - it reduces tribal knowledge and helps to break down the silos. If a team is difficult to collaborate with, it will become quickly obvious, both in the fact that the velocity will be much slower, and sometimes the documentation is either overly complex, restrictive, or negative. Sometimes they have good reasons, like a fragile legacy code base, but now upper management can more clearly see why refactorization might need to be prioritized in regards to the resources.
Collaborating and negotiating: middle managers don’t typically feel empowered to use their leadership skills. This was mentioned in the top five complaints that middle management had previously.
During the InnerSource process, these skills, like collaboration and negotiation, become crucial. When you have these clearly stated, setting expectations across the teams becomes much easier. You can even help other teams help you create your documents and standards. I found, most of the time, people want to give input, especially in regards to the standards making process. It’s also a good and sometimes safe way to get those teams started when they’re first working together.
I have three great examples of how InnerSource processes greatly changed the path for some large projects I worked on.
The first one is payments. Payments needed refactorization and modularization. I worked with the payments team and five other teams to design their new InnerSource processes for eight months.
We were able to take a team that was 80% interrupt driven to being able to finally refactor. The other teams were able to get rid of years of backlogged features. At the end, the director told me we couldn’t have understood properly what the refactorization and modularization would look like for the new payments modules without the input from those five teams during the InnerSource processes and facilitation.
The second one is the ALM, or Application Lifecycle Management process. This team is responsible for orchestrating all of our tools from code creation to production. Not only were we able to implement 15 major features in less than a year, including containerization and database as a service, but we were also able to start refactoring the ALM to transition to platform as a service. This team created some amazing open standard documents after working with various teams and seeing how much velocity it generated.
The third example is FDI, which stands for Failed Developer Interactions. We created a Developer Standards Committee to help develop an open standard. After all, who’s better able to determine what a FDI, or Failed Developer Interaction, is, than the developers being directly impacted on an hourly basis?
This helped resolve some political issues, as well, as every team, previously, had different ways of how they measured failures. Needless to say, in a couple of instances, developers didn’t agree. But by having the discussions public, I like to believe we were able to create standards that are more accurate than the previous ones.
These examples show that if open processes are done well, it changes the face of the middle management. The middle management role changes. Product owners have to negotiate more between teams. Product owners have to focus a little bit more on collaboration. But if done well, all teams get to participate more in the corporate vision.
It’s best if this open planning goes all the way to the top. Often, this means that the product owners may need additional training and mentorship in negotiations. But it does address the major complaint middle managers have about not feeling empowered.