Systems thinking
What systems thinking taught me about recurring problems.
I used to think that recurring problems needed more effort or a faster solution. Working a graveyard shift and handling repeated client revisions taught me to look beyond the latest incident and ask what kept causing it.
When fixing one incident is not enough
I used to deal with problems one incident at a time. If something went wrong, I corrected it and moved on. It seemed practical until the same problems started returning in slightly different forms.
At first, I blamed bad timing or thought that someone needed to put in more effort. Sometimes that person was me. I responded with another reminder, another schedule, or another quick fix. The immediate problem would disappear, but it rarely stayed gone.
Systems thinking gave me a different way to examine what was happening. Instead of focusing only on the latest incident, I started looking for patterns. I paid attention to the conditions surrounding the problem and asked what kept allowing it to return.
Two experiences made this lesson real for me. One came from working a graveyard shift. The other came from freelance projects that went through revision after revision. In both cases, the real problem was not where I first thought it was.
What my graveyard shift taught me
Early in my BPO career, I worked nights. My schedule ran opposite to most people’s routines. I prepared for work while others prepared to sleep, and I traveled at hours when public transportation became limited and unpredictable.
I treated my exhaustion as a time-management problem. I set more alarms, planned different routes, and left home earlier. These solutions made sense to me at the time. Still, I often reached the second half of my shift feeling tired.
I thought I needed more discipline. What I actually needed was to look at everything connected to the problem.
Limited transportation made my commute longer and less predictable. A longer commute took away time that I could have used to rest. Less rest made the shift harder. The exhaustion then made the next commute feel even worse. I kept adjusting my alarms while the same conditions continued to produce the problem.
The option that finally helped was already available at work. The company had a sleeping lounge, which I had previously treated as a minor employee perk. Using it allowed me to avoid one late-night trip and gave me more time to rest.
I did not need another alarm or a stricter routine. I needed to change one of the conditions that kept making me tired.
What repeated revisions told me
Years later, I encountered a similar pattern in my freelance work. Several projects went through more revisions than I expected. My first explanation was that the clients were indecisive.
It was an easy explanation because it placed the problem outside my control. It also did nothing to prevent the same situation from happening again.
The Iceberg Model helped me separate what I could see from what was happening beneath it. The visible event was another revision request. The pattern was that the same thing happened across different projects and clients. That meant I needed to examine my own process.
I realized that I was beginning projects before discussing the clients’ expectations in enough detail. At times, I also accepted more work than I could support with a careful intake process. The revisions were not appearing out of nowhere. They were pointing to conversations that should have happened before the work began.
Once I recognized the pattern, the next steps became clearer. I slowed down the intake process, asked more specific questions, and confirmed expectations before starting a project.
The number of revisions decreased. It was not because the clients suddenly became easier to work with. I had started making room for the conversations that could catch a mismatch early.
The questions I ask now
These experiences changed how I respond when the same concern appears in course design, client work, or a team process. I still address the immediate issue because people often need a solution now. I simply try not to stop there.
When a problem keeps returning, I ask:
- What keeps repeating across these incidents?
- What usually happens before the problem appears?
- What conditions make this outcome more likely?
- What am I assuming about the people involved?
- Where can I interrupt the pattern instead of fixing another symptom?
Systems thinking does not make every problem easy to solve. It reminds me that what I can see may be only one part of the situation. A missed deadline, another revision, or a tired employee is an event. If the event continues to happen, something around it may be helping it return.
Instead of asking only, “What went wrong this time?” I now ask, “What keeps making this possible?”
I use the same questions when examining learning needs and making the design decisions documented in my instructional design and eLearning case studies.
What problem in your work keeps returning even after everyone thinks it has already been fixed?