Hello!
This is going to sound ridiculous.
For two reasons. First, you might think I overcomplicate things, which I do. Second, you might accuse me of textbook engineer behavior. I'll say it now, I am guilty. But in my defense, “all associated privileges” were conferred upon me.
Earlier this year, I was working manual labor (truck hand duty). One job involved helping a customer move what I can only describe as heavy, chaotic sewing stuff from one location to another. I feel obligated to emphasize just how heavy this stuff was. It was heavy. Indisputably, completely heavy.
Midway through the delivery, while the crew and I were actively manhandling some large, unidentified textile contraption, the customer, a woman overseeing the move, looked at all of us and asked, cheerfully:
“Which location do you think is better?”
The others were seasoned professionals. They gave her the perfect answer without hesitation. “This one, definitely.”
I, on the other hand, was too busy trying not to fall over and die. But I could feel her eyes on me. Waiting for my opinion. And under that pressure, my brain did what it always does when cornered by ambiguity: actively seek a scope, then cover that with nonsense.
So I answered.
“Do you mean in terms of loading and offloading? Because it’s hard to compare. Loading works against gravity; offloading works with gravity, so offloading is always going to feel easier, and if things are that obvious, a comparison seems unfair.”
She blinked. I had misunderstood.
She clarified that she meant business-wise. As in, which shop location was better for her informal sewing operation?
This surprised me. Why was I being consulted? I was barely managing to survive the delivery, and now I’m being asked to weigh in on commercial strategy?
But I gave it a shot. A very long, instinctive shot.
I explained that her old location, while safer and flanked by high-end shops, probably didn’t attract much foot traffic. Her business is informal, and being surrounded by formal, upscale establishments can be a mismatch. The new area, on the other hand, is denser, more residential, and has a more chaotic energy. Safety goes out the window. But more people, more potential customers. Assuming she doesn’t face serious local competition. And for a business like this, where trust plays a huge role, competition can be fatal.
Now, you might be wondering how I managed to rattle all this off. The answer is: I didn’t.
What I actually said was probably garbled, abstract, and mildly incoherent. I'm pretty sure she walked away unsure what I was trying to say, which is precisely why this blog project exists: To train my thoughts into structure.
But setting aside my poor articulation for a moment. What I want to focus on is the reflex. The mental habit that kicked in when faced with a problem. How an engineering-trained (cough cough) mind instinctively tried to model, compare, isolate variables, and search for assumptions, while sweating under a 40kg load of fabric-based who-knows-what.
This post is about that reflex and others like it. Mental habits trained in the lab sneak into life everywhere else. Sometimes they create confusion (I'll have you know that the lady did, in fact, move back to her old location, and I probably had no hand in it). This reflex to overanalyze, to see the connections between foot traffic, competition, and customer trust, is a habit called systems thinking.
PART ONE: "It was all of them, a system problem!"
Back in June of 2023, my team and I were working on a line-following robot (aptly named GRACE). She was meant to be fast, elegant, and autonomous. At this point, we were implementing the final control algorithm, trying to optimize her performance. That’s when we hit a bottleneck.
The robot could navigate the line, but only up to a certain speed. Beyond that, it would veer off or jitter. We had reached the edge of stability. And here’s the interesting part: this wasn’t a code problem. Or a sensor problem. Or a hardware problem. It was all of them, a system problem!
The components in question had been developed months apart. The sensors (how many, how sensitive, and how fast they sampled) were dictated by the hardware we had acquired, the chassis design, and other constraints. The motor control code, now being tested, was technically modifiable, but that didn’t mean it could fix everything. Any change we made to one piece ricocheted through the whole system. We had run face-first into systems thinking.
Systems Thinking
Systems thinking is the cognitive shift from linear cause-and-effect logic to multi-variable, dynamic interaction modeling. In other words, it’s the difference between fixing a single leaky pipe and understanding how water pressure, pipe age, and foundation shifts all connect to cause floods.
It's easy to understand simple chains: A causes B. Push a button, get a light. But real systems don’t work like that. In systems thinking, an action in one part of the system might trigger ripple effects in another—often indirectly, sometimes with delay, and not always in predictable ways.
You don’t wait for things to bottleneck; you study how they interact under different conditions before the design. You start asking:
What would happen throughout the system if this variable doubled?
Who else does this decision affect?
Are there invisible constraints shaping this process?
What assumptions are baked into the system that nobody is questioning?
Look beyond what’s being presented. Analyze not just the problem, but the surrounding structure. Review the mechanisms already in place. Consider where incentives, friction, or feedback might be hiding.
But seeing the system is only half the battle. When the system is rigid, you have to adapt. This requires a different kind of mental agility: flexible problem-solving.
And in case you are wondering Grace participated in the race.
PART TWO: "Developer wizarding words"
Earlier this year, my favorite uncle came to me in a state of loud panic. An app he depended on refused to install on his phone. He’d already done the rounds: technicians, salespeople, advice from every possible anybody. The consensus was brutal: get a better phone. Translation: spend money you don’t have.
Naturally, I offered my services.
But not without a disclaimer. I’m known in the family for my... let’s say, experimental approach to fixing things. So I made him agree verbally, if not legally, that any irreversible damage would be chalked up to "engineering risk."
Then I got to work.
Step one: define the failure precisely. No vague “it won’t install.” I needed the actual error. After some digging, I found the exact constraint: a permissions conflict, the Draw Over Other Apps privilege, which this phone’s Android version handled in a strange, restrictive way. The system was blocking the install because it couldn’t reconcile access across layers.
The "solution" wasn’t in the app settings or the installer. It was inside the system’s permission architecture. So I read. I tested. I bricked the phone temporarily (just a little). A few hours later, I was manually modifying parts of the phone’s source-level config via debug mode (Developer wizarding words).
Nothing fancy, just a bypass of the overlay permission using shell commands. But it worked.
The app installed. My uncle could breathe again. And the phone lived to tell the tale, for a while (it was stolen shortly after said occasion).
Flexible Problem Solving
It’s the cognitive habit of working within constraints you don’t control (which is all the time), while refusing to collapse into helplessness or brute force.
It’s, and this includes venturing into unknown territory:
Identifying the problem (not just the symptoms)
Understanding what can’t change (the hardware, the OS version, the money, the scope, there's always something)
Finding what can be reconfigured.
Learning just enough to execute something targeted and safe.
FINAL PART: "Montages are not fun when you’re starring in them"
I’ve had the pleasure of handing out this piece of advice: "Just be tenacious."
It sounds poetic when I say it. But I suspect it lands like one of those "don’t be sad" lines—useless in practice. Advice is frustrating that way, often too narrow to mean much. But that’s beside the point.
The point: here’s the fourth and final story.
There’s one week from two years ago that I can account for, hour by hour. It started with a phone call. I rang my parents (yes, I’m confessing to that) and told them I had failed. Their response was a less poetic version of "you don’t know how to fail."
Then I loaded my non-working H-bridge contraption into the car, grabbed my 50th 9-volt battery, and drove to campus for what we now call the Tenacity Demo. I failed. Completely. But I was given a week to try again.
What followed was a montage. Except here’s the thing I’ve learned: Montages are not fun when you’re starring in them.
For seven straight days, I lived at my desk. That’s not a metaphor. I slept under it. When I couldn’t debug circuits or code anymore, I closed my eyes wrapped myself up in a blanket and threw myself on the floor. When I could function again, I sat up and resumed.
Important note: Tenacity is not a solo performance. Yes, I worked like a lunatic. But I was carried by others.
A neighbor made me food.
A friend answered late-night calls and walked me through logic I couldn’t trust myself to parse.
Someone brought me a resistor when I was out of breath and out of options.
When it was time for the Redemo, it worked.
I had learned what tenacity is. I still can’t define it for you. Technically, Tenacity, in engineering or life, means iterating beyond failure with courage and community. Tenacity isn’t just blind persistence; it’s boundless and limited, and a dozen other contradictions you could write poems about.
So yes, I’ll keep giving that advice. Be tenacious.
And if you made it all the way here, I now confer upon you all the privileges I am afforded to confer.
Byeeeeeeeee!