How this software engineer got involved with ontological coaching
I guess you could say it’s like debugging, but for people.
This essay is a reflection piece and contains only my opinions. I’m not speaking on behalf of the organisations I learnt this from or the companies I work(ed) for or anyone else associated with me ✌🏼
It was 2018 when I had my first brush with coaching and its associates. I didn’t know it as “coaching” back then when I unwittingly signed up for the workshop that introduced me to these concepts. The offer of the workshop was also its title and it was to “facilitate powerful conversations”, which seemed to address struggles I was facing when it came to my work in technology creation. This was namely aligning business stakeholders with the tech team, and facilitating growth in an engineering team (hi if y’all are reading this!).
Some people I know call the workshop a cult and in some ways I guess the transformation it can facilitate in people who were seeking it could be seen as such. But that’s not the point. I was cynical at the beginning and saw skills such as “use of self”, “active listening”, and “powerful questioning” as tools people could use to manipulate others. I wasn’t exactly wrong, but in retrospect, I did miss the point.
Three years on and a full-blown certified coach programme later, I think of these as essential skills in life as long as you’re not a hermit. I also know these set of skills by a different name these days: ontological coaching, with the focus shifting from them being tools to them being awarenesses.
There are many different types of coaching available. The most common ones you’ll find are sports, executive, performance, health, life, and personal transformation. I would argue that ontological coaching is a horizontal skill that can apply across all of them but my experience with it so far has been that it’s more easily applied in life coaching and coaching for personal transformation.
In the coaching discipline, there is a saying to “coach the person, not the problem”. In a nutshell, this is the core focus of ontoglocial coaching. It is a sub-discipline of coaching that laser-focuses on the being of the person. In the coach programme that I attended, the being is understood through archetypes, each with their associated dispositions and available range of body language, emotions, and verbal language (aka the BEL model).
To me, the difference between coaching the problem and coaching the person is the same difference between giving someone a fish and teaching them how to fish. I think you’d agree that teaching a hungry person to fish reaps longer-term benefits than giving them a fish. Which is also why I subscribe to this path of ontological coaching.
The primary aim of ontological coaching as I understand it currently is an exploration of issues a person brings with the aim of helping someone see who they are being in the situation of interest. It is then up to the person to decide for themselves how they would like to change given this new awareness. The coach and coached then partner to design practices that support doing what the person being coached would like to.
What draws me to this ideology is that it enables choice. Choice was never something I gave much thought to and the turning point was an exercise I went through that required a room of about 30 people to self-organise into four groups where everyone would be happy they were in the same group. The catch? It was to be done without saying a word.
“I want; we need” — Tong Yee
Those words came in before every attempt at self-organisation, and every time, we failed. Without going into the details of what happened, the takeaway which I hold strongly to this day is: when one is deprived of choice, all are deprived of choice.
So how does coaching and choice tie up? To me, coaching enables choice. One quote that has stuck with me throughout my coach programme is:
“Between stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.” — Viktor E. Frankl
In coaching conversations I have with others, one question that keeps coming up for me after each meeting is “how have I played a part in helping the person in front of me to choose their response?”.
By definition of someone being coached — the client is naturally creative and resourceful and knows how to solve their own problems (paraphrased) — I know they could’ve done it without me, but my hope is always that the conversation with me has accelerated that process of being able to choose their response, by being able to recognise the relevant stimulus and what options they have. Responding and reacting are not the same thing.
So how does all of this tie back to my main mission in software engineering?
When I started doing software engineering work professionally, there were technical challenges. Finding out how best to integrate different systems, how to structure code for ease of work, how to provision infrastructure on AWS, how to automate processes et cetera. No doubt they were complex, but acquiring the know-how was made relatively painless thanks to Google and StackOverflow and friends.
(This sounds like a flex but it’s for a purpose and it’ll go somewhere after this I promise). When I first started writing software at about 10, I did C++ (only one of around three widely documented languages that was available at NLB) and every error possibly meant an hour looking at the relevant reference manual for the standard library. On top of that, standard library implementation at the time was not standard. If the manual was written for Borland, it wouldn’t necessarily work for the Microsoft Visual suite. Although I enjoyed it, it was definitely frustrating as hell.
Coming back to today, Google returns me answers to almost any question I have as long as I know the right words to say to it. And I’m sure it does the same for you too.
With that in mind, here’s an invitation for you to take a step back to look at the bigger picture and what has really changed. In the past, gaining knowledge and hard skills was difficult (eg. hours on a standard library reference manual that wasn’t standard). Today, it’s a Google search away. Fun fact: google is also an OED-recognised verb. This also means that hard technical skills can now be considered commonplace and easily acquired as long as someone has the will to.
Consider also the speed at which technology is advancing and invading our everyday (distributed ledger wallets anyone?). I trust technology because I was lucky enough to be born and have grown up in a time without and with technology respectively. I grew up alongside it. The same can’t be said of the current generation of people running the world who were born and raised without technology and now find themselves in a world where it’s use technology or die. It can almost be expected that there will be some resistance to change. It’s only human to have a fear of the unknown.
A nice quote that comes to mind is:
“Change moves at the speed of trust” — Stephen Covey
With technology – mostly the internet – the world is changing faster than it ever has. In some circles you’d also hear the term VUCA being used — Volatile, Uncertain, Complex, and Ambiguous — to describe the world.
In the world of technology creation, managing this VUCA-ness has come down to a few buzzwords that I’m sure you’d have heard by now, occasionally with a sarcastic undertone: Agile and digital transformation (and smart nation too if you’re in the public sector). I believe that behind every joke lies a truth, as much as behind every buzzword lies a legitimate need that’s been trivialised. In this case, I think these buzzwords come from a need to respond to external changes and drive internal change.
“People are not afraid of change, people are addicted to safety.” – Tong Yee/Shiao Yin/someone at The Thought Collective
I was once told, “people are not afraid of change, people are addicted to safety”. And who better to create this safety than the people who create the technology themselves?
In my opinion, the responsibility of creating this safety necessarily lies with the ones who have been to/are in this particular promised land— designers and engineers. Especially so since we’re also the ones responsible for this shift that tends to leave people behind. You probably already know this phenomenon as the digital divide.
There are two ways we could see things. The first is “it’s their fault for not keeping up”, but consider that from their point of view it could also be an unspoken plea of “why are they leaving us behind?”. Going back to an earlier point I made on choice, when one is deprived of choice, all are deprived of choice. When even one person who’s affected does not feel safe to take the leap, the entire community/team will either not move forward or move forward with repercussions that will threaten the integrity of the move.
In the context of technology creation, my opinion (and also call to action) is: technical people need to begin communicating better. Not just to business stakeholders, but to the communities we belong to. I loved software engineering admittedly because I could get away from people and write code in my nice comfortable dark corner. But as I gained more experience in the field, my realisation is that advancing the use/creation of technology is a technical challenge only up to a certain point. Beyond that it becomes a people one.
And I guess that is how coaching ties back to my main mission of software engineering. I want to stay at the forefront of technology and I want to raise the level of engineering excellence in my community. But for all of that to happen, I have to first address who the technology serves: people.
I had a conversation some time back with a peer on the topic of coaching and what attracted us to it. What came up was a distinction between ‘a coach’s practice’ and ‘a coach’s job’. The former refers to the values and practices a coach holds and does to become an instrument of coaching; the latter refers to the act of coaching another person.
My attraction to the values and practices of a coach was admittedly what got me into coaching. Seeing the outcomes of how both applying and spreading the awareness gained from the practice of coaching can enable people? I guess that’s what really keeps me going in my coaching journey while being a software engineer.
This essay is really more of a self-reflection after wondering how the hell I even embarked on this journey given my strongly-held identity of a technically proficient person (think introverted, highly skilled, elite yadayada). Regardless, if you’ve reached this point, I hope you enjoyed reading this and that it provided you with some useful life insights!
Also, I’ve decided to go for ICF certification as a personal goal and need 100 or so hours of coaching conversations. So if you’ve ever wanted to try/would like to try getting ontologically coached for anything at all, drop me a message on LinkedIn or schedule an introduction call with me on Calendly. My target audience is people in technology organisations/product teams, but as long as you’re not a hermit, I think I might be of some value to you.
Lastly, big big big shoutout to the two organisations from which I’ve learnt most of what I have: The Thought Collective and The Coach Partnership. And also shoutout to the MyCareersFuture team for putting up with my “raising awareness” shenanigans while I practiced as a noob + my awesome ex-manager Steven Koh who was fully supportive of my endeavours outside of technical skills and who shares my beliefs on technical people needing to step up in technology organisations.
🥂
