For a long time, I thought the hardest part of building AI systems was the technology.
Then I started leading larger teams.
And I realized the harder problems were almost never technical.
They were about people, incentives, and how decisions actually get made inside organizations.
Over the years, I've had the chance to build and lead data science and AI teams inside large enterprises, working across merchandising, supply chain, pricing, marketing, and operations. The problems were complex, the scale was real, and the expectations were high.
But the biggest lessons didn't come from the models we built.
They came from everything around them.
The model is rarely the bottleneck
When something fails in production, the first instinct is often to question the model.
Is the accuracy high enough? Did we choose the right algorithm? Do we need more features?
Sometimes that is the issue.
Most of the time, it isn't.
More often, the real problem is somewhere else.
The data pipeline isn't stable. The workflow doesn't match how the business actually operates. The decision owner isn't clearly defined. The incentives reward short-term results instead of long-term reliability.
You can have a technically strong model and still have a system that nobody uses.
And if nobody uses it, the accuracy doesn't matter.
Scaling a team is harder than scaling a model
Early in my career, most of my focus was on building things myself.
Later, the challenge became building teams that could build things well without me in the room.
That shift is harder than it sounds.
A good AI team needs more than strong modelers. You need people who understand data engineering, product, business context, and how decisions actually happen. You need people who can explain tradeoffs clearly. You need people who are comfortable with ambiguity but still disciplined enough to ship.
You also need trust.
Trust from the business that the system will work. Trust from the team that the work matters. Trust that the problem you are solving will still exist by the time the system is ready.
None of that comes from code.
It comes from leadership, communication, and structure.
Incentives shape systems more than architecture
One of the most underrated lessons in enterprise AI is that incentives matter more than design.
You can design the right platform, the right workflow, the right model, and still fail if the incentives don't support it.
If teams are rewarded for launching pilots, you get pilots. If they are rewarded for short-term metrics, you get short-term fixes. If ownership is unclear, decisions don't happen.
Building reliable AI systems requires alignment across people who report to different leaders, have different goals, and are measured in different ways.
That is not a modeling problem.
It is an organizational problem.
And it is usually the hardest one.
Real impact takes longer than anyone wants
There is always pressure to move fast.
Build a prototype. Show results. Launch something visible.
Speed matters.
But systems that support real decisions take time.
You have to understand the data. You have to understand the workflow. You have to understand what happens when the system is wrong. You have to make the output trustworthy enough that people are willing to rely on it.
That kind of work doesn't always look impressive in the short term. It often looks slower than it should.
But when it works, it compounds.
You stop rebuilding the same thing every year. You stop running the same manual process every quarter. You stop having the same debate every planning cycle.
The system starts carrying part of the load.
That's when the impact becomes real.
Leadership changes how you see the problem
When you are building models, the problem looks technical.
When you are leading teams, the problem looks human.
You start thinking less about algorithms and more about questions like:
Who owns this decision? Who is accountable if it fails? What tradeoff are we actually making? What will people do if the system disagrees with them? What happens six months after launch?
Those questions don't show up in a notebook.
But they determine whether the system survives.
Why I still care about building
Over time, I realized that what I enjoyed most was not the title or the scope.
It was the process of taking something messy and making it work.
Understanding the real problem. Designing a system that could live with it. Building a team that could carry it forward.
That realization is part of what eventually pushed me toward starting something new.
Not because enterprise work wasn't interesting. But because I wanted to spend more time closer to the point where systems are still being shaped.
Where the decisions are not fully defined yet. Where the constraints are not fixed yet. Where you can still design things differently.
Those environments are harder.
They are also where I learn the most.
What I believe now
Strong models matter. Good architecture matters.
But in real organizations, the difference between something that works and something that doesn't usually comes down to people, incentives, and decisions.
If the team is aligned, the system can survive imperfect models.
If the team is not aligned, even great models won't save it.
That's the part of AI work that doesn't show up in benchmarks.
And it's the part I find the most interesting.