LINTURI.NET / ABOUT
About me.
I started coding before I learned to read.
The tools have changed. The curiosity hasn't.

MSX
Before I could read, I could press RUN.
10 PRINT "WHAT IF?"
20 GOTO 10My first computer was an MSX. I could barely read, but that did not stop me from copying BASIC programs out of books and pressing RUN.
I did not always understand why a program worked. I understood even less about why it failed. But it quickly became clear that a computer could do much more than play games.
I wanted to find out what else I could make it do.
1986
The start of an upgrade habit
I got my first PC in 1986. Over the years, new graphics cards, more memory and faster processors found a reliable source of funding in my summer jobs.
BASIC gave way to Pascal, Turbo Pascal, C and C++, followed by assembly language. Using software was no longer enough. I wanted to understand how it worked and how to improve it.
1990s
Pixels, assembly and questionable career advice
In the early 1990s, a group of friends and I made demos. Drawing graphics on screen was a programming challenge in its own right.
We wrote our own graphics routines, optimised code and worked out how much we could get out of the hardware. Low-level programming and the mathematics of graphics became practical skills.
Then my teenage self reached a firm conclusion about career prospects:
You probably cannot make a living developing games in Finland.
With hindsight, forecasting was not my strongest skill. Programming took a back seat for a while. My interest in computing stayed.
2000–2003
If we know the fix, why wait?
My first professional IT role was in desktop support at Novo Group. It raised a question that has stayed with me: if we know what is wrong and how to fix it, why should the user wait for someone to arrive?
I began building scripts and remote fixes for known problems. I also automated workstation installations and other recurring tasks.
The best outcome was a problem the user never had to notice.
That work showed me what automation could achieve when it addressed a specific, everyday need.
2003–2016
The full service lifecycle
I joined Pohjolan Voima in 2003. Over thirteen years I worked through service development, insourcing, outsourcing and rebuilding how services were organised.
I saw what happens when technology, suppliers, contracts and business needs fit together, and what happens when they do not.
Having experienced most of the outsourcing cycle, I decided it was time to try the supplier's side.
I outsourced myself to Atea.
2016–2020
The other side of the table
At Atea I took responsibility for service delivery to large, demanding customer accounts. The work meant meeting service commitments, managing change, working with customers and dealing with incidents when plans went wrong.
Reliable technology was essential. So were trust, predictability and a clear sense of who would take responsibility when something failed.
2020–2025
Building the way teams work
My focus broadened to leading people, services and processes. Alongside line management responsibilities, I served on the management team for managed services in Finland and later on the management team of the group unit responsible for onboarding projects.
A major part of that work was developing and owning the group's shared Customer Onboarding process. It needed to be accepted across country organisations and useful enough for people to adopt in their daily work.
We developed supporting tools, project templates and working practices, together with a transparent portfolio view for tracking and measuring project progress.
A process is not finished when it is documented. It is finished when it works in practice.
Making a new contract good news for delivery, too
One recurring challenge was the relationship between sales and delivery. Winning a customer sometimes created more concern than enthusiasm among the people expected to fulfil the promises.
I worked on a model that brought delivery teams into the sales process earlier. Sales gained technical and operational input, while those responsible for delivery could influence commitments before they were made.
We refined the model together over the years, helping sales and delivery work towards a shared goal.
Winning the contract should feel like a win on both sides of the table.
2025
Back to the code
In 2025 I chose to return to hands-on development. I brought with me years of responsibility for IT services, customers, people and international operating models.
Python, TypeScript, JavaScript, Node.js, modern frameworks, no-code tools and agent-assisted development offered a very different toolkit from Turbo Pascal and assembly language.
What struck me most was how much one person could now build.
Since then, I have developed my own applications, automations and AI-based systems, exploring how they can address real business needs. The projects on this site show that work in practice.
The management experience informs the engineering: I consider how a system will be used, monitored and supported as well as how to implement it.
Now
Useful systems start with real problems
I have seen capable people spend too much time on work that software could handle. Often, the teams already know where improvements are needed. Operational responsibilities leave little time to investigate or build them.
I know that situation from experience. It is where I want to help: understanding the problem, designing a workable solution and writing the code to make it happen.
My current work includes lead processing, AI-assisted video production and trading automation. These involve data pipelines, integrations, workflow orchestration, interfaces and operational monitoring.
AI does not remove the need for sound design, security or clear processes. A useful system needs all three, together with attention to how people will use it.
Productivity, usability and security need to improve together.
The point is to turn technology into something that helps in practice.
As a child, I copied BASIC programs from books without always understanding what they did. Today I use AI to help build systems I would not have expected to tackle on my own a few years ago.
The tools and the scale have changed. There is a lot more experience behind the decisions now.
But one thing has stayed the same.
I still want to see what happens when I press RUN.
Education and qualifications
Degrees
- Bachelor of Engineering, Software Engineering — Metropolia, 2009
- Further Vocational Qualification in Computer Installation — Amiedu, 2001
- Finnish Matriculation Examination — Martinlaakson lukio, 1998
Further training and certifications
- ITIL Service Transition — 2019
- ITIL Foundation — 2017
- Hands-on hacking — Santa Monica Networks, 2008
Other courses
- CCNA
- SCCM Administration
- Copilot AI
- Azure Administration
- PowerShell Scripting