Take The Answer Or Argue
The working relationship went through three stages, and the first two were both wrong in opposite directions. The third is not about trust at all.
The working relationship went through three stages, and the first two were both wrong in opposite directions.
Stage one was taking everything. Not out of naivety. Out of having no alternative. When you cannot evaluate an answer, accepting it is the only available move, and for the first stretch I could not evaluate anything. Somebody proposes a structure, you have no basis to prefer another, so you go. That is a defensible position when you are starting and a dangerous one to stay in.
Stage two was doubting everything, which arrived after the first time something confidently wrong made it through. The correction felt like wisdom and was not, because doubting uniformly is the same failure as trusting uniformly. In both cases you are applying a blanket rule to avoid making a judgment. I was slower and no better, and I stayed there longer than I should have.
Stage three is the only useful one, and it is not about trust at all. It is about knowing which questions belong to which of us.
The line turns out to be clean, and once you find it most of the difficulty goes away.
When the question is about how software is normally done, I take the answer. Structure, convention, the standard way a thing gets handled, the name of the pattern that already exists for the problem I am describing. I have no opinion worth having there, and manufacturing one wastes time. Somebody who thinks their inexperience gives them a fresh perspective on how databases should work is going to spend a year rediscovering why everyone does it the other way.
When the question is about how freight actually works, I decide. Whether a shipper would answer that question honestly. Whether that distinction matters to a 3PL. Whether the way a dealer organization splits work across divisions breaks the assumption we just made. None of that is available to a model, and the answers it produces there are reasonable-sounding and frequently wrong in ways only an operator would catch.
That is the whole rule. It is not about who is smarter. It is about whose domain the question is in.
Two things sit awkwardly across that line, and both took me a while.
The first is anything about what we decided previously. Memory is not what this technology is good at, and the same class of problem will get solved a different correct way next month unless somebody holds the pattern. So a proposal that contradicts an earlier decision does not get evaluated on its merits alone. It gets checked against the record first, and if it conflicts, the burden is on the new proposal to be better rather than simply different.
The second is whether the thing is worth building at all. This is the one I would warn people about hardest. Ask how to build something and you will get a good answer about how to build it. You will not reliably get asked whether it should exist. The tool is oriented toward helping you do the thing you said, which means the question of whether the thing is the right thing stays entirely with you. A colleague would have said this is a bad idea. Nothing here will, most of the time.
Now the part I did not expect, which is learning how to push back in a way that produces information.
Agreement is not evidence. You will be told you make a good point when you are wrong just as readily as when you are right.
Agreement is not evidence. If you object and get told you make a good point, that tells you almost nothing, because you will also get told you make a good point when you are wrong. This was the single most disorienting thing early on. In a human conversation, someone conceding is a signal. Here it frequently is not. So I stopped treating agreement as confirmation and started treating it as the absence of a counterargument, which is a different and much weaker thing.
What produces actual information is asking questions that have costs attached.
What does this not handle. The most useful question I ask. Every solution has a boundary, and asking for the boundary produces a list rather than reassurance.
What did you rule out, and why. If a rejected alternative comes back with a real reason, the proposal is considered. If nothing comes back, it was the first thing that came to mind and deserves another look.
Is this the most robust version. I ask this constantly, in various forms, to the point where I eventually wrote it into the project's standing instructions. It still gets asked out loud, because the answer is sometimes no, and that answer never volunteers itself.
And the one I use on myself: can I name what breaks. If I am objecting and I can describe the specific consequence I am worried about, the objection is real and I press it. If I am objecting because it is not how I would have approached it, that is taste rather than judgment, and taste is not a reason to override somebody who knows the material better than I do.
That last test is what finally settled the relationship for me, because it stopped the argument from being about authority.
Which brings me to the harder direction, and this genuinely happens.
Sometimes the answer is better than my instinct, and I have to take it over my own conviction.
I had a period during this build where I was certain a set of failures came from an authentication problem. It was a reasonable read, it fit the symptoms, and I was ready to spend a day on it. The evidence said otherwise, and it said so plainly: the failures were coming from my own application logic rejecting something on entirely different grounds. Different problem, different fix, and my confidence had nothing to do with either.
That is the case where you have to be willing to be moved. Not because the machine outranks you, but because you asked for evidence and the evidence arrived and does not care what you expected.
The failure mode I try to watch in myself is defending a position because it is mine rather than because it is right. That is the same failure that makes experienced people bad at accepting information from anywhere, and having thirty years in an industry makes it more likely rather than less. Expertise is enormously useful and it is also the thing most likely to make you unable to hear that you have this one wrong.
If I had to compress the whole relationship into one line, it would be this: bring your judgment to the questions that are yours, take the answer on the questions that are not, and be honest with yourself about which is which. The second half of that sentence is easy. The third is the work.
Selecting supply chain technology?
PreShiftIQ matches buyers to vendors on measured fit across TMS, dock scheduling, ELD, carrier vetting, and fleet management. Vendors pay for outcomes, never for influence, and the buyer match is free.
See how matching works at preshiftiq.com/how-it-works.
Next in the series: what actually goes wrong, and what to do about it.
