Add patterns: Sponsor-Amplified Evangelism and Discovering Cross-Team Success Stories - #933
Conversation
|
The failing Link Checker check appears unrelated to this PR, it's flagging a 403 from oreilly.com elsewhere in the repo, not from my new file. |
spier
added
the
📖 Type - Content Work
There was a problem hiding this comment.
Thanks for contributing this, @shrutibist! 👏
These 2 patterns are clearly designed to work together — Cross-Team Success Stories feeds Sponsor-Amplified Evangelism with concrete material, and this pattern amplifies it. That pipeline is the real idea. Right now the connection is only in the Related Patterns sections of each. It would be worth adding a sentence in each pattern's Context or Resulting Context that makes the sequencing explicit: you use the first to find stories, and the second to distribute them.
Both patterns are well-written and address a real gap. 👍
|
|
||
| **1. Establish a contributor-to-team mapping.** Use whatever directory the organization already maintains (an org chart, HR system, or internal people directory) to determine which team or business unit each individual contributor belongs to. This mapping is the foundation the rest of the detection depends on, and it needs to be kept reasonably current as teams reorganize. | ||
|
|
||
| **2. Script the comparison against each InnerSource repository's contributors.** Pull the list of contributors (via commit history, pull request authorship, or equivalent) for each InnerSource repository, and compare each contributor's mapped team against the repository's own owning team. Flag any contributor whose team does not match the repository's owning team. |
There was a problem hiding this comment.
How do you define the "owning team"? An InnerSource repo can intentionally be owned across multiple teams. I assume you mean the "owning team" as code owners as mentioned in the CODEOWNERS file.
There was a problem hiding this comment.
Yes, "owning team" in this pattern refers to the teams/individuals listed in the repository's CODEOWNERS file. I will update the pattern to state is more explicitly. Thanks.
| ## Context | ||
|
|
||
| * The InnerSource program has scaled to a large number of repositories and participating teams, large enough that informally tracking collaboration by word of mouth is no longer feasible. | ||
| * Contribution activity (commits, pull requests, or equivalent) on InnerSource repositories is available in a form that can be queried or extracted programmatically. |
There was a problem hiding this comment.
(commits, pull requests, or equivalent) — which one? A merged pull req and an opened-but-rejected pull req are very different signals. Worth picking one and explaining why.
There was a problem hiding this comment.
I meant a merged pull req. I will update the pattern to reflect that.
|
|
||
| **2. Script the comparison against each InnerSource repository's contributors.** Pull the list of contributors (via commit history, pull request authorship, or equivalent) for each InnerSource repository, and compare each contributor's mapped team against the repository's own owning team. Flag any contributor whose team does not match the repository's owning team. | ||
|
|
||
| **3. Treat the flagged list as a lead list, not a finished result.** The output of the script is a manageable set of specific, concrete candidates for further investigation, not a final answer about collaboration quality. Some flagged cases will be trivial (an incidental one-line fix); others will be substantial, ongoing collaboration. |
There was a problem hiding this comment.
Good framing. What does the triage actually look like though — what questions do you ask to decide if a flagged case is worth following up on?
There was a problem hiding this comment.
What's the triage bar? At scale, even a filtered list can be 50+ flagged cases a quarter. Would you please share any example of what a "story worth telling" actually looks like?
There was a problem hiding this comment.
We used a template to reach out to contributors flagged by the script. For triage, we prioritized based on the number of sustained contributions from a single contributor, looking for people who had made multiple contributions over time suggested real, ongoing collaboration worth investigating.
However, we didn't ignore cases with fewer contributions. The high-priority approach just meant we had schedule outreach to those contributors first. The lower priority cases were still investigated, but on a staggered timeline. This mix actually uncovered interesting stories across both groups. Some of the most compelling collaboration came from unexpected corners where contributors had made just a few key contributions, not necessarily the highest volume.
There was a problem hiding this comment.
I will give a vague example- Team A needed to solve a technical infrastructure problem but lacked the expertise or bandwidth to implement it themselves. Team B, who had already solved the same problem and published their solution through InnerSource, had a developer contribute directly to Team A's repository to help them implement it. Our script flagged this cross-team contribution, and when we reached out to understand it, the contributor explained their team saw an urgent need and could help faster by contributing directly rather than having Team A figure it out alone.
| * **Manual awareness vs. programmatic detection:** asking teams directly is more contextual and often surfaces detail a script cannot, but it does not scale once the number of repositories and teams grows large; a script scales but only produces a signal, not the full story. | ||
| * **Signal vs. noise:** flagging any contribution from outside the owning team is simple to implement, but not every flagged case represents meaningful collaboration; some manual triage is needed to separate incidental contributions from genuine cross-team work. | ||
| * **Automation effort vs. ongoing value:** building and maintaining the script and the contributor-to-team mapping takes upfront and ongoing engineering effort, but pays off repeatedly as the program continues to scale, unlike a one-time manual survey that goes stale immediately. | ||
| * **Privacy and framing vs. usefulness:** using contributor identity data to flag individuals' activity is useful for the program, but should be framed and used carefully, as a way to find and celebrate collaboration, not as a surveillance or performance-monitoring mechanism. |
There was a problem hiding this comment.
Appreciate that surveillance is called out as a real tension. Frame it as celebration is a good instinct, but what stops the same script being repurposed for performance monitoring down the line?
There was a problem hiding this comment.
That's a critical point, and you are right to flag it. In our implementation, we had a few safeguards, the script and its outputs were owned and controlled by the InnerSource program team (not shared with their Managers or HR for performance management), the data was explicitly framed as 'collaboration discovery for storytelling', and we had transparency about how it was being used. However, you are right that organizational intent can shift over time, and this pattern doesn't prevent misuse by design.
|
|
||
| **4. Follow up directly with the people involved.** Reach out to the flagged contributor and the repository's owning team to understand the nature of the activity: whether it was organic and unplanned, or a deliberate collaboration arising from two teams' overlapping needs. This conversation is what turns a data point into a story with enough specific detail (who, why, what problem, what outcome) to actually be useful. | ||
|
|
||
| **5. Feed confirmed stories into existing sponsor and evangelism channels.** Route the resulting case studies into the program's sponsor readouts and broader evangelism efforts (see the companion patterns on sponsor communication and sponsor-amplified evangelism) as concrete, specific evidence of the program's impact, rather than only aggregate metrics. |
There was a problem hiding this comment.
Great that the loop closes back to sponsors. What does a "confirmed story" actually look like at this point — is there a template or a minimum bar for what makes it usable in a readout?
There was a problem hiding this comment.
Good question. We used a structured template for case studies that ensured consistency and usability in sponsor readouts.
Challenge - the business problem both teams faced
Solution - how InnerSource enabled them to solve it together
Impact - concrete outcomes, such as, time saved, cost avoided, capability gained), and
Testimonials - direct quotes from contributors explaining their experience and motivation
Importantly, we deliberately presented both major and minor contributions in these readouts. There is sometimes a misconception that InnerSource contributions only matter at massive scale, but we found value in showcasing how contributors at all levels, whether they made a single critical fix or ongoing contributions, strengthened the program. This approach encouraged broader participation and showed that meaningful collaboration doesn't require solving the organization's biggest problems.
|
|
||
| ## Known Instances | ||
|
|
||
| A large enterprise technology company used this practice once its InnerSource program had scaled to several hundred repositories across many participating teams. The program team wrote a script that pulled contributor data from InnerSource repositories and mapped each contributor to their business unit using the organization's existing directory, flagging any contribution from someone outside the repository's owning business unit. The team followed up directly on flagged cases to confirm and understand the nature of the collaboration, distinguishing organic contributions from deliberate collaboration driven by two business units' overlapping needs. Confirmed cases became case studies used in sponsor readouts and in the program's broader efforts to promote InnerSource across the company. |
There was a problem hiding this comment.
The Known Instances section reads almost identically to the Story section. These should be distinct — Story illustrates the pattern, Known Instances evidences it. Can you differentiate them?
There was a problem hiding this comment.
Ack . I will fix the Known Instance.
|
|
||
| ## Patlet | ||
|
|
||
| An InnerSource program cannot reach broad, organization-wide awareness through its own team's channels alone. Direct outreach (roadshows, tech talks, a portal) only reaches the people already paying attention. Equip the program's sponsors with a simple, ready-to-share link and a natural cue for when to mention it, and align the program's message to organizational goals already on their agenda, so sponsors amplify the program into meetings and audiences the program team could never reach directly, turning each sponsor into a distribution channel rather than only a funding source. |
There was a problem hiding this comment.
Same issue as the other pattern — the patlet is doing too much. It's 4 sentences. Can you please distill this to 1-2?
There was a problem hiding this comment.
Often we try to structure it like:
1st sentence - the problem
2nd sentence - the solution
Of course a sentence gives you little space. So it is always about summarizing the essence of it.
There was a problem hiding this comment.
Updated - "An InnerSource program cannot reach broad organizational awareness through its own channels alone. Turn your program's sponsors into distribution channels by giving them a simple link and a clear cue to mention InnerSource in their existing meetings, tied to organizational goals they're already discussing."
|
|
||
| **1. Use the sponsor readout as the planning venue.** During the program's recurring sponsor readouts, explicitly ask each sponsor what meetings they have coming up (their own staff meeting, a BU all-hands, an executive readout) where InnerSource could naturally fit. This turns a general ask for "evangelism" into a specific, scheduled opportunity rather than an open-ended favor. | ||
|
|
||
| **2. Tie the message to an organizational goal already on the sponsor's agenda.** Rather than asking a sponsor to introduce InnerSource as a standalone topic, connect it to whatever strategic priority or goal the sponsor is already planning to discuss. A message that reinforces something the audience already expects to hear about is far more likely to land and far easier for the sponsor to deliver naturally. |
There was a problem hiding this comment.
"Tie the message to an organizational goal already on the sponsor's agenda" — love this in principle, but how does the program manager know what's on the sponsor's agenda? This assumes a level of ongoing relationship and access that isn't always there. Worth a sentence on how you establish that.
There was a problem hiding this comment.
Valid point. This assumes an ongoing relationship with sponsors, which we built intentionally. The InnerSource program manager had access to each sponsor's quarterly organizational goals, which provided the initial context. More importantly, we made this an explicit ask during the quarterly sponsor readouts. We'd ask sponsors upfront what upcoming meetings they had and what goals they were already planning to communicate. Their teams would then share their agendas in advance, giving us visibility into where InnerSource could naturally fit. So it wasn't that we had magical foresight, it was that establishing this as a planned conversation, rather than an ad-hoc request gave us the access we needed. The relationship was built over time through consistent, structured communication in the readouts.
I can add this to the pattern - "Make this an explicit ask during sponsor readouts. Ask each sponsor upfront what upcoming meetings they have and what organizational goals they are already planning to communicate, so they can share their agendas in advance and you can identify where InnerSource naturally fits."
There was a problem hiding this comment.
Added - "Make this an explicit ask during sponsor readouts. Ask each sponsor upfront what upcoming meetings and organizational goals they're planning to communicate, so they can share their agendas in advance and you can identify where InnerSource naturally fits."
| **4. Offer two delivery modes and let the sponsor choose.** Some sponsors are comfortable delivering the message themselves and sharing the link on the program's behalf; others prefer the program team to attend the meeting directly and post the link into the chat at the right moment. Supporting both keeps the ask low-effort for sponsors while preserving accuracy when they want the extra support. | ||
|
|
||
| **5. Track the resulting portal traffic.** Monitor portal visits around the date and time of each sponsor-amplified mention. A visible spike immediately following the meeting is both feedback that the channel is working and concrete evidence to bring back to sponsors and the program's own leadership about the value of their advocacy. | ||
|
|
There was a problem hiding this comment.
The whole solution depends on a sponsor readout that is defined in "Sponsor Communication and Engagement" — a pattern that is still pending review in PR #931. If that pattern doesn't merge, readers can't implement step 1. The dependency needs to be acknowledged more explicitly in Context, not just in Related Patterns.
There was a problem hiding this comment.
I have called this out explicitly under "Context" section- "This pattern assumes the organization has already established recurring sponsor readouts as the primary communication mechanism with the program's sponsors (see the companion pattern "Sponsor Communication and Engagement"). Without that structured cadence, the planning venue for sponsor-amplified mentions doesn't exist."
Co-authored-by: Amburi Roy <amburi.roy@gmail.com>
spier
added
the
1-initial
3 participants
Two new, related InnerSource patterns building on the previously submitted Sponsor Communication and Engagement pattern: