In my last article, I told you about a small silver rod that taught me something my PhD never did:
“We understand parts best
when we see them within the whole to which they belong.”
At the end of that article, I promised a second lesson - one that came earlier in my career, long before the mower, long before Restful Work Again Lab existed.
A Story I've Told at Every Conference
For years, whenever I spoke at business conferences, I would hold up a soda can and start with the same story. A thick block of aluminum - an ingot - gets squeezed thinner and thinner between pairs of giant rollers, under tremendous pressure, until it becomes the thin sheet metal in your hand. It's the same basic process, whether the can ends up holding your drink or the mill down the road is rolling steel instead.
That can-in-hand story was never really about aluminum. It was about the moment, early in my career, that changed how I solve every real-world problem since. I've taught that same discipline to my AI assistant recently, and it has started reporting back, unprompted, "applying Solve@Source discipline here" when it works through an analysis for me.
Here's the story behind it.
A Contract Between Two Giants
Early in my career, I worked at Alcoa's Technical Center, in the R&D group responsible for one of the company's proudest achievements: its rolling mill engineering controls.
Alcoa was, at the time, the most technologically advanced aluminum company in the world. The mills themselves were German-engineered - built and assembled on-site by German engineers. But the moment those German engineers finished, Alcoa's own control engineers would arrive and rip out every electrical component the Germans had installed, replacing them with Alcoa's proprietary controls.
Those controls were the pride of the department. They used sophisticated mathematical models to sense the pressure on the cylinders in real time, predict how an uneven ingot would behave as it passed through, and adjust the rollers on the fly - all so that whatever unevenness entered the mill would come out smooth and within specification. It was elegant. It was hard-won. And Alcoa guarded it closely, reluctant to share it with anyone outside the company.
So when a joint venture brought a Japanese steel company to the Technical Center for a knowledge-transfer visit - same industry, different material, a chance to learn from one another - our department head walked in ready to impress.
"What's Next?"
He held nothing back. He walked the Japanese delegation through the full technology: the models, the sensing, the real-time adjustments, all of it.
When he finished, he expected the guests to be eager for more.
They weren't. Their body language said, as clearly as words could,
"Ok, what's next? Let's move on."
Puzzled, he reiterated the core points, certain the steel industry could put this technology to immediate use in their own rolling mills. Still nothing. Finally, he had to ask directly:
"Don't you have the same process, just with steel instead of aluminum?"
The Japanese team leader answered softly, careful not to embarrass him:
"Yes, we have the same problem in the steel context.
But we tackle it differently.
We spend a lot of effort smoothing the ingot at the source,
before it ever enters the system.
Because of that evenness,
we don't need the kind of sophisticated controls you've developed."
A Lesson Bigger Than a Rolling Mill
I heard this story secondhand, as a young engineer, and it has stayed with me for over thirty-five years.
Alcoa had built the most advanced downstream compensating system in the world - proud, expensive, and genuinely brilliant. Japan had asked a question Alcoa never had: what if the unevenness never entered the system at all?
Alcoa was solving the problem where it was visible: at the rollers, under pressure, in real time. Japan had traced the same problem back to where it actually began: the condition of the ingot before it ever touched a machine.
Neither team was wrong about the physics. But only one had asked where the problem truly started.
That distinction matters far beyond a factory floor. In any sequential process - a production line, a project, a decision, even a season of life -
a defect introduced upstream doesn't stay upstream.
It travels. It gets compounded at every stage after it, until by the time it surfaces downstream, it may be unrecognizable as the same problem that started much earlier, in a place no one thought to look.
So we build controls. We add checkpoints. We manage the symptom wherever it happens to show up - because that's where we can see it. And that instinct isn't foolish; sometimes downstream compensation is genuinely the best we can do. But it is rarely the cheapest, and it is almost never the simplest. The pressure applied downstream isn't corrective. It's productive - doing exactly what it's designed to do. If something is already wrong with what enters that pressure, the pressure doesn't fix it. It amplifies it.
Learning to Solve@Source
I've come to believe this is one of the most under-practiced disciplines in problem-solving:
before reaching for a fix,
trace the problem back to where it actually began
- and ask whether it needs to exist downstream at all.
It's tempting to solve a problem the way it's handed to us. A late shipment looks like a scheduling problem. A budget overrun looks like a compliance problem. A short temper at the end of a long day looks like a discipline problem. Each of those can be managed right where it appears - and often is. But just as often, the real cause sits somewhere upstream: a forecast made too optimistically, a plan built without margin, a morning that started without rest.
Solve@Source isn't a call to ignore the downstream symptom. It's a discipline of asking one more question before you do:
“Is this the source,
or just where the problem became visible?”
This is also why I keep going back to first principles instead of secondhand summaries of them - and why I keep going back to the Bible itself rather than settling for commentary about it. A commentary is, in a sense, a downstream product: someone else's already-processed read on the source. It can be useful, the way a well-tuned control system is useful. But it isn't the source. First-hand encounter with the text - reading it directly, slowly, before consulting what others have said about it - is its own small act of solving at the source.
I've since learned that seeing the source clearly requires the same patience I later learned from that silver rod - you have to SEE the whole system first, or you'll misdiagnose where the SOURCE even is. The two lessons turned out to be two halves of the same habit of mind:
SEE the whole, then trace it to its SOURCE.
It's a habit I now find myself returning to constantly - not only in engineering and business, but in how I read Scripture and think about the shape of a well-ordered life. Just as an uneven ingot compounds its flaws with every pass through the rollers, an unattended condition upstream in our own lives - a missing rest, a misplaced priority - tends to compound downstream, too. The steadiest fixes I've found rarely start at the point where the trouble shows up. They start further back.
I hope this story stays with you the way it's stayed with me - not as a manufacturing footnote, but as a question to carry into your own week:
Where am I solving a problem downstream that could be solved at the source?
Have I traced this back far enough to know where it truly began?
(On LinkedIn this week, I told a much smaller, much more recent Solve@Source story - involving my kitchen island and a sudden invasion of ants. Come add your own solution in the comments before I reveal ours.)
Get a new "Read to SEE" Psalm and a weekly Lab Note, always free at restfulworkagain.com. Download an interactive Psalm 1 and try it for yourself.
