Repository navigation
Create gig-marketplace.md - #101
stephenmccall wants to merge 1 commit into
Conversation
This is the initial commit of the Gig Marketplace pattern.
rrrutledge
left a comment
rrrutledge
left a comment
There was a problem hiding this comment.
This is really cool, @stephenmccall. Leaving a few comments that came to mind as I read. Looking forward to calling about this. Thanks for sharing!
| * Create an intranet marketplace where InnerSource project owners and potential contributors can easily discover one another | ||
|
|
||
| ## Patlet | ||
| Establish a marketplace by creating a website(s) that lists InnerSource project needs as "gigs". |
There was a problem hiding this comment.
Kind of sounds a bit like Top Coder but internal to the company?
There was a problem hiding this comment.
That's the general idea, but the intended outcomes are so much different. The Gigs posted are also used as "proof of ability" for the developers accepting them after they are completed. Another main objective is for developers, not managers, to post Gigs allowing them to work with one another to accomplish just about anything they can think of. It's a mechanism that flattens the organizational hierarchy, ignores BU affiliations and opens up the whole company wide development community as a resource for anyone to potentially leverage.
There was a problem hiding this comment.
Based on comments from @rshanmer : looks good, length wise. Also focuses on solution, which is how it should be�. Possible elaborate on the content of the 2nd sentence.
There was a problem hiding this comment.
from @NewMexicoKid : Would it be helpful to introduce a length limit of patlets?
@rshanmer : Maybe limit to two sentences, instead of going for a #characters limit.
all: two sentences sounds like a reasonable choice.
| ## Forces | ||
| * Individuals are trapped within their business units/teams and do not often interact with those outside of them | ||
| * Individuals are experiencing downtime on projects where they are underutilized | ||
| * Managers are reluctant to allow involvement in work outside of their business unit priorities |
There was a problem hiding this comment.
Is this at-odds with this line in the Context?
Individuals have been given some time by their management
There was a problem hiding this comment.
Maybe not "at odds" with but these sections of the pattern do need to be better balanced. This is where we could really use some help from the rest of the forum who might have more experience authoring other patterns.
There was a problem hiding this comment.
Sounds like a good topic for the call.
| * Managers have no way of knowing what the true time/effort commitment will be if their employee chooses to take on tasks to support an InnerSource project. | ||
| * There is no way of tracking or rewarding an individual's involvement in an InnerSource project. | ||
|
|
||
| ## Forces |
There was a problem hiding this comment.
Recommend rephrasing some of these lines to reference why the particular activity is important instead of just saying that the activity isn't happening.
e.g. Managers have no way of understanding what the time/effort commitment is for their employees wanting to get involved in an InnerSource project outside of their business unit becomes sometime like Part of a manager's job is tracking, estimating and understanding use of employee time.
There was a problem hiding this comment.
True. Good point. We should also edit this to include more of the motivations behind why individuals would want to take on a Gig. To learn a new skill, demonstrate expertise, help someone out etc... Right now it is too "manager"-centric. The Gig Marketplace is actually something that benefits individual employees from a professional development perspective more than it does managers looking for assistance in getting day to day work completed.
There was a problem hiding this comment.
Sounds good. Looking forward to continuing to work on this pattern together!
| This makes it explicit what the commitment is and that management agrees with it while encouraging and tracking involvement. | ||
|
|
||
| ## Problem | ||
| There is no single, uniform way for InnerSource project owners and potential contributors to discover each other and connect. |
There was a problem hiding this comment.
Based on the context and forces it sounds like there are a few other problems that this pattern helps to solve (e.g. estimating commitment and tracking achievements).
There was a problem hiding this comment.
Exactly. The "tracking achievements" part is probably the most compelling. Although being able to communicate exactly how much time you are expected to spend on the task is a huge selling point for those looking for approval from their direct management to get involved.
There was a problem hiding this comment.
That's cool. I (personally) think it would be fine to list out multiple problems that this pattern addresses.
There was a problem hiding this comment.
Here I go again ;). I propose to state the problem more clearly and explicitly in the problem section. I guessing the problem is that opportunities for collaboration are wasted?!
There was a problem hiding this comment.
Suggestion from the group: split this pattern in two:
- Publish InnerSource projects on easily accessible website
- Establish Gig Marketplace to ....
from @rshanmer : The Gig Marketplace seems to solve multiple problems. Find stuff to work on. Also making mgmt. comfortable with their people working on InnerSource management.
from @stephenmccall : The original focus of the Git Marketplace was the performance management directed toward people.
from @russ: Feels that the patter should on performance management
frpm @daniel: Does this depend on existence of trusted committers, contribution guidelines e.t.c.?
from @stephenmccall : These topics are closely intertwined.
from @daniel: Also closely linked to problem of findability
from @NewMexicoKid and @dicortazar : let's add links to related patterns whereever the related patterns are mentioned.
| There simply is no single uniform way for contributors to discover all the InnerSource opportunities that exist that they might be interested in contributing to. | ||
| Conversely, innerSource project owners also have no way of informing a general audience about their projects and its goals. | ||
|
|
||
| ## Context |
There was a problem hiding this comment.
Maybe some of the no way assertions here are a little strong? Could just say that it's "difficult" to make the pattern more broadly-applicable?
There was a problem hiding this comment.
True. We should soften that language for the general pattern. In fact, this entire section should most likely be rewritten to speak more about the motivations for creating a Gig Marketplace as opposed to InnerSource projects per se.
| * There is no single portal through which potential InnerSource contributors can discover project opportunities | ||
|
|
||
| ## Solutions | ||
| Several separate initiatives were spawned across business units and then brought together by the InnerSource governance team to create an intranet based InnerSource marketplace. |
There was a problem hiding this comment.
This piece of context and detail feels specific to an instance of application of this pattern rather than a core part of the pattern itself?
There was a problem hiding this comment.
Completely agree. Again, this is a holdover from a previous document describing the relationship between the InnerSource program at Fidelity in general and how it relates to the Gig Marketplace. We should only be talking about the Gig Marketplace in the "Gig Marketplace" pattern! :)
|
|
||
| The second was a “gig” based intranet site where individuals could advertise their areas of expertise and project owners could list opportunities for collaboration describing exactly the skill and time requirements needed. To reward participants a points based system was attached to every action. Points accrued by accepting a gig are then captured and used as performance management criteria. All interactions are tracked via a public dashboard to measure and communicate the overall health of the marketplace. | ||
|
|
||
| ## Resulting Context |
There was a problem hiding this comment.
It's neat to see parts of this resulting context referencing items in the original context. Some of the original points of context are not referenced in this result, though (e.g. insight of managers to what their employees are doing). Recommend talking about the resulting context for each point of the original context.
There was a problem hiding this comment.
Agreed. I'd like to sort out what to include as part of each of these sections as part of our next group review.
rrrutledge
left a comment
rrrutledge
left a comment
There was a problem hiding this comment.
Hey, @stephenmccall, thanks for engaging on these comments! I feel like this conversation we're having is useful in prepping for our upcoming call.
| * Create an intranet marketplace where InnerSource project owners and potential contributors can easily discover one another | ||
|
|
||
| ## Patlet | ||
| Establish a marketplace by creating a website(s) that lists InnerSource project needs as "gigs". |
| This makes it explicit what the commitment is and that management agrees with it while encouraging and tracking involvement. | ||
|
|
||
| ## Problem | ||
| There is no single, uniform way for InnerSource project owners and potential contributors to discover each other and connect. |
There was a problem hiding this comment.
That's cool. I (personally) think it would be fine to list out multiple problems that this pattern addresses.
| * Managers have no way of knowing what the true time/effort commitment will be if their employee chooses to take on tasks to support an InnerSource project. | ||
| * There is no way of tracking or rewarding an individual's involvement in an InnerSource project. | ||
|
|
||
| ## Forces |
There was a problem hiding this comment.
Sounds good. Looking forward to continuing to work on this pattern together!
| ## Forces | ||
| * Individuals are trapped within their business units/teams and do not often interact with those outside of them | ||
| * Individuals are experiencing downtime on projects where they are underutilized | ||
| * Managers are reluctant to allow involvement in work outside of their business unit priorities |
There was a problem hiding this comment.
Sounds like a good topic for the call.
|
|
||
| The second was a “gig” based intranet site where individuals could advertise their areas of expertise and project owners could list opportunities for collaboration describing exactly the skill and time requirements needed. To reward participants a points based system was attached to every action. Points accrued by accepting a gig are then captured and used as performance management criteria. All interactions are tracked via a public dashboard to measure and communicate the overall health of the marketplace. | ||
|
|
||
| ## Resulting Context |
gruetter
left a comment
gruetter
left a comment
There was a problem hiding this comment.
Excellent new content. Thanks a lot for this @stephenmccall ! Looking forward to discuss this tomorrow.
One idea, though: What do you guys think about splitting this pattern up into two: one for an InnerSource portal to increase discoverability of projects, and one (this one) for the Gig Marketplace. Sound like two related but distinct patterns to me.
| * Create an intranet marketplace where InnerSource project owners and potential contributors can easily discover one another | ||
|
|
||
| ## Patlet | ||
| Establish a marketplace by creating a website(s) that lists InnerSource project needs as "gigs". |
| This makes it explicit what the commitment is and that management agrees with it while encouraging and tracking involvement. | ||
|
|
||
| ## Problem | ||
| There is no single, uniform way for InnerSource project owners and potential contributors to discover each other and connect. |
There was a problem hiding this comment.
Here I go again ;). I propose to state the problem more clearly and explicitly in the problem section. I guessing the problem is that opportunities for collaboration are wasted?!
|
|
||
| ## Context | ||
| * There are multiple business units in your organization that do not communicate well. | ||
| * Individuals have no way of discovering what InnerSource opportunities exist across the entire company. |
There was a problem hiding this comment.
As @rrrutledge mentioned above, I'd soften the no way here, too. I'm also wondering if this shouldn't be in the forces section. General rule: things that can't be changed should be put in the context section. Things that can be changed belong in the forces section. Since this pattern proposes a solution to the discovery problem, I'd say this should go in the forces section.
There was a problem hiding this comment.
from @rrrutledge : when we split up this pattern into two, might this be omitted in this pattern and be moved to the other pattern (portal)
from @stephenmccall : this one is about opportunities so I don't think so
from @NewMexicoKid : This is also a good problem statement - one part of it
| * There are multiple business units in your organization that do not communicate well. | ||
| * Individuals have no way of discovering what InnerSource opportunities exist across the entire company. | ||
| * InnerSource project owners have no way of advertising their project to potential contributors. | ||
| * Individuals have been given some time by their management to get involved in InnerSource projects of their choosing. |
There was a problem hiding this comment.
Is that a necessary precondition? I've seen over and over again, that people just contribute because they think it is right, without their management giving explicit permission.
There was a problem hiding this comment.
from Georg: is this also applicable without the mangement consent
from @stephenmccall : not a necessary condition but enables an InnerSource program to succeed
from @NewMexicoKid : it's also inspirational for people who might not have this consent in their companies
from Georg: is this really a precondition for the applicability of this pattern?
from @NewMexicoKid : not all of the context needs to apply in order for the pattern to be applicable.
from @stephenmccall : if people don't have that consent, it makes it harder to apply this pattern. "Hey boss, I just completed this gig. What d'ya think?" Probably a difficult argument.
from @rrrutledge : A real marketplace is only valuable if there's money/capacity to spend.
from all: let's keep this bullet point.
| ## Context | ||
| * There are multiple business units in your organization that do not communicate well. | ||
| * Individuals have no way of discovering what InnerSource opportunities exist across the entire company. | ||
| * InnerSource project owners have no way of advertising their project to potential contributors. |
There was a problem hiding this comment.
Is this a necessary precondition? They might have a way, but it might not be a good one.
There was a problem hiding this comment.
from @rshanmer : should go into the problem section of the other (new) pattern
|
|
||
| ## Forces | ||
| * Individuals are trapped within their business units/teams and do not often interact with those outside of them | ||
| * Individuals are experiencing downtime on projects where they are underutilized |
There was a problem hiding this comment.
Stupid question: does this actually happen? Not kidding ...
There was a problem hiding this comment.
@gruetter by your earlier comment maybe not a force?
There was a problem hiding this comment.
It is relevant for the pattern if underutilization is a thing so I wouldn't leave that out, in any case. I propose to move this to the resulting context section and rephrase it as a benefit. Something like "Developers who are experiencing a temporary underutilization can put their free time to good use using the Gig Marketplace."
| * Individuals are experiencing downtime on projects where they are underutilized | ||
| * Managers are reluctant to allow involvement in work outside of their business unit priorities | ||
| * Managers have no way of understanding what the time/effort commitment is for their employees wanting to get involved in an InnerSource project outside of their business unit | ||
| * Managers have no way of tracking or rewarding their employee's involvement in InnerSource projects |
There was a problem hiding this comment.
General idea: I kinda like to formulate forces differently than the bullet points in the context section. I usually do it in the form of a tradeoff, to signal that the force is something ... malleable (not sure that's the right word). So in this case e. g., this would sound something like
The less insight a manager has into the effort and accomplishment of their employees in InnerSource projects, the more unlikely it is that he can reward their employees for their InnerSource work.
Just my 0.02$ on pattern style, though.
| ## Solutions | ||
| Several separate initiatives were spawned across business units and then brought together by the InnerSource governance team to create an intranet based InnerSource marketplace. | ||
|
|
||
| The first was an InnerSource project portal. This was an intranet site where InnerSource project owners could plug in the URL to their Git repo and (via the inclusion of an “innersource.json” file to their codebase) display small cards of information describing their projects. Each of these were then indexed and made searchable by end users based on a number of criteria including business unit name, technologies in use or trusted contributor names, etc. |
There was a problem hiding this comment.
Sounds like good content for the Known Instances section, though. So far we've just listed company names but some pattern books list more detailed descriptions of how they applied the pattern in practice.
| Conversely, innerSource project owners also have no way of informing a general audience about their projects and its goals. | ||
|
|
||
| ## Context | ||
| * There are multiple business units in your organization that do not communicate well. |
There was a problem hiding this comment.
Some alternative language (if you like it): ... multiple pockets of engineering in ...
| * Create an intranet marketplace where InnerSource project owners and potential contributors can easily discover one another | ||
|
|
||
| ## Patlet | ||
| Establish a marketplace by creating a website(s) that lists InnerSource project needs as "gigs". |
There was a problem hiding this comment.
Based on comments from @rshanmer : looks good, length wise. Also focuses on solution, which is how it should be�. Possible elaborate on the content of the 2nd sentence.
| * Create an intranet marketplace where InnerSource project owners and potential contributors can easily discover one another | ||
|
|
||
| ## Patlet | ||
| Establish a marketplace by creating a website(s) that lists InnerSource project needs as "gigs". |
There was a problem hiding this comment.
from @NewMexicoKid : Would it be helpful to introduce a length limit of patlets?
@rshanmer : Maybe limit to two sentences, instead of going for a #characters limit.
all: two sentences sounds like a reasonable choice.
| This makes it explicit what the commitment is and that management agrees with it while encouraging and tracking involvement. | ||
|
|
||
| ## Problem | ||
| There is no single, uniform way for InnerSource project owners and potential contributors to discover each other and connect. |
There was a problem hiding this comment.
Suggestion from the group: split this pattern in two:
- Publish InnerSource projects on easily accessible website
- Establish Gig Marketplace to ....
from @rshanmer : The Gig Marketplace seems to solve multiple problems. Find stuff to work on. Also making mgmt. comfortable with their people working on InnerSource management.
from @stephenmccall : The original focus of the Git Marketplace was the performance management directed toward people.
from @russ: Feels that the patter should on performance management
frpm @daniel: Does this depend on existence of trusted committers, contribution guidelines e.t.c.?
from @stephenmccall : These topics are closely intertwined.
from @daniel: Also closely linked to problem of findability
from @NewMexicoKid and @dicortazar : let's add links to related patterns whereever the related patterns are mentioned.
| * InnerSource project owners have no way of advertising their project to potential contributors. | ||
| * Individuals have been given some time by their management to get involved in InnerSource projects of their choosing. | ||
| * Managers have no way of knowing what the true time/effort commitment will be if their employee chooses to take on tasks to support an InnerSource project. | ||
| * There is no way of tracking or rewarding an individual's involvement in an InnerSource project. |
There was a problem hiding this comment.
from @rshanmer : the last two bullet points should go into the forces section
There was a problem hiding this comment.
from @dicortazar : we might be able to measure this, actually. People might not just be aware how
from @stephenmccall : yes, this is probably too strict. Soften statement a bit.
from @dicortazar and @stephenmccall : suggestion: "peoples activities and specific contributions are currently not tracked so managers don't know how to reward it"
| ## Context | ||
| * There are multiple business units in your organization that do not communicate well. | ||
| * Individuals have no way of discovering what InnerSource opportunities exist across the entire company. | ||
| * InnerSource project owners have no way of advertising their project to potential contributors. |
There was a problem hiding this comment.
from @rshanmer : should go into the problem section of the other (new) pattern
|
|
||
| ## Resulting Context | ||
| In combination these systems of discoverability have vastly increased the number of possibilities for InnerSource opportunities. The self-directed nature of these tools have enhanced the employee experience while also providing a constant source of tasks for employees to pivot too in the event they are underutilized by their current teams. | ||
|
|
There was a problem hiding this comment.
from @stephenmccall : add: "the Gig Marketplace allows you to validate employees skill sets."
| The first was an InnerSource project portal. This was an intranet site where InnerSource project owners could plug in the URL to their Git repo and (via the inclusion of an “innersource.json” file to their codebase) display small cards of information describing their projects. Each of these were then indexed and made searchable by end users based on a number of criteria including business unit name, technologies in use or trusted contributor names, etc. | ||
|
|
||
| The second was a “gig” based intranet site where individuals could advertise their areas of expertise and project owners could list opportunities for collaboration describing exactly the skill and time requirements needed. To reward participants a points based system was attached to every action. Points accrued by accepting a gig are then captured and used as performance management criteria. All interactions are tracked via a public dashboard to measure and communicate the overall health of the marketplace. | ||
|
|
There was a problem hiding this comment.
from @stephenmccall : it helped that the BU which started the portal had responsibility for similar type of systems/portals.
| * There is no single portal through which InnerSource project owners can advertise the existence and goals of their projects | ||
| * There is no single portal through which potential InnerSource contributors can discover project opportunities | ||
|
|
||
| ## Solutions |
There was a problem hiding this comment.
from @rshanmer : add a first "do-this" sentence to the solution along the lines of "create a marketplace for InnerSource Gigs/needs"
| * There is no single portal through which potential InnerSource contributors can discover project opportunities | ||
|
|
||
| ## Solutions | ||
| Several separate initiatives were spawned across business units and then brought together by the InnerSource governance team to create an intranet based InnerSource marketplace. |
There was a problem hiding this comment.
from @stephenmccall : propose to remove this bullet point altogether
| ## Solutions | ||
| Several separate initiatives were spawned across business units and then brought together by the InnerSource governance team to create an intranet based InnerSource marketplace. | ||
|
|
||
| The first was an InnerSource project portal. This was an intranet site where InnerSource project owners could plug in the URL to their Git repo and (via the inclusion of an “innersource.json” file to their codebase) display small cards of information describing their projects. Each of these were then indexed and made searchable by end users based on a number of criteria including business unit name, technologies in use or trusted contributor names, etc. |
There was a problem hiding this comment.
from @dicortazar : we are using the specific word marketplace but there's no mention of selling anthing
from @stephenmccall : what are the buyers and sellers?
from @dicortazar : different BUs are offering time, capacity or money (sellers) and the developers (BU) could use that (buyers). How are the "selling" BUs reimbursed for their offering?
from @stephenmccall : the reward is being able to say "I did this". There are no physical rewards attached to work done.
from @dicortazar : the developers are being rewarded by their organization. It would be a good idea for the selling business units to be reimbursed by the "buying" business units.
from @stephenmccall : this should happen at some point, but we wanted to start this as "pro bono" to get things going. Might evolve to Daniels suggestion.
from @rshanmer : related to the performance management section. There are three parties: management rewarding their developers for doing work for a 3rd party (as part of performance management). I feel this constitutes a marketplace.
from @stephenmccall : there is inherent benefit in doing the work itself. Unsure whether there need to be additional benefits
from @NewMexicoKid : is it also a people marketplace? A tool for BUs to find people with certain skills? What implications might that have for the "buying" business units? (loosing their best people?)
from (unattributed): Talent hoarding can be a problem in companies; people's mobility around the company is limited. There was a program to solve this: You can allow people to secretly share their resume. This can be tied into this same idea.
maxcapraro
added
the
Stale
lenucksi
added
the
📖 Type - Content Work
|
@gruetter sorry to bother you with this but I see that you gave a bunch of feedback to this PR in 2018, so I figure that you might be able to help me with this question: We have a version of the Gig Marketplace in the main branch already. I cannot clearly tell but it looks like what we have in main is actually newer than the version of the pattern that was reviewed in this PR. So I am inclined to just close the PR (without merging it). What do you think? |
|
The version of the pattern discussed in this PR has substantially diverged from the one now on |
|
Agree with @gruetter. |
|
Awesome, thank you for the confirmation both of you! And @stephenmccall if you are still working in InnerSource environments, we would love to hear what new experiences you have made in the meantime. Either in Slack or who knows, maybe even in a new pattern? 🚀 Closing this PR. |
This is the initial commit of the Gig Marketplace pattern.