Tasks
You're a coach in the first place. Whatever other skills you have are a nice plus — but it's your job to coach the students; not to do their job.
Last updated
Was this helpful?
You're a coach in the first place. Whatever other skills you have are a nice plus — but it's your job to coach the students; not to do their job.
Last updated
Was this helpful?
Make sure that your team is balanced. Match the right people with the right skills for the project, and make sure their characters will work.
Before open summer of code starts, we start screening the students beforehand. We will invite some coaches to do the screening. After that, we start building teams. Check out the page on how this works!
At the start of osoc, it's your job to manage the partner's expectations (just like you would in your own projects). Keep in mind these are students, and it's possible the outcome won't be what they want it to be. You'll have to adjust along the way in those 4 weeks.
Scoping a project is very important from the start. After you receive the briefing, ask the right questions to chop the tasks into smaller parts, prioritise the tasks and make sure the client knows what's absolutely not feasible, and what might be feasible. Not sure how to conduct a scoping session? Contact your organisation!
A non-exhaustive list of examples:
Make sure your team can communicate well, and has the tools to do so. For example: use week-plannings, physical or virtual stand-ups and retrospects.
You also can do scoping sessions now and then to break up the work into smaller pieces, and help students do better assessments of work load.
Make sure your team can spot "danger" in time, and know how to get out of it. Are they stuck? What do they have to do to get un-stuck?
How do they ship features?
How does quality testing work?
How do they test with their target audience?
Will they conduct interviews?
How does that feedback roll back to the team?
You are the arbiter of quality. You decide what is shipped, what is not, and what is communicated to the client. Of course, it's the student's job to deliver good code, a good design and a decent communication plan. It is your job to have it tested (by the students and yourself), and deliver the right information to your client in times when you see fit. For instance, you can communicate every week, every two days or every day, after every big release… depending on what you see fit. As long as your client isn't left in the dark, up-to-date and can trust you.
A client meeting happens at least once a week. Most of our students have no experience with attending or guiding a client meeting, so your presence is crucial — before (preparation), during (guidance) and after the meeting (feedback). A very experienced team can probably do this on their own at some point, but you should always be up-to-date.
The meetings should be well-prepared (agenda, demo, questions prepared), well-executed (concise, polite, clear) and written down during the meeting (meeting-minutes). A feedback session is helpful for the students to learn about what they can do better in the future.
Keep your client up to date, and don't leave them in the dark. A client needs to be able to trust your team, and know what the team is up to. You can communicate every week, every two days or every day, after every big release… depending on what you see fit.
You can delegate the communication, but make sure the students run it past you before they send it. Most students do not have a lot of experience communicating in a professional context.
Scoping sessions (SLIP)
Team assembly
Creating structure for the team
Standups
Conducting retrospects
Workflow
"Team crisis"
etc.
If you are a half time coach, there are two scenario's
You have a strong team with one or more alumni and/or a student coach that can take over tasks
You have a expert or butterfly coach that will take on technical questions
Your expert or butterfly coaches and alumni/student coaches are here to make sure you have someone to bounce ideas off and make decisions faster. They are your ally, and you can prepare for battle together.
Keep your expert/alumni/student coaches up-to-date about what happened, and make sure there's a hand-over when the you're not available (tasks, problems, progress). You can hand over the information yourself, or delegate it to your students in a structured way.
Maintain structure and quality for the team together
If you need to check in with someone else, you can always ask help from other coaches or the lead coach!
You're a coach in the first place. But you'll also have other skills. For instance, you're a designer, a dev, a marketer, a copyright expert or a yogi.
Other teams might need your expertise to move forward; and you might need an other coaches' expertise as well. Osoc is all about sharing and learning from each other. So it's your job to figure out who is on board, to ask for help whenever you or your team needs it — and to help others out. Right now, we don't have a great system for this (yet), so grab your fellow coaches for lunch in the first week and get to know each other ;-)
You have a set of skills other coaches might not have. For instance, a team needs feedback on a poster design and only has dev coaches. Or a designer coach has no clue how to help their team with implementing a map. Use your spare time to get to know the others, and help out a little. Sharing is caring, and you'll get to know some interesting people!
Go to for tips and tricks! Something missing? Let us know.
At the end of Osoc, you'll also hand in a big with your students, that contains all the work.
Everybody needs to start somewhere. Not every coach knows what to do from the start, and this is why we have an assistant coach program. We assist you with . This includes: