If you are an engineer or scientist or doctor turning to business, the first thing I would suggest is "Please go on a lot of sales calls, face rejection if necessary, but persist".
You will develop better communication skills as you realise that explaining your ideas is not so easy.
You will develop respect for sales people.
You may even become good at business!
There is no such thing as a business without selling something. Sometimes the most obvious thing has to be said!
Technology-driven learning: What does this tool do?
Problem-driven learning: What problem am I trying to solve, and why is this tool the right choice?
Which one of you?
I used to think learning a new technology meant finishing the tutorial.
New framework?
Find a course.
Watch it.
Build the demo.
Move on.
But I realized I could finish a tutorial and still not know how to solve a real problem.
So I changed my approach.
Now, whenever I learn something new, I follow 7 steps:
1. Find a problem
Customers can’t find answers across thousands of documents.
2. Understand the technology
Why does RAG exist? What problem is it actually solving?
3. Learn only what I need
Learn retrieval and embeddings, not the entire documentation.
4. Build something small
Start with one PDF and one question.
5. Break it
Ask questions the document doesn’t contain and see where it fails.
6. Measure and improve
Check accuracy, latency, cost, and user experience.
7. Explain it simply
If I can’t explain why I chose it and where it fails, I haven’t learned it yet.
This changed everything for me.
I stopped trying to finish technologies.
I started trying to solve problems with technologies.
The technology will keep changing.
The ability to learn, build, break, and improve is the skill I want to keep.
New LLMs are released so quickly that I stopped asking:
“Is this the latest model?”
I ask:
“Is this model better for my problem?”
My process:
Problem → Define evaluation → Test models → Compare → Measure → Choose.
I compare what actually matters:
> Accuracy
> Latency
> Cost
> Context handling
> Reliability
> Tool calling
A benchmark can tell me what a model can do.
My own use case tells me whether I should use it.
I don’t chase every new model.
I test the ones that could create a meaningful advantage.
Corporate hack I learned:
When you have a huge problem to solve, don’t sit with it alone.
Schedule a call.
Put the problem in front of the team.
Make it everyone’s problem, not just yours.
You’ll be surprised how quickly the solution starts appearing when the right people start thinking together.
Leadership isn’t always about having the answer.
Sometimes, it’s about bringing the right people together to find it.
What’s stopping you from running an LLM locally?
Privacy?
Cost?
Latency?
Hardware?
Model quality?
Setup complexity?
Today, running models locally is much easier than it used to be. @ollama@vllm_project@opencode
The real question is:
Do you actually need a cloud model for your use case?