Pattern 1: Developer level
Acquisition(s) resulting in multiple cultural perspectives. Developer is aware and InnerSource program environment is available to them. Post-acquisition, so this won't account for code decisions that were made around acquisition.
Inefficient/Duplicative development across teams because they are siloed
- Different processes in place
- Used to different tools and reluctant to change.
- Competing middle managers
- Rigid timelines
- Politics and egos
- Bi-directional fear/Lack of trust
- Fear of losing one's job
- Fear of loss of control of domain or code
- Fear of loss of identity
- Pandora's box/unknowns tied to opening up code
For net-new acquisition
Make the acquired teams feel secure in the new environment by
-
Establish a neutral (well-respected) governance committee across both companies that selects from the different options across these silos to converge and integrate. (validated).
-
Come up with rational rules for managing code redundancy as a result of acquisition (validated)
- Joint effort between two teams to bring new software into existing platforms. (validated)
- If allowable/controllable, initial software selection not tied to job security. (not validated)
- Same ground rules as above for determining tooling platforms. (validated)
- Giving developers and middle management good on-boarding training and mentoring with InnerSourcing as part of it. (not validated)
- Clear guidance on how to bring their software onto existing platform. (not validated)
- Definition of roles including Contributor and Trusted Committer. (not validated)
-
Make it clear that there are career advancement opportunities that come along with actively participating as well as with being a Trusted Committer. (validated)
-
Give them time to get comfortable with the new environment - a generous, realistic grace period for ramping on new company procedures/processes. Not uncommon for this period to be up to a year but there must be a mutually agreed-to deadline. Being "fully integrated" requires a certain level of representation among Trusted Committers from both companies. (validated)
-
Minimum commitment for face to face engagement between the two teams.
- can be representative team from acquiring company meet with team.
- potential Trusted committers from acquired company can meet with parent company.
- Silos are broken and teams working together
- This pattern does not address potential cultural issues due to the acquisition.
Partially validated. Validated means this has been seen to work in similar scenarios but not in the exact context of this pattern.
Pattern Idea - Draft In Progress
Pattern 2: Management level
Acquisition(s) resulting in multiple cultural perspectives. Acquired company's Middle Management is supportive of the InnerSource program. Post-acquisition, so this won't account for code decisions that were made around acquisition.
Inefficient/Duplicative development across teams because they are siloed
- Different processes in place
- Fear of losing control
- Have to deal with developer fears
- Fear of losing developer resources (who work on other projects)
- Rigid timelines
- Politics and egos
- Bi-directional fear/Lack of trust
- Fear of losing one's job
- Fear of loss of identity
- Fear of being judged
- Pandora's box/unknowns tied to opening up code submissions
(PICK UP HERE NEXT TIME)---------------10/25/16
For net-new acquisition
Make the acquired teams feel secure in the new environment by
-
Establish a neutral (well-respected) governance committee across both companies that selects from the different options across these silos to converge and integrate. (validated).
-
Come up with rational rules for managing code redundancy as a result of acquisition (validated)
- Joint effort between two teams to bring new software into existing platforms. (validated)
- If allowable/controllable, initial software selection not tied to job security. (not validated)
- Same ground rules as above for determining tooling platforms. (validated)
- Giving developers and middle management good on-boarding training and mentoring with InnerSourcing as part of it. (not validated)
- Clear guidance on how to bring their software onto existing platform. (not validated)
- Definition of roles including Contributor and Trusted Committer. (not validated)
-
Make it clear that there are career advancement opportunities that come along with actively participating as well as with being a Trusted Committer. (validated)
-
Give them time to get comfortable with the new environment - a generous, realistic grace period for ramping on new company procedures/processes. Not uncommon for this period to be up to a year but there must be a mutually agreed-to deadline. Being "fully integrated" requires a certain level of representation among Trusted Committers from both companies. (validated)
-
Minimum commitment for face to face engagement between the two teams.
- can be representative team from acquiring company meet with team.
- potential Trusted committers from acquired company can meet with parent company.
- Silos are broken and teams working together
- This pattern does not address potential cultural issues due to the acquisition.
Partially validated. Validated means this has been seen to work in similar scenarios but not in the exact context of this pattern.
Pattern Idea - Draft In Progress
David Marcucci, Nicholas Stahl, Padma Sudarsan, Ryan Bellmore, Erin Bank
Pattern 3 For post-acquisition legacy silo
Make the acquired teams feel secure in the new environment by
- Giving them a good on-broading training with inner sourcing as part of it. To bring their software onto existing platform
- Make a few of them Trusted committer so they feel included.
- Give them time to get comfortable with the new environment.
A neutral (well respected) governance committee that selects from the different options across these siloes to converge and integrate.
Discoverability and visibility across the different organization.
Siloes are broken and teams working together
Draft
David Marcucci, Nicholas Stahl, Padma Sudarsan, Ryan Bellmore, Erin Bank
Pattern 2: Management level
Acquisition(s) resulting in multiple cultural perspectives and different processes.
Inefficient/Duplicative development across teams because they are siloed
- Used to different tools and reluctant to change.
- Competing middle managers
- Politics and egos
- Lack of awareness
- Lack of flexibility
- Bi-directional fear/Lack of trust
- Fear of losing one's job
- Fear of loss of control
- Fear of loss of identity
- Rigid timelines
- Resource constraints to provide for overhead
Make the acquired teams feel secure in the new environment by
- Giving them a good on-broading training with inner sourcing as part of it. To bring their software onto existing platform
- Make a few of them Trusted committer so they feel included.
- Give them time to get comfortable with the new environment.
A neutral (well respected) governance committee that selects from the different options across these siloes to converge and integrate.
Discoverability and visibility across the different organization.
Siloes are broken and teams working together
Draft
David Marcucci, Nicholas Stahl, Padma Sudarsan, Ryan Bellmore, Erin Bank