Who’d want to be a coach?
About a year ago, Redgate introduced a new role to support our development teams: Coaches.
The idea’s simple. Our development teams are made up of software engineers and UX designers, who make great products. They can do that on their own, but many people are used to agile experts (like scrum masters or project managers) and quality experts (like testers) to do some of the work. Rather than have specialists do that work, we have coaches to help teams develop skills to do it themselves.
People reacted to the idea differently. “That will never work!” was heard more than once. I also heard “Who’d want to do that?” a few times, but that question I had an answer to.
I’d want to do that.
Before becoming a coach I’d worked in the software industry for over a decade. In that time I’d been a coder, tester, automator, manager, scrum master, agile transition-er, and who knows what else besides.
What drove me to do all those different things? I like to make things better. To leave places better than I found them.
Coaching: Year One
My first year as a quality coach has been a learning experience.
Most of the people I’d spoken to about coaching work as contractors or consultants. A company finds a need for them and brings them in as required – maybe for a specific project or a health check.
When I started as a coach, I hoped teams would regularly come to me with similar requests. That’s rarely been the case so far – asking a coach for help seems to be a last resort, rather than plan A.
If a request does come in, I do all I can to jump on it. There’s no better marketing for my services than happy customers! But I often need to be a bit more proactive in finding work, so people get a better idea of what I can offer them.
Sometimes that means creating an opportunity to work with a team. Looking at what’s going on in the business, at what work is coming up, can reveal interesting opportunities. People are generally happy with an offer to work with them on de-risking a new feature. That gives me the chance to introduce some new ideas to the team, or encourage some more quality-centric engineering practices.
I also look at factors outside of teams that can make a difference. The working environment is a huge influence on how people work, and environmental changes can have huge impacts on multiple teams at once.
Improving the visibility of our CI build and test results, for example, led to people reacting quicker to failing builds. Even better, it gave me a chance to work with teams to make their builds more stable, letting them focus on building great features instead of babysitting the build server.
What comes next?
I do need to make one thing clear. This job is hard.
I’m working with highly-skilled, problem-solving individuals. Who am I to come into their teams and change how they work? I don’t get explicit push-back, but it’s not easy to influence people unless they want to be influenced.
What can coaches do anyway?
Perhaps the biggest barrier is that teams often don’t know what other coaches can do for them. These are teams of skilled engineers who pride themselves on solving their own problems. That means that requests for a coach to get involved often come too late, if at all.
We want to support teams in solving their problems, not swoop in at the last minute with a pre-made solution. Getting involved earlier helps to come up with better, more interesting solutions for the teams.
Being proactive in finding work has only taken our reputation so far. Really we want one or two big wins to really show off how a coach can help a team to level up how they work, but they have been hard to come by so far.
Quality is about more than testing
Most software engineers are used to having testers or QA to influence the product of their work – maybe through collaboration, but most often through after-the-fact QA practice. That’s built an idea that quality is all about testing, which is something you do after writing the code.
That’s a big challenge for quality coaches. There are plenty of clever soundbites about how you ‘can’t test quality in’, about how bugs found later are more expensive, and so on. Our mission is to instil the kind of quality practice that allows us to develop high quality software, at pace.
That means understanding the needs of users, delivering small changes frequently and learning from them, using the right tools to learn about your code as you write it. Being driven by results, not just shipping code.
After a year, that message is only starting to hit home with some of our teams.
Making that kind of change can be really hard. There are so many things we can make better, and never enough time. People sometimes call that a ‘challenge’.
Do I regret taking this challenge on? Not one bit.
You may also like
Blog