Edward Withers

Dec 4 2017: Notes on Coaching

Jump to comments

Jump to Part 2 (Nov 4 2019)


I'm six months in coaching at Makers Academy, helping beginners learn how to program. But I'm a beginner too. I'm at the beginning of a journey to get better at coaching. And to get better at anything, it's key to understand what exactly you're doing and how you're doing it. This essay is a reflection on a particular part of my approach to coaching at Makers Academy.

No one could argue this fact: the learning environment of a student is integral to the learning trajectory of the student.

I want to talk about a learner's control over their environment.

In order to do so, let's set some context.

Teachers have responsibility for the learning environment

In a nutshell, teachers have responsibility for almost all of the learning environment. In a traditional setting, quite critically this responsibility inevitably translates into control over it. Usually the reasons are:

  1. Learners start off not caring about their learning
  2. Learners don't have objectives for after their learning
  3. Education at scale tends towards the least resource intensive approach
  4. Regular standardised qualitative assessment

This usually causes a few things to happen:

  1. Most students rely on the teacher to set objectives, feed information to them, and then test that they have learnt it.
  2. Students don't take ownership of the learning space, or their learning
  3. Teachers try to control more of the environment and then also individual learning

It's somewhat unfair to compare the two settings given that at Makers the students are adults, they have paid significantly to be there, and they have committed to a career change, which has already imbued them with far more control than the typical student at school or university. However what's important to note is the set of expectations people have of an educational environment. Students and teachers alike.

The question is how to hand back control to re-empower students to care about their learning. Once that starts happening, then we can talk about individual strategies to accelerate learning and much more. But the key part is even with the privilege of having (for the most part) committed students, what ways can we continue to encourage and reinforce the idea that they should control their own learning environment.

Peer to Peer coaching

Aside from the ways in which our curriculum, course materials, & methodology help, my perspective is that, all the rest being equal, the best learning happens in an environment where the power dynamics between the teacher and the students is lowered as far as possible. I strive for the somewhat idealistic scenario where the only imbalance between me and the other people in the room is the knowledge and experience I have compared to the others.

This is a mindset: as a teacher, you have to believe everyone in the room is an equal and even such categorisations as teacher and students is laden with traditional dynamics. Experienced dev and less experienced devs; I maintain the perspective we're all developers in the room, I'm just more experienced. (I use the terms student and teacher in this essay only to be clear..)

This perspective focuses on the imbalance on knowledge and brings the education out from a classroom setting to a setting focused on transferring knowledge, skill, and behaviour.

So here is a list of things to avoid and what to do instead:

Things to avoid doing

Lecturing in order to impart knowledge

From the perspective of handing control over to students, there are two problems with lecturing.

  1. Having someone talk at length constrains the types of learning a student can use. It relies heavily on a student listening and taking notes for an extended period of time. However studies suggest some of the best learning happens when you build or play with the thing you're trying to learn.

  2. The choice of topic is usually not suited to everyone in the room because students are at different learning points. On top of that a long lecture doesn't easily allow for responding dynamically to these individuals.

Alternative: Essentially, the less lecturing the better. Keep lecturing to fifteen - twenty minutes maximum in order to set context for an exercise. Ask a lot of questions to gauge understanding, and throwback to the students to answer each other's questions. I have a name randomiser that they can see so all students are asked questions equally. Allow students to decide how they learn.

Using Jargon

Don't use it. I see this happen all the time. It is difficult to remember being a beginner without technical vocabulary. I know i've definitely used terms like Sinatra, Rails, interface, type, mocking, even the word object without realising that to a beginner the words mean differently. These words have specific meaning for an experienced dev, but in beginners' heads these words are either confused, wrong, or they don't have a mental model of it. And yet they usually feel they are expected to know all of the words being said. Learners should be able to choose how much abstraction/new terms they confront.

Alternative: Avoid using technical words as much as possible. Use diagrams on the board, have a list of jargon and links to articles that explain or give a short description. Use evidence from running bits of code on a projector rather than describing it with words.

Trying to solve a student's problems yourself

Naively I used to think that I can help students by offering them solutions to their problems. I've seen the thing, or experienced the thing, it's efficient for me to give my advice. Don't do this. Learning has to come from a place of struggle which is reflected upon and a process developed to resolve it. In this situation the process is getting the coach to resolve the problem. Remember: most problems are related to weak or non-existent processes in problem solving.

Alternative: Lead them through a process they can repeat by themselves when they are stuck or overwhelmed. Often the short term benefit is tempting, but the best thing a student can learn is behaviour: the mindset of how to approach their learning. Next is a skill: getting better at applying a certain learning technique. Guide, demonstrate if needed, better process or processes. Better yet if you can get the student to derive their own.

Having a fixed way of doing things

Usually this looks like some of the following:

  • answering the same way to all students
  • the same material delivered in the same way every iteration.
  • not exploring an avenue for learning if it presents itself
  • not soliciting/ listening/ acting upon feedback

Alternative: Be dynamic as possible. I try to distinguish my responses in three types roughly based on the understanding of a student: walking, jogging, running. This approach requires having effectively three courses and to be able to respond effectively to the students. Students and a student body, especially small groups of 25 are variable things. Responding to the group's need even though at the same point of the course another group needed something different is super important to reinforce the sense of control the students have over their learning environment. This requires their constant feedback: challenge them to reflect to see how they can improve their experience, and then act upon it if you can. I seek to make sure every time I'm asked a question, the student leaves feeling supported

Not knowing the students

Usually this creates an unconscious difference between students and teachers, as if we don't have enough time to care about getting to know them and that all we see in them are customers. The only identifiers end up being the roles we perform in the learning environment.

Alternative: People respond positively to recognition and validation. The more they feel like they belong, the more in control they will feel. Learn their names from day one, as soon as you can. Names have power, use it to call on them, and check in to show that you care.


Such is my perspective that it's a little jarring every time one of them asks me to leave a workshop to go to the bathroom, or to apologise for being away the day before, or to apologise for leaving early during the day. Usually I smile and gently remind them they are always free to do anything they wish.

Questions are the bread and butter of learning. I want learning spaces that are filled with questions. In order to do so learners have to be engaged, feel empowered, and have time & space to reflect.

Pitfalls

Essentially the knowledge imbalance isn't only confined to the development expertise I have, it is also in knowledge of the course logistics and aggregated information of past students and cohorts. This inherently causes some tension between wanting to only be the more experienced dev in the room and being a central resource for the students. If I start to centralise too much information regarding non-code related things then this takes control away from students.

For example

  • I start and stop workshops
  • I follow up with students for non-code, team dynamic reasons
  • I have intimate knowledge of the course structure, events
  • I have aggregate information of past students and cohorts

There is always tension between this ideal and the educational infrastructure needed to effectively deliver the course. We recognise it and so, as much as possible, we try to document this information specifically to hand over as much control of information back to the developers (and also to reduce the workload on us, let's be honest..) Our entire course is open to the students to have a look at and know what's happening, even to the point it's versioned and they can look back at how it has changed and developed over the months and years. And we're getting better at publicising aggregate data.

Giving up Control is Difficult

I've definitely encountered situations where I feel like I know exactly how best to guide the learning of a student and I've had to catch myself directing it. It comes from a place of wanting to help, but a naive one in that it's helping me solve the problem in front of me in a two-dimensional fashion without realising that actually the problem is not mine solve, but the students and purpose is to help them solve it.

Yet, some educators just aren't confident in their knowledge, or just like being the center of attention and so rely on control to manage the learning environment

Takeaways

If you can: strive for the idealistic scenario where the only imbalance between you and the other people in the room is the knowledge and experience you have, and actively hand over control in all other areas.

See what happens 🤓

Part 2

Updated on Nov 4th 2019

As of Nov this year, it's been 27 months since I ran my first cohort of learners at Makers.

For those interested in self-management, open feedback, flat hierarchies - all that buzzy hipster workstuff, here's my reflection transitioning to managing the coaching team at the Academy (from July 2018 - July 2019).

All the juicy details about my achievements are there. Here's the tl;dr

  • I've seen over 600 students matriculate at Makers

  • I've seen and driven a lot of significant change to the way both our beginner devs and our coaching team think about learning at the Academy.

  • I managed the coaching team at the Academy throughout a critical stage in these changes, absorbing and growing from a lot of new information - I'm a much better manager now than I was, but it's (almost) impossible not to be: first-time managers are irreparably hindered by their lack of experience. Have to start somewhere though.

  • Once the steam was stable, and self-sufficient (as any decent manager should aim for) I went on a 7 week holiday, hiking my way around the Mont Blanc massif with my tent. Take care of yourself - burnout happens easily.

My coaching toolkit

Reflecting on the past couple of years, I feel like my toolkit is like one of those expanding tool chests that I lug around waiting patiently to retrieve the specific tool for the job. To continue the metaphor, when I started all I had to hand was a hammer.

And a spanner I kept throwing around the place.. I had to rapidly add tools, and drawers for those tools, which I guess is a description of experience in a nutshell.

The things I've become better at while coaching at Makers

  • rapid assessment of a group of learners

  • differentiation when coaching: responding to any kind of learner or set of learners

  • identifying success metrics for my coaching

  • designing experiments to produce better outcomes

  • coaching other coaches

  • The ratio of emotional investment has swung back to a healthy distance (I started off being very invested)- I'm more effective as a coach as a result.

Things I'm not good at still

  • administrative tasks I don't have control over to innovate on

  • Sharing information about the work I do

The context is different though. I'm working with a cohort on the Apprenticeships course.

What's different?

Learners are employees

There are mechanisms for struggling learners to transfer to another cohort, or to off-board altogether. These mechanisms don't exist at the Apprenticeships or are much much more complicated. As a coach this is difficult for this course - in the rare case someone falls far behind/disengages it impacts the group of learners and it's not easy to resolve it.

One student in the cohort was absent for a significant number of days during the first 6 weeks and it took a few weeks for the triangle of employer, Makers and learner to resolve the situation. I quarantined the learner from the cohort and helped them set up an individual learning plan. Luckily, the employer had another set of apprentices starting soon after so the learner extended his training time.

Motivation is different - it's much more of a workplace, which has a different set of learners. Recently there was a set of learners who were returning to the workplace after a long absence - which is amazing!

More diverse backgrounds

Backgrounds of the students are different - the ability to offer education for free to learners is incredible. So many more types of learners enriches the learning environment!

Shorter course

The course at Apprenticeships runs at about 50-65% of the hours the Academy course. The objectives have remained the same because of the following:

  • the course was essentially forked from the academy course

  • a committed but inexperienced delivery team (coaches)

  • a short deadline to launch the product

  • and importantly no explicit course designer or product team with apprenticeship experience focuses on the course here.

The delivery team (coaches) have to both deliver and also find time to do this work, a quite impossible task.

No top-level goals.

Goal trees work when the top level goal is clear, everyone's aligned towards it, and the sub goals are equally clear and understandable. The apprenticeships course dropped the main course goals because they reasonably felt redundant against the standard points of the L4SE certification.

Whereas the Academy course (which is the basis for the apprenticeships course) is clearly about equipping you with skills and behaviours to get your first job as a software dev the apprenticeships course is not about getting you your first job as a software dev - because apprentices have one, and yet the subgoals are all still based on the top level goal.

This means the Apprenticeships course is stuck in a set of legacy choices with no vision and no designer. The high level goal remains a L4 software engineering certification that is by default achieved with the academy course retro-fitted as an apprenticeships course that the delivery team has to constantly address this tension to ensure some level of successful delivery.

As a result the definition of success for coaches has changed and therefore become even harder to grasp. I have an innate understanding of the top-level goal and responsibilities at the Academy, forged my own success criteria and then helped others forge theirs, yet with the absence of what the apprenticeships course itself intends to deliver, it's been much harder than I thought here.

The learners on the apprenticeships course seem to rely on the curriculum far more as a result, and also far think their goal is to learn how to code, rather than learning how to be a software developer. Goal trees help those using them to know why any one thing they're doing aligns to the end goal, but I think I'm beating a dead horse here...

Learnings

  1. Drive towards increasing diverse student backgrounds.
  2. Do better setting culture and expectations
  3. Hire or explicitly nominate both a product manager and designer, especially when launching new products/services (seems a tad obvious, but relies on organisational structure)
  4. Spend time clarifying and aligning at the top of the goal tree, not further down.

Next steps

As I transition to a role for the next step in my career, I'm spending time at work coaching. I assumed I would, but the reality of enjoying it so much triggered a bunch of introspection. Not everything is rosy, but I'm getting a lot of reward from the interactions I'm having with the learners.

I've missed it. I really enjoy reducing complexity just enough to allow learners to continue the reduction in order to mentally create a foundation they then can leverage. Every successful interaction like this offers a glut of endorphins, and I love solving puzzles.

I want to continue to find ways to help others get better; work with learners (maybe fewer) and coaches, sideways and upwards management and have more conversations. Always, always more conversations.

-----