By Gene Kwon, Salt Lake City, UT
The call that software can’t make
A shipment gets stuck at a dock. The tracking software says “in transit,” but nobody knows why it hasn’t moved in two days. What actually fixes this isn’t a dashboard. It’s a phone call to someone who owes you a favor and picks up on the second ring.
I’ve built companies around solving operational problems, and every single time, the fastest fix came from a relationship, not a system. Technology tells you what happened. People tell you why, and people are the ones who can actually change it.
What good software is actually for
I’m not against automation or data. Good systems remove guesswork and save time. But a platform can only act on the information it’s given, and it can’t build trust with a warehouse manager who’s had a rough week or a carrier who’s about to get slammed with volume they didn’t plan for.
The tools are supposed to free up time for the conversations that matter. When people treat the software as the whole solution instead of half of it, that’s when things break down. I’ve watched companies pour money into systems while ignoring the partnerships that made those systems useful in the first place.
The partner who tells you the truth
Here’s something I think gets missed constantly: the value of a partner isn’t that they always say yes. It’s that they tell you the truth when something is about to go wrong.
A vendor who has a real relationship with you will call before the problem shows up in your reports. They’ll say, “we’re going to be short next week, plan around it.” That warning is worth more than any predictive analytics tool, because it comes with context a machine doesn’t have: who’s reliable, who’s stretched thin, what’s actually happening on the ground.
I’d rather work with a partner who tells me bad news early than one who has better software and tells me nothing.
Diligence looks like showing up
I’ve said before that success in this kind of work comes down to being nimble, staying connected, and being diligent. People sometimes hear “diligent” and think it means checking reports more often. I mean something more basic: staying in touch with the people who make your operation run, even when nothing is on fire.
That’s what keeps the network solid. You can’t build trust in a crisis. You build it in the quiet weeks, so it’s there when things go sideways.
Where I’ve seen this play out
Across the businesses I’ve helped start and grow, the pattern is consistent. The companies that treat vendors and partners as line items on a spreadsheet struggle more than the ones that treat them as people with their own pressures and incentives.
I’ve been part of teams solving shipping and logistics problems, and the recurring lesson is that the technical solution rarely fails on its own. It fails because nobody maintained the relationship that would have caught the problem early.
What I’d tell someone new to this
If you’re coming into logistics or any operations-heavy field, learn the systems. You need them. But don’t stop there. Learn the names of the people on the other end of your supply chain. Call them when you don’t need anything, not just when something’s wrong.
Networking gets talked about like it’s a skill for salespeople. It’s not. It’s an operational advantage. The person who knows a dozen people they can call in a pinch will outperform the person with the better dashboard, most weeks of the year.
The trade-off nobody names
Building real relationships takes time you could spend optimizing a process. That’s the honest trade-off. You will spend hours on calls and check-ins that don’t show up as a line item of value anywhere.
But when the system breaks, and it will, those hours are what get you a fast answer instead of a support ticket in a queue. I’ve made peace with spending that time. I think more people in this field should.
The short version
Technology handles volume. People handle exceptions. Almost every real problem in logistics is an exception, not the volume. That’s why I keep investing in relationships first and treating the technology as the thing that supports them, not the other way around.