Dosh's Technical Coaching Guide Overview ~|~ Auengun.net

This is an ongoing attempt to organize a lot of the ways I think about coaching into an abstract guide to help other coaches or technical people. The guide is written based on my own experiences, and shared experiences with other coaches/peers/people, through 10+ years of in-the-industry coaching software engineers, technology teams, data scientists, data engineers, math students, or otherwise.

This won't probably ever be complete in the sense that it's finished, and so I don't think I can ever revision or create a release of this information. Nor do I think I could create a book or blog or magazine on some of it either. A wiki or an updated docs page feels the most appropriate for the time being, and thus this page was born.

First an non-exhaustive overview on what I consider to be "Technical Coaching" and what isn't...

I've been given many opportunities over my career to consider my role and what to call it. What recruiters have called it, what peers, managers, and people asking for help might call it ...

Software Engineering Coach
Technical Coach
DevOps Technical Coach
Data Engineering Coach
CI/CD Coach

But the frustrating thing to me about all of those, is that they start with technology, even if the role claims to be about "people, process, tools" in implementation details or messaging from leadership. So, maybe it's better to say that I'm a person who likes to help people first, and then the technology how comes later. Usually after I'm done helping the team self-solve some of their initial people related dysfunctions first.

🧱

Note: setting boundaries is something I've spent a lot of my career failing at doing...but gotten SIGNIFICANTLY better with time and exposure.

You might be a person who is already good at setting boundaries, awesome! You might already have a healthy balance, but the coach in me also wants to tell you to be sure you're not over setting boundaries too 😉

The technology I'm willing to help with is mostly rooted in the domain of Software, Coding, etc., but I'm sure a non-trivial amount of this technical coaching experience could be applied to many knowledge worker industries to with a quite a varying degree of successes!

Coaching is ... a really complicated topic and can be defined many ways. I sort of take inspiration from the model of coaching I found most around me in my career early on, and that tended to be coaches who had an ICF mindset.

Technology coaching might start with a different set of tools in the tool box, and it might take a different path to understanding that other coaching, but it starts through the same fundamental idea. Ethical practices, shared empathy, trust, safety, codevelopment of plans, understanding, and maybe a tacit hope that there might be something to learn from the experience.

Next, a really loose collection of half-finished thoughts that are waiting to be teased out into bigger ideas or more complex statements.

Seriously, this next section is just a mixture of things that aren't probably all that helpful to see in isolation. Each of the topics or pages could be turned into any number of talks or presentations or full-on rants/stories from my past on how things did or didn't work.