A Teaching Team Member is an individual-contributor to a project who is willing and able to help a learning team member to progress as a developer.
Responsibilities of a Teaching Team Member include…
- Offering yourself as available (on terms you set) to Learning Team Members who need pair-programming, advice, and other guidance. When approached on the outlined terms, you should be responsive and friendly to your Learning Team Member(s).
- As a “Teaching” (or “Senior”) Team Member, you hold responsibility to setting norms of code quality, code techniques, external dependencies, and development workflow for your project(s). In collaboration with the Project Leader, you decide the technologies to use, and workflows that make sense. (Where you are both a the sole Project Leader and Teaching Team Member, you’ll simply do this my your own discretion and private decision making.)
- You are explicitly not responsible to make sure that the Learning Team Member remains engaged and active. You shouldn’t scare them off, nor turn them away. But it is the responsibility of the Learning Team Member to make sure that they stay involved and learning. You answer questions and pair program (where you’ve invited those things), they must take responsibility for their learning, however.
- You are also an individual contributor. This means that you’re doing development and regularly pushing code. There’s no requirement of volume or frequency of your code, but ideally you’ll push something at least one time per month. More frequent is encouraged, but we do understand you have a life and day job.
Teaching Team Member count and capacity
Ideally, every project should have at least one Teaching Team Member. That will often be the Project Leader, but doesn’t need to be. There isn’t an upper limit on the number of people will have this role on a project, but given current brigade-size and project-volume (in late 2018) there probably shouldn’t be more than three on any project.