What skills does a technical coach need?
One of the goals of my present coaching engagement is sustainability, defined as the ability to continue with the improvements after the coaches are gone. To that end, we’ve been identifying internal people who have the potential to become effective technical coaches. One manager asked us for a short list of key skills that a technical coach ought to have. Answering that question has been quite a challenge. It occurs to me that other people may be asking the same question, so it might be useful to discuss it publicly.
Initially, the manager asked the question casually and I answered it lightly. As I walked into a room where the conversation was already underway, he asked, “Off the top of your head, what are three things a technical coach needs to know?” Having no context, I shrugged and said, “First, technical shit. Second, coaching shit. Third, what’s for lunch?” Everyone laughed. But he still wanted an answer. His hope is that it will be possible to jump-start several internal technical coaches by the beginning of summer.
The technical coaches on the engagement have been discussing it off and on for a week. If I have to come up with a list of three things a technical coach needs to know, I suppose it would be this:
- The willingness to spend time helping others
- The ability to respond credibly to team concerns
- Basic skills in communication and coaching techniques
1. The willingness to spend time helping others
When client personnel talk to me about the possibility of becoming a technical coach, a recurring theme is that people worry about losing their “edge.” If they have to spend time preparing and facilitating workshops, code dojos, and training classes, then they won’t be able to keep their hands on technology as much as they would prefer.
People see the way the non-technical coaches operate. They lead workshops, they conduct one-on-one coaching sessions, they devise and facilitate educational games, they meet with management and describe the value proposition of organizational change. They talk a lot, but they never build any software. Their concept of “technical coach” is a person who does largely the same things as the other coaches, except that they talk about technical practices instead of process improvements. Technical people are not interested in doing that for a living. They got into technology because they like technology.
Actually, a technical coach operates a bit differently. While we do the things that non-technical coaches do, we spend more of our time working directly with technical teams. We pair with individual team members on their actual work. We demonstrate techniques and tools that we have found useful. We show them how to overcome practical challenges, such as applying refactoring and automated testing to monolithic legacy code bases.
If a technical person is willing to do those things, then he/she can be an effective technical coach or mentor without moving away from hands-on work. You can stay sharp and still function as a technical coach. In fact, you have to stay sharp, or you will lose credibility with the people you’re trying to help.
2. The ability to respond credibly to team concerns
In a large organization, nearly every team you encounter is operating under a unique set of conditions. Languages. Technologies. Access rights. Organizational structure. Process constraints. Governance. Compliance. Performance management. What works in one situation will not work in another. They can’t “fix” the organization to grant themselves access to every system and every tool they need, and to enable themselves to step on someone else’s “territory” to get things done. They have to work within existing limitations. You might describe technical practices that are generally considered “good,” and the team will reply, “But what about [unique thing]?”
A coach’s job is to help others discover their own strengths, and to show them how to find their own path forward. To do that, the coach must have credibility. The team members must think that the coach has something of value to offer. Platitudes and buzzwords don’t establish credibility. When they ask, “But what about [unique thing]?” your answer can’t be a glib “Go forth and self-organize! The answer is within you!”
The coach doesn’t need to have all the answers. No individual has direct personal experience with every unique situation, every set of technologies, and every imaginable organizational constraint. It isn’t realistic to expect the coach to have overcome every challenge that each team presents, and to offer a step-by-step solution. But the coach can respond credibly to the team’s concerns. He/she can relate the team’s current needs to one or more past experiences, even if those experiences don’t precisely match the immediate situation. He/she can help the team understand how to adapt their chosen model (“agile” or “lean” or whatever) to the current reality.
So, what’s the particular “skill” involved here? It’s hard to quantify. It isn’t so much a discrete “skill” that you can learn in your spare time by the beginning of summer. It’s more a question of having sufficient experience in different situations and with different technologies and business domains that you can relate to the problems the team is facing.
And now for the hard part: If you’re working with large organizations that have significant legacy systems, it’s almost mandatory that the experience include technologies that are no longer considered “sexy.” Otherwise, you may not understand exactly why a team can’t (or believe they can’t) apply the good practices you’re recommending. Tools for contemporary development methods are lacking on large legacy platforms (i.e., mainframe), and you might have to lay hands on the system and roll your own tools. You may have to show them that it is possible to deliver a piece of working software in less than a month’s time, and if you use Ruby or Python for your example they won’t relate to it. With the current emphasis on “scaling” lightweight processes to work in larger enterprises, this sort of experience is becoming a baseline requirement for effective technical coaching in these organizations.
I don’t mean to imply that an effective technical coach in a large organization has to be a mainframe specialist. The reality is far more challenging than just that. Applications in that sort of organization often span multiple platforms and employ disparate technologies. A “feature team” might support application components on multiple platforms (iOS, Android, Linux, Windows, AIX, zOS), multiple frameworks and server products (Rails, JSF, WebSphere, Tivoli, Siebel, Blaze), multiple data stores (MongoDB, MySQL, Oracle, DB2, VSAM), multiple programming languages and shell languages (JavaScript, Ruby, Java, C, COBOL, Assembly, Rexx, Bash, Windows batch), and multiple delivery pipeline tools (Git, Subversion, ChangeMan, Jenkins, UDeploy). No one is an expert in all those things, but a technical coach must be able to respond credibly to team concerns across most of the technologies the team uses.
Of course, not all organizations have such a broad range of technologies in place. One of the “most agile” companies I’ve worked with used just two technologies for their software products: JavaScript and Java. It would certainly be possible to function effectively as a technical coach in that environment without having previous experience in 15 or 20 other technologies. It’s likely, however, that a person who could add value in that environment would be at a loss in a larger company that used several different legacy technologies, like one of the large banks or insurance firms. Not every technical coach can function in every environment.
3. Basic skills in communication and coaching techniques
Some technical professionals are great at working with technology, and not so great at communicating effectively with humans. This isn’t the cliché it was, say, 25 or 30 years ago, but in the role of technical coach one needs to have stronger than average communication skills. Fortunately, there are plenty of resources available to help a prospective coach improve his/her skills in these areas. Look for seminars, workshops, classes, and conference sessions that deal with communication skills and coaching as a discipline.
A good deal of coaching work involves listening rather than talking. How you listen and how you ask clarifying questions can make a huge difference in the effectiveness of your work. This topic has too much substance to cover in a blog post. Just be aware that these are important areas in which to develop your skills, if you’re interested in a technical coaching role.
Communication models you might find useful include (not an exhaustive list):
- Active Listening
- Appreciative Inquiry
- Powerful Questions
- Non-Violent Communication
It’s useful to understand a bit about psychology and cognitive bias. Patience also comes in handy on occasion.
“Coaching” as such is a discipline in its own right. There are institutions, training courses, conferences, books…the whole nine yards. There are several aspects to professional coaching. You sometimes act as a teacher, sometimes as a mentor, sometimes as a life coach. Sometimes you lead, sometimes you guide, sometimes you let go. There’s a fair amount of observation and on-the-spot judgment involved. There are different models of how coaching happens, and different schools of thought about how to do it. I’d suggest you start searching online with the word “coaching,” see what other words tend to come up in that context, and refine your search to discover resources you can use to start developing these skills. Just don’t expect to be an expert by the beginning of summer.
Apart from the sheer volume of information to learn, this aspect of coaching involves the so-called “soft skills” that many technical professionals prefer to avoid. Be realistic about your comfort level with these things. “Technical Coach” isn’t just another name for “Senior Developer.”