Introduction
This is a proto-document (a first pass at something which is my opinion and could eventually become a canonical doc) to describe my thoughts around how any contributor in the SourceCred community could propose a new project of any size.
This would be useful for two major reasons: 1. contributors with less context than the core team can have an avenue through which they can put forward new ideas to our existing issues, and 2. makes sure that all projects/ideas (regardless of who they come from) are addressing real problems and have a concrete plan of action.
We want contributors who are relatively new to the community (though with a defined minimum level of trust and context) to be able to propose new projects and ideas within initiatives. It gives new contributors the avenues they need to start getting engaged, and it encourages people of different backgrounds to bring us new perspectives on our problems or goals. Even if we do not end up moving forward with a proposed project or idea, it is important to have a way for people to be heard for their ideas and perspectives as they move through our container.
Beyond allowing new contributors to get involved, it also creates a good framework to make sure that when a team is putting its effort towards achieving a goal, that there is a team-wide consensus/understanding about why they are working towards their goal, how they plan to achieve it, and how they’ll know when they’ve succeeded. I theorize that this will create better use of many people’s time and a more efficient collaboration which produces better results without burning out key contributors and champions.
The way I propose we make this accessible is through a protocol. A list of items a team of contributors should discuss together before putting significant effort into a new project. This will require everyone on the team to spend a little extra time coordinating upfront, but I frequently find that at the beginning of a new endeavor 5 minutes of thinking is worth 15 minutes of action.
The Protocol
This protocol is meant to aid small to medium sized groups of SourceCred contributors as they bring forward new ideas, make sure their ideas are aligned with the larger vision, and create a plan to make something new.
If you are an individual with no team (either because you don’t need a team, or because you haven’t assembled one yet) putting forward a new initiative/project, then take the time to write up a new Discourse Topic which lays out the answers to these five questions. Then, bring the fully formed idea and plan to whichever regular meeting is held for that branch. There you can get a greenlight and/or some additional folks to help you realize the vision.
It consists of 5 discussion topics you should synchronously consider with all of your teammates:
- The Problem
- The Mission
- The Success
- The Strategy
- The Tactics
Have you and a few other SourceCred contributors come up with a cool idea? Something you’d like to design, create, build, or solve for within the way SourceCred works? That means it’s time to gather up everyone who is interested in helping you and set up a synchronous meeting together to answer the questions posed below.
1. What is the problem your team is solving for?
When starting a new collaborative project, it’s important to identify that you’re solving for an actual issue in the community. Otherwise, you may finish your project and find that your end result doesn’t fit in very well with the needs of the community and you’ve wasted your time. It’s also important to make sure that everyone in the team agrees about what the problem is, or you could end up in confusing arguments with your teammates. It’s also useful to find consensus on how urgent the problem you’re solving for is. This helps everyone agree on a pace for the completion of the project which will inform your bandwidth commitments/requirements and strategy/tactics.
Questions to ask:
- What is the issue or problem we want to fix with our idea?
- Why is it important to resolve this issue or problem?
- How urgent is this issue, and approximately how long do we have to work on it?
- Is our idea feasible within this timeframe?
If you cannot answer these questions well, then you may consider that your idea is not meeting the needs of the community yet. Try getting more in touch with what the true problem is, and how the community needs it resolved before coming back to the protocol.
2. What is your team’s mission?
Within the scope of your idea/project, what is your mission? Define the goals that the whole team can agree on in advance, before you begin the project. Use your understanding of the problem you’re solving to help you define your mission together. Keep it as short, simple, and potent as you can. Once you’ve identified your mission, check the missions of the larger initiative you’re working within and of SourceCred as a whole, and make sure that your stated team mission does not conflict with these larger missions.
Questions to ask:
- What are we trying to achieve, and what are our overall goals while working on our idea?
- What is the simplest way we can say that goal?
- Does our stated mission conflict with the larger missions of the initiative or project branch we’re working within? How about with SourceCred’s overall stated mission?
If you have difficulty defining a unified mission, then your team may not be ready to collaborate together or may be coming from different base assumptions about what you’re working on. Try having everyone in the team share their vision of what they’re attempting to achieve when they solve the problem you identified in step 1. Getting specific will help you find the base assumptions each person is making, and see where you truly agree or disagree.
Tip: Be gentle as people describe their vision. It can be easy to get emotionally attached to your vision and hear a different opinion as an attack on your ideas. If your team is struggling with identifying a cohesive vision, give everyone the chance to say what they think and what their base assumptions were without judgement. In the end you may find out you all agreed all along, or that you may want to change your original vision to reflect the ideas your team brings forward.
If your stated mission does not align with the missions of the parts of the project you are working within, or of SourceCred itself, then your idea may not be well enough aligned with the project as a whole. This may mean that your team does not have enough context on what our community (or that specific project branch) is about and what our overall vision for the future of SourceCred is. Take some time to get more familiar with what SourceCred is trying to achieve in the world and why before you come back to this protocol.
3. How will you know when your team is successful?
You’ve identified what your goals are, and why you’re pursuing them. Now take the time to envision together what it will look like when your goals are achieved. It’s important for the whole team to be able to clearly see the end goal and when you’ve succeeded at your mission. Otherwise you’ll end up working on The Neverending Project, which is a terrible blow to morale.
Questions to ask:
- What will it look like when we’ve achieved our mission?
- What definitely needs to happen before our identified problem is solved?
-
How will we know when to pop the (figurative) champagne?
- When will we be able to say we’ve finished this project/this idea has come to fruition?
- Are our identified success conditions realistic and achievable?
If you are having trouble figuring out how to tell if you’ve completed your goals, then that may indicate that you’re trying to do too much within too wide a scope. Try working together to narrow the scope of your idea or project, it’s mission, and/or the problem you’re trying to solve. Sometimes it can help to envision the smallest, easiest, most basic version of you goals or step forward could be. You may end up going bigger than that, but starting with what is simple is often helpful.
4. What is your team’s strategy for achieving success?
Now that you know what success looks like, it’s time to brainstorm about how you could potentially get there. Look at the big-picture and identify what your team will need to do in order to get where it’s trying to go.
Tip: When brainstorming, all ideas should be welcome, no matter how outlandish or strange they may seem. Let your team have fun being creative in their problem-solving, you never know what kinds of connections will get made. This also makes it harder to get pidgeon-holed into the first idea that’s brought up.
Tip: Keep your strategy zoomed out and avoid getting too granular. There will be time to talk about how you’ll do things during the tactics section of this protocol. For now focus on the big-picture of what you’ll be doing, that’s your strategy.
Create a solid list of brainstormed strategies, and decide together as a team the best battle plan for turning your mission into a reality by solving the problem. The battle is won when you meet your success conditions.
Questions to ask:
- What are the different ways we could tackle this problem?
- What are the big-picture steps to get from having the problem, to our success conditions?
- How will we determine who takes responsibility for each part of this big-picture strategy?
- How will our team communicate about this project and keep track of the big-picture strategy as time goes on?
If you are unable to figure out the big picture strategy, then you may not have all the information or expertise needed. Try taking some time to break down the biggest pieces of action that will get your team to its identified success conditions. If no one is sure what steps need to be taken or if no one feels like they have the skills to execute a part of the strategy, then it’s time for some research and potentially to bring a more experienced person onto your team before you come back to the protocol.
Tip: When splitting up the responsibility for different sections of your project’s strategy, keep in mind who has not only the most skill at what, but also their interest/passion level, and their bandwidth availability.
Tip: Make sure you take the time to decide as a team the best way to keep in touch about the project. One example is a regular meeting. It’s important to have designated ways and times to check in about how the strategy is being implemented. Sometimes things move slower or faster than anticipated or get off track, and it’s better to talk about it and shift your expectations sooner rather than later.
5. What tactics will your team use to enact your strategy?
Once your team knows the overall structure of what needs to get done, then it’s time to decide how you’ll execute that plan. This is a great time to talk about more granular aspects like the best tools for the job, the procedure you’ll follow, the resources you’ll need, and anything else that relates to how you’ll implement your identified strategy.
Tip: It’s okay to let each team member take point for the tactics of their designated part of the strategy. If they’re doing it, they probably know best what they’ll need and in what order things should get done. For each section of the strategy, ask the questions below.
Questions to ask:
- What are the step by step actions I need to take to execute my part of the strategy?
- What materials or resources will I need?
- Are there any roadblocks or dependencies I need to wait on before taking action?
- Are there any parts of my section of the strategy that I don’t know how to accomplish?
- How long do I predict it will take me to prepare and execute the tactics for my section of the strategy?
If a team member finds themselves overwhelmed or unable to answer the questions above for their part of the project, then it may indicate that they do not have enough; expertise, bandwidth, or support. Explore whether additional research or the addition of an expert or support person would make a difference. They may need to take on a smaller part of the strategy, or delegate tasks while keeping an eye on the larger picture. It really all depends on your team and their unique skills.
Conclusion
Some teams may need the depth and granular detail with which this proto-doc is written, while other teams may only need to do a cursory checking off of the five items with their team before launching in. I wrote this doc in such an in-depth way so as to support those who don’t immediately understand what I’m talking about, or who want some really solid guidance as they start proposing projects in our community.
I encourage each individual team to decide for themselves how in-depth they want to discuss these items I’ve outlined, but to indeed discuss each one at least in a cursory way. I’d be extremely curious to see how taking the time to find an answer to these five overall questions in real time with your team before beginning a project could impact the effectiveness and cohesiveness of your efforts together. I think that it will probably benefit even those teams who feel they are fast, effective, and high context; because no amount of skill can make up for being on a different conceptual page than your teammates.
Next Steps
Regardless of whether you’re a team of contributors or a solitary individual, take the time to answer these questions about the idea/initiative/project you’re proposing, to the degree that feels appropriate. Once you’ve written up the answers and any needed explanations in a new Discourse topic, take that thought through plan to the weekly meeting for the branch you’re proposing the new initiative within to get feedback from the rest of the contributors in that branch.
To get an idea for the different branches/initiatives currently being worked on in SourceCred, check out our Initiatives Index.
If you or your team use this protocol to host a meeting before beginning a SourceCred project, I’d love to hear your feedback about the experience. Though, please give it a try before you provide any criticism.