Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define a process for including our Engineering Team in negotiations and statements of work for leads #569

Open
choldgraf opened this issue Nov 17, 2022 · 0 comments
Labels
Community Engaging and cultivating communities that we currently serve. Engineering:SRE Cloud infrastructure operations and development. Enhancement An improvement to something or creating something new. Partnerships Creating and fostering new collaborations with external groups

Comments

@choldgraf
Copy link
Member

Context

We have had a few instances now where our Engineering and Community Guidance teams were "surprised" at requests they were getting from communities. These happened because of mis-matches in our understanding of our responsibilities, and the community understanding of our responsibilities given the contracts they've agreed to.

For example, in some cases we have signed contracts that suggest 2i2c will perform development for communities as part of the service, or that we will help with use-cases. Neither of these are part of the original "2x2 product matrix" that we have defined, though they may be useful for us to commit to nonetheless.

Setting aside what is the "right" kind of deliverable for us to commit to, we cannot have surprises in expectations in any of our teams. Given that we are asynchronous, we pay a large penalty when we do not have efficient and timely information sharing between teams about what our commitments are. This is especially true between the "Partnerships" team, which generates new commitments for 2i2c, and our "Community Guidance" and "Engineering" teams, who must now fulfill those commitments.

Proposal

We should define a way for Engineering and Community Guidance to have input in any non-standard contracts that we are working on. This means anything that deviates from what exists in our "standard" hub service offering and pricing. In these cases, we need to provide extra visibility for this work so that these teams know what's coming and so that they can influence the negotiation process if needed.

References

This will also require defining a "Source of Truth" for our "leads in progress", which is tracked in this issue:

And will also benefit from us making "Our responsibilities" clearer:

Updates and actions

No response

@choldgraf choldgraf added Enhancement An improvement to something or creating something new. Partnerships Creating and fostering new collaborations with external groups Community Engaging and cultivating communities that we currently serve. Engineering:SRE Cloud infrastructure operations and development. labels Nov 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Community Engaging and cultivating communities that we currently serve. Engineering:SRE Cloud infrastructure operations and development. Enhancement An improvement to something or creating something new. Partnerships Creating and fostering new collaborations with external groups
Projects
None yet
Development

No branches or pull requests

1 participant