JetBlue

Andrea Zanon

Decision Systems Engineer

Start with the Problem, Not the Model

I try to be problem-first, not model-first. One principle I come back to often is: never fall in love with the solution; fall in love with the problem. In practice, that means spending a lot of time understanding how decisions are actually made before deciding what technology to use.

That requires asking questions, but also observing. We spend a lot of time sitting with users and simply watching them work. There is often a meaningful difference between a documented process and how operations actually happen. Those nuances matter, especially in complex environments. You cannot model reality well from an ivory tower.

I also believe strongly in starting with the simplest solution that can test the core assumptions. It is cheaper, faster and helps determine whether you are solving the right problem at all. Complexity should be added only when it creates measurable value. Ultimately, the goal is not simply to produce a prediction or a model; it is to improve a decision. That means understanding who makes the decision, when they make it, what information they have available, how the model output will be used and how you will measure whether the resulting decisions are actually better.

Redefining What Good Performance Means

The hard part of data science is rarely building the most sophisticated model. It is building the right decision system for the operations. A model that performs extremely well on a technical metric but is not trusted, understood or used has very little value.

That is why I think it is important to optimize the system, not just the model metric. Performance is multidimensional. There is technical performance, but also operational performance (reliability, latency, robustness, explainability) and ultimately business performance. The first category is usually easiest to measure, so it naturally gets the most attention, even though the others can matter just as much (if not more).

Explainability is particularly important in operational and highly regulated environments, like the airline industry is. Often, it must be considered a product specification, not something optional. Users need to understand why a recommendation was made and be able to challenge it. Trust has to be engineered into the system through transparency, validation, monitoring and predictable behavior. You also have to design for failure: what happens when the model is wrong, the data is unavailable or a dependency goes down? Production systems need fallbacks and monitoring because the operation still has to continue.

The Human Judgment behind Machine Intelligence

I see the biggest impact across three dimensions, which are scale, speed and consistency. Many operational decisions involve more variables, constraints and alternatives than a person can reasonably evaluate at once. AI, machine learning and optimization allow organizations to systematically explore a much larger decision space and do so much faster.

That does not mean removing humans from the process. I think the most powerful model is complementary: machines expand the decision space, while humans provide judgment, context and accountability. The result is a move away from decisions constrained by what a person can manually analyze toward more scalable and systematic decision-making.

  The opportunity for data scientists is to become engineers of decision systems, not just builders of models.  

The key, however, is being able to measure whether those decisions are actually better. More automation is not automatically better. If the data, assumptions or objectives are wrong, automation simply allows you to make bad decisions more efficiently and at greater scale (to sum up, “garbage in = garbage out"). Strong evaluation, governance and monitoring therefore become more important as these systems become more capable.

From Promising Projects to Products People Depend On

Stakeholder involvement from the beginning is one of the strongest predictors I have seen. When users are involved early, feedback loops become much tighter. They challenge assumptions, identify edge cases and tell you when something works technically but does not fit the way the operation actually functions.

I also think when a product is delivering value the directionality of the conversation shifts​. A promising project is one where you present results and stakeholders say, “That looks great.” A lasting product is one where users come back and say, “This is not working as expected, can we improve it?” That may sound like criticism, but it is actually a sign that the product has become part of their workflow and that they depend on it, so they want it to get better.

Lasting value also requires measurable impact and low-friction adoption. If the product changes an important business or operational metric, you should be able to see it. And if possible, the solution should fit into tools and workflows people already use rather than forcing them to adopt another isolated dashboard or application. Deployment alone does not create value; deployment plus adoption does.

The Rise of the Decision-System Engineer

Everything is moving so quickly it’s hard to predict what will happen. But my view is that the role is moving from model builders towards systems builders. AI and coding agents are dramatically reducing the cost of producing software. As writing code becomes easier, knowing what should be built, how the pieces should interact and whether the system is correct becomes more valuable.

That means data scientists should still build strong fundamentals in statistics, machine learning and optimization, but they should also develop a broader understanding of software engineering, system design, data architecture, reliability and product thinking. A model rarely exists in isolation. It sits inside a larger system with data pipelines, APIs, user interfaces, business rules, monitoring and operational constraints.

On the business side, I would emphasize humility and proximity to users. You are often building solutions in someone else's domain of expertise. Listen carefully, ask questions and be willing to change direction when the evidence tells you that your original idea was wrong. I do not think AI is making software less important. If anything, it is enabling us to build much more of it. The opportunity for data scientists is to become engineers of decision systems, not just builders of models.