Everyone’s building. Who’s making it work?

A working demo can make a problem look solved long before anyone’s work has improved. The system produces an answer. The presentation goes well. Weeks later, the people it was built for are still using their old process.

If you’re the engineer, this is your problem too.

On one of my projects at Traba, I met with operators every day for two months. We eventually reached more than 90% adoption. That experience shaped a belief I take seriously: stay close to the people doing the work, understand their decisions, and keep improving the solution until it becomes useful to them.

The tweet above has become a mantra for my life. Finding the lever takes sustained attention. You have to understand what is keeping a problem in place before you can change it.

Talk to the people. Read the traces.

Don’t be the engineer who avoids talking to end customers. You can spend weeks interpreting an adoption chart when a conversation would tell you what you’re missing.

And read the traces. Follow an actual interaction from the input through the tool calls to the result. What information was missing? Where did the agent make a bad assumption? What did the user have to do afterward? Then sit with that person and understand the consequences.

Could your customer get fired for blindly trusting your agent? If the answer might be yes, their hesitation deserves more attention than another reminder to use it.

Charlie Munger’s observation is useful here:

“Show me the incentive and I will show you the outcome.”

Charlie Munger

Suppose an operator is accountable for every error but has little visibility into the system’s decisions. Checking each result manually may be entirely sensible. You get to celebrate the time saved in a demo; they have to explain the mistake on a real case.

Once you understand the incentives and constraints, you can work backward from the behavior. The spreadsheet they keep open, the extra approval they request, the feature they avoid: each is a clue to what your solution still needs to address.

Perhaps corrections take too long. Perhaps the evidence is difficult to inspect. Perhaps responsibility is unclear. Those are different problems. You need to know which one you’re solving.

Earn their confidence

Confidence has to come from what people can see and do with the product, and from how you respond when it fails them.

That might mean more text explaining a recommendation, with evidence they can check. It might mean redesigning the interface to fit their existing workflow, even if you preferred the cleaner version. It might mean guided sessions or regular office hours where people can bring difficult cases and ask questions they wouldn’t raise in a large meeting.

You learn which of these matters by listening and observing. You also learn when the system itself needs to improve. Explanations and training can help someone use a reliable tool; they won’t make an unreliable one dependable.

Product delivery is one point in that process. Adoption, feedback, and iteration are where you discover how your decisions hold up in someone else’s working day. Some of the most valuable lessons arrive after launch, when people use the system under conditions your demo never covered.

When that work needs daily contact, protect the time. No excuses, no exceptions. Listen, make the change, and return to see whether it helped.

Spend the speed well

AI is making implementation cheaper and faster. You can build further on an assumption before discovering it was wrong. That puts more value on deciding what to build and how it should fit into people’s work.

This is why AI enablement and forward-deployed engineering matter to me. The responsibility runs from understanding the problem through to adoption. It requires technical judgment, patience with people, and the willingness to change a solution you’ve already invested in.

You can still multitask where it makes sense. A customer conversation, a bug fix, a workflow change, and an evaluation can all advance the same outcome. Give the important problem enough sustained attention for those activities to add up to something.

There’s a career lesson here too. Your scope can grow when people outside engineering trust you to collaborate, take feedback seriously, and help them succeed. They bring you into problems earlier. They tell you what’s actually going wrong. They become willing to use what you build because they’ve seen how you work with them.

Use some of the time AI saves you to earn that trust. There’s plenty being built. Stay close enough to find out whether yours is helping.