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.
| ## 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.
|
|
||
| **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?
| * **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?
|
|
||
| **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?
|
|
||
| ## 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?
|
|
||
| ## 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?
| (feedback signal) | ||
| ``` | ||
|
|
||
| ## Solutions |
There was a problem hiding this comment.
| ## Solutions | |
| ## Solution |
|
|
||
| **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.
| **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.
3 participants
Two new, related InnerSource patterns building on the previously submitted Sponsor Communication and Engagement pattern: