Applying Software Engineering Concepts in Professional Growth

A client of mine has a Ph.D. in Computer Science and works on a cutting-edge research project for one of the top tech companies. He has been feeling overwhelmed with his task list, which keeps growing daily and has sophisticated interdependencies. I knew one way to reduce his “overwhelmed” 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 eventually shifted to a more focused state as he started talking about whether it should be a tree or something else. Finally, he said it was a graph, a Directed Acyclic Graph (DAG)! I didn’t have to know it, but that process helped him better understand his challenges.  

Before coming to coaching, I was a software professional and 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. 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 humans are complex systems, we require a conscious effort to understand our operating systems. Unfortunately, we often are focused on the outside demand, and we ignore notice how it affects us. Building self-awareness and knowing what makes things meaningful and gives us an 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, it usually gets very little time for actual processing work. As a result, the overall productivity (throughput) becomes very low. 

As I wrote here, the same thing happens in our brains when we have too many tasks in our minds. Any 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, 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 tasks need your PFC, you are context-switching between the two studies. The more you do the context switching, the more PFC gets 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. 

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 matter. 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. Unfortunately, the feedback often doesn’t resonate with the receiver because they don’t have enough context. If they don’t understand what the input means, 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 due to 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 embraces ambiguity as part of the process. The teams get more clarity by creating the initial sprints based on what they know and then make progress iteratively toward 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 plan, 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 didn’t have the luxury of time to do a full exploration. He was stuck.

I then noticed 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 he needed to solve this career design problem iteratively, one sprint at a time. I wrote more on this here.

I am sure coaches from other disciplines would find similar analogies they use in coaching. I can’t find a better way to apply 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!

---

Feature Image by Christopher Kuszajewski from Pixabay
This article was originally published on July 27, 2020