Edward Withers

Oct 17 2019: Notes on learning environments

Jump to comments

-draft-

Notes on learning environments

There is a lot that goes into this.

When I work with coaches, sometimes I think of the team as a software infrastructure team whose job it is to create and maintain internal platforms and tools to allow other teams to do their own work better, more easily, and faster.

If I apply that metaphor to an educational institution, it means that the team responsible for the learning environment is a team whose job it is to help learners do their own work (learning) better, more easily, and faster.

Part of the success at Makers comes from the rapid design cycle - we have groups of learners start every four weeks, allowing very short feedback loops on what works and what doesn't - although the effect on TTJ(time to job) takes six months to see. The short feedback loop means we can innovate, run experiments from cohort to cohort, learn from failure, and incorporate success into the fabric of the curriculum.

Change must happen.

The coaching team at Makers for a lot of start-up reasons has some product management responsibility. A couple years ago we extracted a role from the coaching team to focus on longer term product vision. Here are guidelines we follow at the Academy to lower the barrier for innovation

Goal: Coaches are empowered to make changes

It's really important to me that we each have a job we love - it is my top priority as Head of Coaching. Understanding how to make changes that could benefit the team is a useful tool to help enjoy our jobs - in my experience coaches at Makers enjoy control over how they work and the work they do.

Every day we do some version of the following in order to do our work as coaches. I'd like to encourage being more explicit about this in two kinds of situations.
Identifying a problem and the consequences it is having.
What are the possible solutions?
What is the proposed solution and its expected result - how will you know?
What are the risks?
Is there a smaller version of the solution that can be implemented?
Is it safe enough to try?

1. Changes that only directly affect yourself
Most changes that only affect yourself have no need to be explicit. Some still however could be valuable to the team when made explicit.
Example: Checking in on slack with every dev to send them resources tailored to their needs during the week.
Example: During process observations, experimenting with a different kind of challenge.
* It's useful to consider and seek feedback on the above questions.
* It's useful to document and share the results of changes or experiments, so they can be pulled by other coaches as needed.

2. Changes that affect other coaches
These kinds of changes usually require some buy in or alignment. But the idea is, in order to encourage new ideas and useful experiments, that as long as it's been discussed and it's safe enough to try we should encourage each other to propose ideas.

Example: Change process workshops to be self-led where coaches don’t resource it.
Example: Change coaching hours to be all day

* Consult me where possible and other coaches as needed for the proposal
* Share a slack message or 1 page post with information as needed to cover the points above, ideally a few days before you need to decide.
* If needed, organise time to discuss
* After appropriate discussion Coaches either
- greenlight the proposal,
- think it's safe enough to try but share their reservations,
- or indicate the risks that mean it's unsafe to try.
It's really important to me that we each have a job we love - it is my top priority as Head of Coaching. Understanding how to make changes that could benefit the team is a useful tool to help enjoy our jobs - in my experience coaches at Makers enjoy control over how they work and the work they do.

Every day we do some version of the following in order to do our work as coaches. I'd like to encourage being more explicit about this in two kinds of situations.
Identifying a problem and the consequences it is having.
What are the possible solutions?
What is the proposed solution and its expected result - how will you know?
What are the risks?
Is there a smaller version of the solution that can be implemented?
Is it safe enough to try?

1. Changes that only directly affect yourself
Most changes that only affect yourself have no need to be explicit. Some still however could be valuable to the team when made explicit.
Example: Checking in on slack with every dev to send them resources tailored to their needs during the week.
Example: During process observations, experimenting with a different kind of challenge.
* It's useful to consider and seek feedback on the above questions.
* It's useful to document and share the results of changes or experiments, so they can be pulled by other coaches as needed.

2. Changes that affect other coaches
These kinds of changes usually require some buy in or alignment. But the idea is, in order to encourage new ideas and useful experiments, that as long as it's been discussed and it's safe enough to try we should encourage each other to propose ideas.

Example: Change process workshops to be self-led where coaches don’t resource it.
Example: Change coaching hours to be all day

* Consult me where possible and other coaches as needed for the proposal
* Share a slack message or 1 page post with information as needed to cover the points above, ideally a few days before you need to decide.
* If needed, organise time to discuss
* After appropriate discussion Coaches either
- greenlight the proposal,
- think it's safe enough to try but share their reservations,
- or indicate the risks that mean it's unsafe to try.

We have constraints

Based on my observations and reading, mixed in with some suggestions. These aren't meant to be distinct, discrete points, but different interpretations of the same solution space. They overlap.

Break out of the focus on Doing, and spend time helping learners get better at being more responsible, active, intentional in what they're doing, followed by reflecting, and self-assessing their progress.

  1. focus on 3 parts of the learning cycle,
    • and embed this into the fabric of the environment
  2. Create & maintain emphasis on taking care of yourself - positive mental and phsyical wellbeing The magic -> read the reviews
  3. empower the learners to drive their own learning.
    • leave them be (Frontload context, backload reflection)
    • respond to learner needs
  4. positive, and rewarding interactions
    • individual, and cohort, actioned (aggregate) feedback.
  5. Surround with images and stories of success
  6. Top end equipment

You might notice they both love The Recurse Center.

-----