Last week, I talked to a client who has a Ph.D. in Computer Science and works on a cutting-edge research project for one of the topmost tech companies. He has been feeling overwhelmed with his task list that keeps growing every day and has sophisticated interdependencies. I knew that one way to reduce his “overwhelm” state was to bring him to his strengths. I asked him to describe the tasks as a data structure (software developers store data in different data structures). It made him pause and think. I noticed his energy shifted eventually to a more focused state as he started talking about whether it should be a tree or something else etc. Finally, he said it was a graph, a Directed Acyclic Graph (DAG)! I didn’t have to know it, but that process helped him get a better sense of his challenges.
Before coming to coaching, I was a software professional, and I studied computer science in college. A common perception is, coaching is the opposite of software engineering. But in this past decade, I noticed many more similarities than differences between these two. I found several such parallels while coaching those from the tech field. Here are a few examples.
Operating System Applies to Self Awareness.
We all know how complicated these new smart devices are. Average users hardly use all the features. Likewise, as human beings are complex systems, we require a conscious effort to understand our own operating systems. We often are focused on the outside demand, and we ignore to notice how it affects us. Building self-awareness, knowing what makes things meaningful and gives us inner boost VS what depletes our energy is the first step in the coaching process.
CPU Multi-Tasking, Context Switching Applies to Stress and Productivity.
Remember “CPU thrashing”? When the CPU is context switching most of the time, it gets very little time for actual processing work. As a result, the overall productivity (throughput) becomes very low.
As I wrote here, when we have too many tasks in our minds, the same thing happens in our brains. Any piece of job that requires even a little bit of analysis or decision making is processed inside the pre-frontal cortex (PFC), the CPU of our brain. The PFC is a tiny and very much energy-hungry part that sits right behind our forehead. Between any two tasks, if one of them is very rudimentary (something like driving your car in a familiar street), you can do some other job simultaneously like talking or listening to the radio. But when both the tasks need your PFC, you are context switching between the two tasks. The more you do the context switching, the PFC gets more tired. Ultimately its performance starts decreasing, the work quality hampers, and you feel exhausted.
It explains why we often feel overwhelmed and don’t get things done despite being busy all day long.
Bug (software defects) Fix, Root Cause Analysis Applies to Feedback and Growth.
As developers, when a bug report comes, we sometimes push back, saying it is not a real issue. And when that doesn’t work, we investigate the issue. For example, we want to know the expected VS, the actual behavior, the user context (in what condition it is happening), etc., to recreate the issue and then explore the root cause of the problem before we fix it.
In coaching, clients often bring developmental feedback (“bug report”) they receive at their workplace. The feedback often doesn’t resonate with the receiver because they don’t have enough context. If they don’t understand what the feedback means to them, they don’t accept it and become defensive (like a developer pushing back on a bug). A coach can help make sense of the feedback (the context of the bug report) and then explore the “root cause,” and eventually invent a “proper fix” for the issue. This way, the change is more meaningful and sustainable for the client. In software analogy, the code becomes more robust as a result of the bug fix. I wrote more about a client here.
Agile/Iterative Process Applies to Professional Development Goals.
In the last few decades, the software industries adopted the agile or iterative process to build a new product. It has gained popularity because it inherently embraces ambiguity as part of the process. The teams get more clarity by building the initial sprints based on what they know and then make progress iteratively towards figuring out the unknown.
In our personal and professional goals, we often are stuck because of the unknowns. Since we don’t know the entire goal, we are afraid to take any step, and it becomes a deadlock (another term used in the operating system theories). Recently I was in a coaching session with Peter, a senior tech executive, who was thinking of a career transition. His goal was to design his post-corporate career. But he was getting frustrated that he didn’t know what it would be, and he didn’t have the luxury of time to do a full exploration. He was stuck.
I then brought to his attention that he has been using an agile/iterative process to address the inherent ambiguity while designing a new product in his work. It opened up a new avenue for him; he realized that he needed to solve this career design problem iteratively, one sprint at a time. I wrote more on this here.
I am sure coaches who come from other disciplines would find similar analogies they use in coaching. I can’t find a better way to apply the software engineering principles for my hi-tech, analytical-minded clients to help them make meaningful progress. I sometimes think that training as a software engineer made me a better coach.
Innovation is often about applying well-established principles from one domain to another. It is very rewarding to see the quality shift my clients make by applying these engineering concepts in their lives in a whole new way!
Join me for this FREE bi-monthly event Q&A with Sharmin, a safe, confidential space to explore your career and leadership challenges. The next one is Friday, July 9, on Zoom at noon PST/3 PM EST. Only 10 spots per session.
Feature Image by Christopher Kuszajewski from Pixabay This article was originally published on July 27, 2020