I’m finally coaching! Considering I was hired as a consulting coach in January, started with a client in February, and landed with a team in March, that’s an odd thing to say, isn’t it?
What do I mean by “coaching”?
”Coach” (the role) includes teaching, training, mentoring, and any other kind of situationally called-for behavior, but aims to center on coaching. “Coaching” (the activity) means helping people and teams become more themselves. I recently discussed this topic with Zach Bonaker and Ryan Ripley on Agile for Humans 013, and I’ve got a blurb about how I and others see what I do.
Others use the word differently. For instance, some say “coach” to mean “consultant who will tell us what to do.” I don’t want to do that, and I don’t think it has much to do with coaching. To take another example, I often hear a distinction made between “process coach” and “technical coach,” with which I have at least three beeves:
- I’m not coaching processes or techniques. I’m coaching people.
- As a coach, I’m more effective when I consider the whole system.
- In Agile software development, process and technique are intertwined.
Why did it take so long?
I was brought in as a hands-on technical coach, as a deliberately influential member of the team. I liked the sound of that, especially after so much time off. Let’s get paid! Let’s go to offices and work with people! Let’s see if I can earn trust, influence and be influenced, help a few people who wish for better to get it.
It was a slow start, for a variety of reasons: two weeks to get new-hire oriented at my consultancy, more than that to arrive at clarity about which client team to place me with, much more than that to get me a development-capable machine with a development-ready environment. During those months, when the only way to learn the domain and the codebase was to bother someone who was trying to get their work done, I tried pairing a couple times and decided to stop. (I hate wasting anyone’s time.) Until I could acquire the local knowledge on my own, I looked for other ways to start helping the team, such as:
- Hands-on classroom sessions for an hour every afternoon, alternating between exercises to build new code skills (TDD, refactoring) and legacy code skills (characterization tests, refactoring). After a while, not seeing how to apply what they’d learned to their production codebase, the team lost interest and we stopped the sessions.
- Whole-team programming for a full two-week iteration. It wasn’t textbook mob programming, or even close, but it was a start at learning to work together more effectively. They were nearly as productive as they’d been the previous iteration, plus key knowledge spread to many more brains, plus everyone on the team was animated and engaged in the problem-solving. But under perceived pressure to maximize velocity, the team decided they couldn’t afford to continue working in this way.
One obstacle was the sheer size of the team (at its largest, about a dozen). With a team that size, it’s hard enough to have a direction, let alone try to change it. Another obstacle was the frequency with which members joined or departed, constituting a new team.
How can I tell I’m coaching?
I’ve lost trust by trying to help in ways that haven’t helped, earned some back by finding ways that have been desired. I’ve found ways to offer potential value to the team without asking more than they’re willing to offer. I’ve listened, asked questions, and offered suggestions in conversations with and without keyboards, in groups and one-on-one. I’ve identified feedback loops in need of repair — several of which involve me — and have been repairing them.
In short, I’ve tried a bunch of things that didn’t work, and found a few that are (for the moment) working. I’ve danced insensitively, and learned some signals to be more attentive to. I’ve improvised ineffectively, and learned some new moves to try.
I know I’m coaching because, as the team’s needs have not yet been primarily technical, I haven’t been doing much “technical coaching.”
I know I’m coaching because I’m sometimes aware when I’m failing, when I’m succeeding, and when I’ve learned something.
I know I’m coaching because I’m sometimes aware when people want what I’m offering, and when they want me to be offering more.
I know I’m coaching because I’m not even sure “coach” is a thing anymore. Maybe nothing exists but people, the actions we take, the behavior patterns we choose, the capabilities we grow, and the environments we design. Some of what I do each day could be called coaching, some programming, some teaching, some delivering. My job is to catalyze mutually desired improvement, and I’m finally, perhaps, beginning to.
How do I feel?
This work is exactly what I wanted. I’m finally wrestling with all the challenges I hoped and wished this job would consist of. What’s more, I’m being supported in ways I’d learned not to hope or wish for. As a new coach, I’ve leaned heavily on Pillar folks and other coaches at the client, all of whom have lent their expertise and experience to help me when I’ve asked. I’ve been very lucky to have such easy access to terrific consultants, to know I’ve got the backing of program management, and to bring my whole self — because the work needs me.
I would have regretted not doing this. I also would have regretted doing it badly. But I seem to be getting the hang of it.
It’s everything I wanted, and then some.