How the Samman Method helps to sell technical coaching internally?
Emily Bache wrote an accessible guide for technical agile coaches. Here is my review, plus my bonus section: How to sell your technical coaching services internally.
[…] Often they have a lot of internal knowledge and are more valuable to the organization in their current role than they would be as a more general technical coach. [Emily Bache]
Emily Bache has a great reputation that helps her a lot to find organizations and teams to work with. It is different for us: anonymous and without reputation. [A reviewer on Okiwi]
I no longer focus on the practices when I spread them; I just start using them when I pair with someone, and they catch on (or don’t). Maybe I should have specific sessions where I focus on, say, refactoring, or TDD. [George Paci extremeprogramming@groups.io]
A while ago, Christophe Cadilhac created a channel for technical coaches on the french Okiwi Slack. Our kick-off action was to start a book club. As a first book, we picked Emily Bache’s Technical Agile Coaching with the Samman Method. We met every Monday, Wednesday, and Friday. It took us around 3 weeks to finish the book.
Emily Bache had the freelance coaches in mind when she wrote it. I found most of the text useful for both external and internal coaches… except the Sales aspect. Yet another reason for me to write about the book. This blog post consists of 2 parts:
- A review of Emily Bache’s book
- Advice about how to sell your technical coaching services when you are an internal coach
You don’t need to read the first part to understand the second. You can jump directly to how to The Unique Sales Challenge of Internal Coaches if you prefer.
What is the book about?
NOTE: Emily’s book was only 90% finalized at the time of this review. Content may have changed a little when you read this.
The book presents how Emily Bache now does technical agile coaching. She calls this way of coaching the ‘Samman method.’ It relies on mob programming and regular mini-trainings, which she calls learning hours.
Why Samman?
Google told me that Samman means ‘Together’ in Swedish. Although British born, Emily Bache lives and works in Sweden. Her coaching style relies a lot on mob programming, which I guess is why she picked the ‘Samman’ word.
Book structure
After 2 short introduction chapters, the book consists of 3 parts:
- Ensemble Working. This part contains a crash-course on mob programming and some advice about how a coach should act in the mob.
- Learning Hours. On top of mob sessions, Emily uses short 1-hour training sessions with the coachees. The goal is to have them practice the theory they will need to be effective in the mob.
- Samman coaching engagement. This last part details how to organize as a coach:
- How to sell?
- How to work with recalcitrant teams?
- How to manage your career?
- …
What I loved about this book
Here are the reasons why I enjoyed reading this book.
It’s an easy read
It’s currently only 122 pages, which makes it a short and easy read. We all suffer from information overload. I’m a strong advocate of short books: many of my favorite software books were short. For books, less is more!
It’s a full-spectrum recipe for technical coaching.
In her book, Emily presents her full-spectrum and coherent recipe to technical coaching. It’s not a disparate set of practices that we could copy from an experienced coach. It’s a system of techniques that support and build on each other. For example:
- Learning hours provide the theory and practice so that mob sessions can be useful.
- In turn, mob sessions will highlight what the team should look into during learning hours.
It’s a crash-course on mob programming.
There are entire books about mob programming. Maybe you don’t have the time to read 200+ pages about mob programming. Emily’s book contains a 10 pages crash-course to get you started with mob programming. It even includes a short section about remote mobbing.
It fills a gap
There are plenty of books about Agile coaching. There are very few books that deal with the technical aspects of coaching. By relying on practices like mobbing, Emily presents a modern way to do technical coaching.
It goes into great details about learning hours.
One of my main takeaways from the book is the extensive description of Learning hours. Emily provides some typical session examples. She also goes through the pedagogic theory behind the practice.
We have been using katas for a similar goal at work. A typical kata lasts for 2 hours, though. We had also been experimenting with ‘mini-katas,’ unfortunately, without much success until now. Learning hours, as described in the book, might be what we have been looking for!
It’s a starter kit
The book also covers some career and business-related topics. It could serve as a guide for someone willing to pick a technical coach career.
Emily writes about what she loves about the technical agile coach job. She also presents her typical coaching day. This short section makes the rest of the book more concrete!
In part 3, she dives into more details:
- How to find a customer
- How to find teams to coach
- How to deal with recalcitrant teams
- How to start and grow as a coach
- …
It contains everything we need to get started!
She uses a very personal style.
The book is not meant to be an absolute reference. It is instead the return on Emily’s experience of doing technical coaching. This is not the only way to do it, but it’s Emily’s way. It works for her and also works for others. My own current way of coaching at Murex is very close to this style.
Presenting her coaching recipe connects with the reader at a more personal level. This made my reading experience more enjoyable.
It’s also useful for experienced coaches.
If you are an experienced technical coach, you might think this book is not for you. You would be wrong! The previous points might look ‘junior coach’ oriented. Here is why the book remains worth your time:
- It will make you think about the way you are currently coaching. You might not jump in Emily’s style right away, but it will shed new light on your current practices. Most likely, you’ll tune or change your coaching for the better.
- She also offers advice about dealing with recalcitrant teams, a difficulty we all face at some point.
- Throughout the book, Emily addresses the personal organization topic in depth. Many of us (me included) still struggle with this, and any help is welcome. For example, she provides advice about when to take breaks and when to have non-coaching days.
My conclusion
My conclusion is straightforward. If you envision becoming or already are a technical coach: give this book a read. Its advice/page ratio makes it a no-brainer.
What you won’t find in this book
Like with any book, Emily had to select what she put in it. Here are two things that are not in the book that are worth mentioning:
No technical knowledge
It does not contain learning material to teach you all the skills you’ll need to become a technical coach. Instead, in part 3, Emily provides a list of all the skills you’ll need to work on. The book also features a terrific shortlist of references to acquire these skills.
No explicit advice for internal technical coaches
Emily explains that she wrote the book with freelance coaches in mind.
Most of the coaches I know are consultants who engage with a number of different organizations […]. I believe it should also be possible to be an internal coach in a large organization. I don’t have experience of that but I hope you will still find useful material in this section. [Emily Bache, Technical Agile Coaching with the Samman method, Part 3]
Indeed there are a lot of internal technical coaches out there. I am one of them, for example. I know even more developers who do unofficial, ‘guerilla-style’ technical coaching.
I find myself continuously reinstalling [XP and Agile] best practices at the jobs I’m taking on. Continuous Integration, unit testing, refactoring, iterative development… [Slava Imeshev extremprogramming@groups.io]
This is where I can be helpful!
What changes for internal coaches?
Part 3 of the book addresses many different aspects of the coaching engagement. Most of these are pretty similar for both internal and external coaches:
- Persuading a team to work with you.
- Setting expectations before you start working with a team.
- Starting a technical coaching career.
- Continuously improve as a coach.
If you are an internal technical coach looking for advice on any of these topics, Emily’s book is for you. There is another aspect that differs a lot, though: Sales!
The Unique Sales Challenge of Internal Coaches
A freelance coach sales challenge is:
How do I find a client to work with?
Sales for freelance coaches is very close to any consultant’s sales. In her book, Emily gives business cases examples to pitch technical coaching:
- The department striving for Technical Excellence
- The company struggling with defects
- The twenty-year-old codebase
- Too stressed out and busy
She also details typical coaching proposals. You might also have a look at the ton of literature to help consultants find clients.
If you are an internal coach, your situation is different. Your sales challenge becomes:
How do I start technical coaching with teams in my organization?
Why bother?
This looks like a difficult thing to do! Why should someone even bother? Again, Emily has the answer in her book! For the same reasons that someone would want to become a technical coach:
- It’s challenging and interesting. […]
- You can have a bigger effect than you would in other roles. […]
- Teaching is inherently rewarding […]
Now that we know why, let’s see what changes!
Different Context
Independent and internal coaches face very different contexts. If you are an internal coach, some aspects will be more tricky:
- You often don’t start with an official technical coach role! This means that you will have to work your way to this new job.
- Independent coaches often negotiate contracts with people high in the hierarchy. This is a fail-fast test that ensures some management support for technical coaching. As an internal coach, that’s a luxury you often don’t have. To make things worse, wannabe internal coaches start from a different job. Which very often makes top managers unreachable!
- You will not be able to ‘chose’ your customer! Except if you decide to jump ship, your unique customer is your employer. This can be a pretty tricky constraint if the company does not yet believe in technical coaching.
- As Emily noted in her book, wannabe technical coaches are often stuck in their roles. Organizations value contributors too much in their roles to let them change jobs.
On the positive side, you also have advantages in your pocket!
- There is already a contract that is binding you with your company. There is no energy to waste on negotiation and bureaucracy.
- If you’ve been there for a while, you already know the context and the challenges better. This should help to fit technical coaching to the current goals of the organization.
- You should know some influential people. These can prove valuable allies to help you to start technical coaching.
- You also know the culture better. You’ll have a gut feeling about what people will like and what they will not.
- Finally, you should know the processes better. This should help you to work around the bureaucracy and get things done.
4 steps to sell your technical agile coaching services internally
In the past 10 years, I’ve been both an external and internal coach. I already had a few coaching missions under my belt when I joined my current employer 7 years ago. I started as a senior developer, and I am now an official internal technical coach. I even managed to grow an internal team of technical coaches.
The 4 steps
My success formula has been to act like an intrapreneur and to accumulate momentum, day after day. I would summarize my approach in 4 steps:
- Find a pain that you believe you could provide some help against
- Hack the organization! This is where your organizational knowledge will help you. You’ll have to be creative to find a way to provide some help. Use your position, your network, the process, or whatever you can think of! A quick chat with the right person at the right moment is often all we need to unlock the situation.
- Coach: at this point, you should have some buy-in for some form of coaching. Now is the time to be helpful. Do your best, be humble, be collaborative, and collect feedback. Don’t forget the coaching mindset! You should not do it yourself, but help others to do it by themselves.
- Accumulate momentum: if you managed to provide some help, then communicate about it! It’s going to help you in the future. If it did not work as expected, then at least you learned something, so try something else!
At that point, repeat the whole thing! Every iteration should get you closer to doing technical coaching on a broader scale.
My story
A few months ago, I wrote a summary of my own journey from senior developer to technical coach at Murex. To illustrate what these steps might look like, let’s put them in parallel with my story.
Iteration 1
I had joined a relatively junior RTDB team as a senior developer.
- Pain: The team struggles with a lot of code, slow tests and is at risk of delivering an ambitious product.
- Hack: My senior developer role has a mentoring aspect. Let’s use it to coach other developers during code reviews and pair sessions. I could also try to introduce effective retrospectives.
- Coach: I start to coach my teammates to TDD, refactoring, and evolutionary design. A few months of this is enough to ignite a continuous improvement mindset in the team. (You can have more details about this in From Zero to Pair Programming Hero
- Momentum: the team is on track to deliver a breakthrough product! Some managers buy-in the agile way of working and are pushing for more.
Iteration 2
An Agile transformation is on its way, for the worse or better… I now had a success story as an embedded coach under my belt! I only had to express my desire to do more coaching to get an official agile (not technical yet) coach role. I am asked for help in the Deadpool team, which is struggling with legacy code.
- Pain: I spend a few days within the team to understand that legacy code is not the only pain. It’s a group of experts more than a team. Expertise silos and legacy-code production-issues make the pace unsustainable. Morale was low.
- Hack: Let’s use my now official ‘agile’ coach role to embed in the team. I could help them to add tests with katas and pair sessions.
- Coach: I try different approaches before we get some results. Pair sessions don’t work as expected, but mobbing with the team on their refactoring does. The team develops a continuous improvement mindset, delivers, and works on T-shaping.
- Momentum: This is a significant milestone for me. I come out of this with
- A coaching plan to tackle legacy code and refactoring
- Credits among other agile coaches
- Credibility from other teams
Iteration 3
My style of agile coaching is now known as Technical Coaching. My new goal is to find more teams to coach.
- Pain: I know many teams suffer from legacy code and refactoring pains. Thanks to the success with the Deadpool team, I now have something to help them!
- Hack: This is the most ‘sales’ intensive work I ever did. I started an open coding dojo. I looked for teams to coach through word of mouth. I used my personal network. Whenever I meet a candidate team, I pitch them what I had done with the Deadpool team. Every time a team said no, my pitch became better. Eventually, I find a team that is ready to go!
- Coach: I work with the team for 3 months, going through TDD katas, refactoring katas. We also mob together on their legacy code. I receive excellent feedback. Again, people love working on their production code with the coach.
- Momentum: Thanks to repeated good feedback, higher-level managers notice my work. They start to see technical coaching as a tool against tricky issues like technical debt. The end-of-coaching survey is also a way to collect the next pains to tackle!
Iteration 4…
The story goes on… We are now scaling the offer, with more technical coaches, more katas, more problems… If you want to read the end of the story, stay tuned!
Takeaways
If you envision becoming or already are a tech agile coach, go and buy Emily’s book! It’s a short and pleasant read. You will most likely discover new practices, or at least see her perspective on them.
She mainly addresses independent coaches in the book. Most of the content is still relevant to internal coaches, though. Whatever your current role as an employee, you can sell technical coaching internally. You have the unfair advantage of already being in the organization! Start iterating through these 4 steps:
- Identify a (technical) pain you could help with
- Use your organizational position and knowledge to find ways to do some coaching
- Coach people to act against the pain
- Assess the results: communicate about successes, review and retry otherwise
Leave a comment