Everyone Needs A Coach. Every Delivery Team Needs A Technical Coach

Bill Gates chose to open his 2013 TED talk with the words "Everyone needs a coach". Someone to provide feedback, and help them see how others see them. True enough - I have helped many people over the years understand themselves, how they interact with others, and how they can resolve inner conflicts and improve. For me, being an effective personal coach is one part of providing quality leadership to companies, and was one reason I went on the Barefoot coaching course a while back.

But let's zoom out, and look at the next level in the software industry, specifically the delivery teams. These folks should be the powerhouse of any company, turning customer needs and ideas into reality that can be assessed for usefulness, and ultimately value (whatever that is - value can take many forms. Maybe a subject to explore another day). 

However, in companies I work with I am seeing a problem with many of these powerhouses. Something that I suspect is rapidly becoming a BIG problem throughout our industry. As someone who has been actively (and successfully) developing high quality software since the last century(!) I feel eminently qualified to say this, plus I am not the first to raise the alarm. The delivery engine is misfiring. So what is going on?

Looking back to 2001 the Agile Manifesto triggered renewed widespread interest in iterative, incremental development - arguably encouraging the software industry to relearn the techniques that were used before: remember, techniques such as Spiral and RAD were in use long before Snowbird (trust me, I know! I was there). The rest is, as they say, history. Iterative frameworks became big business, what with training and certifications. However, the trouble with "big business" has always been that it is driven by business and marketing types rather than engineers. Most engineers have little interest in how to build market share, and are generally happy to lose themselves in the technical weeds as long as the paycheque keeps landing in their bank account, and they are not asked to do anything too stupid. So the technical ability needed has rarely been emphasised - a case in point, how many folks have heard of the "Certified Scrum Developer" qualification? Very few as far as I can work out. Developers are more likely to have heard of, and maybe tried, snippets of techniques and disciplines for example Test Driven Development, Behaviour Driven Development, Clean Code and so on, but have rarely been taught them by people who know what they are, and how they interrelate in real projects. 

Just a few of the skills needed for effective iterative delivery

Then there is the learning curve; these techniques take time to learn and will slow you down at first, but this learning is poorly supported by non-technical people such as project managers who see it as simply slowing down the day to day delivery. It is not their fault - I doubt they fully understand that these skills are fundamental to what is needed to deliver on the promises of "agile software delivery". Unfortunately the result is huge pressure to cut corners, and fudge around the misunderstandings and difficulties rather than doubling down and learning or fixing the issues. More work, fewer results.

All this is fine, after all we have been bludgeoning software into delivery for decades. Right?

Wrong.

Iterative approaches to delivery without the technical skills to do so leads to Bad Code & Technical Debt.

And when Bad Code & Tech Debt takes over, planning becomes much more erratic and unpredictable - which creates more pressure to deliver, which creates more Bad Code, and so the death spiral continues (again, a subject for another day). 

As I mentioned, I am not alone raising the alarm here:

“There must be five million makers working under the thumb of Scrum, and most of them simply do not have the skills you need to work effectively in Scrum.” - Ron Jeffries

The net effect is that instead of being able to comfortably deliver live code multiple times per day, releases happen infrequently, are stressful, and the team becomes massively overloaded, working late nights and weekends. In the field I am seeing teams trying to maintain utilisation factors of 130% and above for months on end, which is inhumane when there are tools and ways of working that are much smarter. Both the human and business cost is enormous.

Coming back to coaching, this is the reason EVERY DELIVERY TEAM NEEDS A TECHNICAL COACH! The whole point of this article. The Technical Coach is someone to help teams improve. A person trusted to guide teams through new techniques and approaches, helping to fully appreciate the underlying principles. The Technical Coach is skilled in bringing agile technical practices together to enable stress-free, more predictable delivery without needing to burn out the team. The Tech Coach helps the team improve, hears the team's feedback and ensures their concerns are heard in the delivery chain. 

Emily Bache puts it like this:

“Technical coaches help software developers to adopt better coding practices. The focus is on the code and the way it is being written. A technical coach will themselves be a competent software developer able to mentor and teach specific coding practices. For example Test-Driven Development, Refactoring and the use of Design Patterns.”

So hire a Technical Coach today, before your competitor does and gains an advantage. 

At the time of writing (July 2023) I am available. Give me a call to discuss possibilities.