Lesson 1: Understanding Business Needs - Not “Give Me Data Scientists,” But “What Problem Are We Solving?”

Before talking tech, you first ask WHY. This applies to every IT project, but surprisingly, most people cannot answer this in clear terms. They find it easier to discuss WHAT - the daily routines of entering the office and doing stuff. This gets even harder when working with advanced statistics and hyped technology. You have to go back and forth, posing the stupid questions and building trust with the people you’re trying to help.

An AI project starts with three roles: a domain specialist, a data scientist, and an enabler. The enabler role in the first phase is your business analyst or product owner type - typically extroverted and talkative.

In later phases, your enablers are compliance, legal, engineering, application managers, contracts managers, and whatever other layers exist between a business idea and running code in production. These layers are important, but I’ll leave them aside for now.

What We Did

When seeding and sourcing ideas in any organization, an absolute treasure trove of existing needs will surface - everything from common sense to unmet needs to science fiction. Apart from the preset goals we started a ‘Hypothesis Club’ where anyone in the organization could walk in for an hour at a set time each week and present ideas or needs.

We then backlogged, evaluated, and prioritized based on business value, then examined whether suitable data existed to represent the problem. Methodologically, this is basically scrum plus data.

Why It Worked

The Hypothesis Club made data scientists accessible and transformed these mysterious creatures into friendly colleagues.

Working from an understanding of WHAT the business needs and WHY they need it is foundational to any successful project. But when working with data, it’s even more critical. If you have no understanding of what constitutes success, you’ll have a hard time building and evaluating a model or finding it in data.

What You Can Apply

AI projects need people who know math, but you also need people who understand business and the problem domain. More often than not, you’ll also need roles that can clear problems of communication, legal compliance, and contracts.

But it all starts with everyone having a clear understanding of WHAT we’re aiming to achieve without getting caught up in the HOWs.

Lesson 2: Get Everyone a Second Linux Laptop with Sudo

Our data scientists kept hitting walls with locked-down corporate IT. They needed specific Python versions, custom libraries, root access to configure environments. Have you ever tried to order a non-whitelisted application through corporate IT?

The Problem We Faced

Every request to IT took weeks. This happens because your IT organization is most likely not producing software itself - vendors and consultants do the development. The majority of your employees work with office tools on their PC or access web apps. They click on stuff that will encrypt your endless file shares of unstructured data. So everything on their PC is locked down to prevent that.

What We Did

We gave every data scientist a second Linux laptop with full sudo access. IT panicked: “We don’t have data on those laptops!” We pushed back - these are development machines, not production. Different security model.

Result: Time from idea to prototype went from weeks to minutes. Data scientists stopped fighting IT infrastructure and started developing models.

Why It Worked

We implemented security rules (the Danish Government has an official set of minimum technical requirements) - your basic best practices for setting up clients: VPN access to networks, encryption, firewall, always updated, antivirus. We set up collaboration with the IT security team for audits.

What You Can Apply

If you’re in an organization where you hand out administered, secured laptops to all your consultants with a full IDE setup, good for you. Otherwise, what I described here is basically the liberties you give consultants who aren’t part of your organization.

If you can’t give them separate machines, create isolated development environments with actual autonomy. The principle: don’t make them negotiate with IT for every package they need to test an idea.

Lesson 3: Infrastructure Reality - Laptops Don’t Do Massive Compute

Data scientists wear down laptops faster than normal users. Laptops aren’t designed for massive calculations running day and night.

The Problem We Faced

Laptops don’t scale and aren’t built for that level of abuse, so they die - usually at the most inconvenient time.

What We Did

To have a little quiet in the office from the cries of overheating laptops, we moved compute to the cloud (both data center and public). Besides, we don’t store data on laptops. As data scientists became more comfortable working on Linux, it made sense to embrace SSH connections and use servers for heavy lifting.

Why It Worked

Once people learned to work from a disconnected terminal, sharing resources became necessary. This actually built collaboration rather than competition - people help each other out of self-interest to reduce cycles. Sharing compute is a common way to work in academia. It freed up laptops for further experimentation rather than involuntary coffee breaks. More compute, all the time.

What You Can Apply

Moving to servers is a massive security improvement because it gives control back to the organization and reduces the risk of data proliferation (local cache). Furthermore, working in a professional DEV environment is a cultural step toward productionization.

Lesson 4: Server Park - Real Production ML Needs Real Resources

Moving to cloud for compute was initially risky business, as resource usage safeguards were rudimentary.

The Problem We Faced

One data scientist could set up a job Friday afternoon, and Monday morning we’d return to a huge bill from the cloud provider. This was a risk I had to take seriously as others had faced this.

What we did

I drafted a business case for establishing our own hardware. A small group of multicore servers running Linux with lots of memory, GPU and storage effectively becomes your mini-cloud. Of course, this presented new challenges to the organization.

Why It Worked

Building on the embrace of server-side compute, after the initial investment we were basically paying only the power bill for equivalent performance. A colleague and I had to maintain this infrastructure for a few years until it was finally accepted into the fold.

What You Can Apply

I don’t recommend adopting operations responsibilities, but if you have the skills, you may have to until organizational change happens. A far better solution is working with operations to set up an environment.

Lesson 5: Autonomy and Self-Organization

Data scientists as a group are generally highly intelligent, introverted, have heavy academia backgrounds (often natural sciences), prefer logical thinking, are underpaid, and have to work in political organizations (irrational).

The Problem We Faced

Data scientists differ from your ordinary employee and need an approach that builds on their strengths. They work with open-ended problems that fail often, but they’re also workaholics. Setting too rigid rules will hamper their effectiveness or wear them out.

What We Did

We realized they’re all adults, very agile, and could be trusted. They’re motivated by seemingly ‘impossible’ tasks.

Why It Worked

The team wasn’t in open internal competition but already collaborating on resource sharing and ideation. When everyone understands WHAT and WHY and has self-determination to formulate a strategic approach for solving the problem - plus the tools to solve it - motivation comes pre-packaged.

What You Can Apply

Building a team that collaborates is hard. There’s always a natural pecking order in a group and chemistry issues. Self-organization and scrum methodology ensure that most friction is taken out on work problems rather than on each other.

Lesson 6: Software Development Practices

Data scientists can be wizards with numbers and computers, but this strength doesn’t necessarily translate to building generic software products.

The Problem We Faced

Initially, we adhered to how the rest of the organization procured software: handing over requests to professional developers who then wrote code. The data science models were literally rewritten by a vendor. Mistakes happened - 1 out of 10 can become 90% if you mix up the sequence. The now-alienated production code would predictably need retraining by the data scientists.

Software development is a field unto itself. We could choose between teaching advanced statistics to software developers or having data scientists adopt software development best practices. We chose the latter.

What We Did

We realized that whatever we did, we’d eventually face changing production code, so we might as well take responsibility for running code.

The journey from individual sudo to collaborating in a DEV environment required adopting basic software skills: GitOps for collaborating on code repositories and reviews. Running long-running jobs through detached terminals. Using Docker for controlled environments. Finally, adopting MLOps and deploying code directly into production through specialized pipelines.

And of course, a well-engineered platform to maintain it all (another article).

Why It Worked

Writing code is mental work that has its own rules of the road for collaboration. Data scientists who know enough software development to be safe are easier (and safer) than the other way around.

What You Can Apply

Putting AI into production means taking responsibility!

Even though in AI Act terms, Users (deployers) of high-risk AI systems have some obligations, though less than providers (developers), ask yourself: Does it really matter to your customers whether you bought the error that affected them or produced it yourself?

Lesson 7: Data Access - “Duh… It’s Called Data Science”

One of my favorite points is that the I in IT is often neglected in preference of the mighty T.

That’s part of why we need to ask WHY and WHAT. With AI, you’re basically trying to have machines make sense of information that isn’t readily available to humans. Access to information happens through access to DATA. No data, no AI.

The Problem We Faced

Access to data is always a problem. Red tape and regulations safeguard against misuse - rightly so. However, when working with AI you run into trouble: First, you need massive amounts of data, and endpoints usually aren’t built for that. When you get clearance and technical access, the production system may become unstable due to greedy parasitic AI usage. When data finally arrives, it has quality problems and is structured for its original purpose, having evolved on a case-by-case basis since then.

What We Did

Blatant use of our server park to create a huge duplicate data store, restructuring data to fit cross-domain purposes, even fundamentally redesigning the Danish Business Registry as a graph database. We proved business value by solving low-hanging fruit with political value.

Why It Worked

Data is the blood of AI. If you don’t have access to resources and information, nothing leaves the production line. Showing that this approach solved real, tangible business problems that had remained unanswered for years opened doors.

What You Can Apply

Focus on a limited, hard problem that you intuitively know could be fixed if you had the information. Look at what others have done and transfer the principle to your domain. Ask your data scientist, ask your business owner what they need.

Lesson 8: Critical Mass - “>5 Is a Group” - You Need Scale

You land a brilliant data scientist. A year later, they’re gone. Maybe they couldn’t work because the software they needed was never approved, no access to data, no clear business purpose - or perhaps there simply wasn’t an inspiring work environment.

The Problem We Faced

We can attract some of the smartest people. But we can’t offer them competitive salaries.

What We Did

We accepted that success meant 2-3 years until they had to buy an apartment or otherwise needed higher income. We created a working environment where you could grow as a professional and be visible in networks and conferences.

Why It Worked

Some never left; some followed the predicted pattern. But access to formal requirements for doing data science - compute, data, and the domain - made things attractive compared to the competition. Critical mass adds to the attraction. When you have 15 data scientists, you have a small community. Anything above 5 is critical mass.

What You Can Apply

Maybe you can’t afford to hire 5 data scientists. But you can introduce the thought to management: How many of our systems will be running without AI in 5 years? How will we become more effective when our competitors are using AI?

Lesson 9: Unlearn Perfect

Mathematical precision is part of the academic DNA driving data scientists. This can lead to quality overfitting where products aren’t shipped due to unnecessary personal goals.

The Problem We Faced

Working intensively on a problem can lead data scientists to compete not with the threshold at which they’re delivering business value, but with the score that will measure them against a NeurIPS paper.

What We Did

Data scientists were at times reluctant to release models because they were ‘not good enough.’ The problem was they were actually exactly ‘good enough’ given the abysmal situation the business faced due to workload.

We let business colleagues set the threshold for individual parameters - when models delivered ‘good enough’ value for production. This also served as an acceptance factor based on agency for the business regarding the automation taking place.

We introduced ‘Research Fridays’ where data scientists worked on cutting-edge problems and presented papers to each other.

Why It Worked

Allowing agency for the business took pressure off data scientists. Introducing Research Friday created an academic fulfillment safety valve that otherwise would have affected projects.

What You Can Apply

Balance decision-making between business and data scientists. Eventually, models need retraining and the next digit improvement. Find an outlet for sharpening AI tools.

Lesson 10: Make a Difference - “It Goes Into Production, Bad Guys Get Caught - It’s Real”

Seeing models have real-world implications is a major attraction. This goes for almost all work-related tasks.

The Problem We Faced

Getting AI into production is HARD. If your data science effort never leaves POC state, if AI becomes a glorified business intelligence report for management, then ROC-scores get detached from the impact they help create and motivation suffers.

What We Did

We had data scientists work closely with their business colleagues - sometimes sitting next to each other, evaluating preliminary POC outcomes, sharing insights into case handling. They informally learned each other’s domain language and WHYs.

Why It Worked

Continuous collaboration allowed for deeper understanding of the problem domain and the limitations in data. Projects set out to achieve 100 of ‘something,’ but with AI you often get 80 of the original goal and 30-50 of something you initially didn’t know was there. Close collaboration with business built co-ownership of the problem and the impact.

What You Can Apply

Have your data scientists collaborate directly with business colleagues. It moves them from stakeholders to collaborators and creates co-ownership.

Conclusion

The data scientists who worked in this environment didn’t just ship models. They caught fraudsters, identified regulatory violations, prevented harm. Not because they had better algorithms, but because they had the boring infrastructure and organizational support to actually deploy them.

Shipping AI to production is an organizational and engineering problem disguised as an AI problem. Infrastructure, autonomy, collaboration, data access, realistic expectations - these are boring, non-AI-specific concerns.

These lessons aren’t just about data science - they’re about building teams that bridge research and production in high-stakes, regulated environments. If your organisation’s AI initiatives are stuck in prototype hell, the problem is rarely the technology, more likely the organization is trying to adopt AI without changing how it works.

It’s the organizational patterns that prevent shipping. The choice isn't whether to change - it's whether to change deliberately or keep failing.