Altana Innovation & Technology Culture

How does your team stay ahead of emerging technology trends while scaling fast?

The work here is genuinely interesting: probabilistic entity resolution at global scale, graph modeling across billions of supply chain edges, ML pipelines that balance precision and recall across massively heterogeneous data sources. The technical problems are hard, and the team gets to work on things that push the boundaries of what's possible in this domain. But we’re deliberate about where we push boundaries and where we don’t, and that deliberateness is exactly how we scale fast. 

We actively track what’s emerging to understand where the landscape is heading, and our engineers are consistently evaluating new tools, frameworks and approaches in their domains. When something interesting surfaces, we run it through a clear filter: Does this create a differentiating advantage for our product? Does it make our knowledge graph more accurate, our entity resolution faster, or our data ingestion more scalable? If yes, we invest deeply, build real expertise, and stay on the frontier. If not, if it’s infrastructure that needs to be reliable but isn’t a source of competitive differentiation, we go with what’s easiest to support — battle-tested, well-understood and boring where boring is a virtue. 

So the short version: We’re curious and we pay attention, but we evaluate everything through the lens of whether it differentiates the product. We innovate aggressively where it does and standardize where it doesn’t, and the result is a platform that lets teams move fast without the complexity tax that kills most scaling orgs. 

What recent product or feature are you most proud of — and what impact has it had?

When the Supreme Court struck down IEEPA tariffs on February 24, 2026, Altana was uniquely positioned to respond because we’d been building toward this moment for months. 

The team had been at work building out our tariff stacking calculator that correctly models the interactions between six or more overlapping tariff programs. The core challenge is what we call the “30 percent problem” — the complex stacking logic where naively summing rates produces wildly inaccurate results. To give a concrete example: A shipment from Israel to the United States carries an actual duty of 28.2 percent, but if you simply add up the applicable rates, you get 143.2 percent. Getting that math right across every product, every origin and every combination of programs is a genuinely hard engineering problem. Within two weeks of the IEEPA ruling, a team of three engineers shipped a minimum viable product. That timeline would have been unthinkable even a year ago. 

This wasn’t a team of 10 working around the clock. It was two to three engineers who deeply understood the domain, using agentic coding to compress weeks of boilerplate, data transformation logic and test scaffolding into days. The system they shipped ingests 100,000 raw customs entries and recalculates duties against billions of rows of tariff data. Agentic tooling handled the mechanical work so the code also got better while the product shipped faster. By early March, customers were already using the tool. Across the platform, the team had identified millions in average duty savings and calculated over one million complex product duties.

What I’m most proud of isn’t just the single feature itself. I am most proud of the system that made this possible: engineers who’d been embedded in the tariff problem for months, infrastructure that was ready when the moment came, and agentic tooling that let a tiny team ship a production system in two weeks that processes billions of rows of tariff data and puts real money back in customers’ pockets. That’s not a demo. That’s the compounding payoff of customer proximity, deliberate infrastructure investment and AI-native engineering working together.

How do you create a culture where innovation and experimentation are encouraged daily?

Give teams a clear understanding of the customer outcome they own, put them as close to that customer as possible, and then get out of the way. That's the short version. The longer version is three things working together. 

First, every team needs to know what winning looks like for their customers, not in abstract key performance indicators, but in real workflow terms. When an engineer understands that a compliance analyst is spending four hours a day manually cross-referencing supplier records, they don’t need a brainstorming session to innovate. They see the problem, and they want to solve it. Customer clarity is the best innovation fuel I’ve found. 

Second, we create direct feedback loops between engineering teams and the customers they serve, which is not filtered through three layers of management and a quarterly roadmap review. Engineers are hearing real reactions to what they shipped last week. That does two things: It makes people care more about the quality of what they build, and it gives them the confidence to try things because they’ll know quickly whether it worked. 

Third, and this is the one most engineering orgs get wrong: You have to let teams move fast enough that failure is cheap. If every release is a six-week bet with a heavyweight review process, people play it safe. If the team can ship something in a day or two, try it with a real customer, and iterate, they’ll take smart risks constantly. Our philosophy is that getting 80 percent of things right and fixing the other 20 percent faster than competitors can ship version one is a massive advantage. But that only works if the team has real autonomy and the infrastructure to support fast iteration. Innovation happens when capable engineers understand customer context and problems deeply and can move fast enough to act on what they see.