Where people,
business & technology
meet.

The work behind the change

Leading people through change is not a communication exercise. It starts before the first announcement — with understanding what people are actually afraid of losing, and what they believe is working that no one has asked them about.

Over the course of my career I've led two types of organizational change that taught me the most. The first was a merger of two large, separate service teams into one. The fear was immediate and legitimate: will my job change, will I still do meaningful work, what happens to the things we've built? The answer wasn't a slide deck — it was structured listening, clear boundaries around what would and wouldn't change, and involving people in how the new model would actually work. The second type was system rollouts — asking people to do their daily work in a fundamentally different way. Here the approach is the same: start with what they did before, understand their actual process, and find what they themselves could change to make the whole thing work better.

I've held people leadership responsibility for teams ranging from 30 to 50 people in customer service operations — managing daily performance, coaching individuals, and owning the P&L. I've also led a smaller expert team combining a developer, a data analyst, and a process developer — a very different dynamic that requires more peer-level collaboration and less directive management.

At Tribedo I worked in the management group as the head of the development unit, representing development work to the business and translating business priorities back into the team. That role demanded something specific: the ability to sit in a strategic conversation and understand the commercial stakes, then walk back to the team and make the work feel connected to something real.

I've completed formal coaching training and apply it practically through the questions I ask before proposing anything: why does this need to change, what does good look like, how will we know when we're there. The answers to those three questions shape everything that follows.

What this looks like in practice: project portfolio management across concurrent initiatives, stakeholder communication across levels from frontline staff to executive teams, change readiness assessment before major rollouts, and the ongoing work of keeping people aligned when the situation shifts.

Turning numbers into decisions

Most reporting fails for the same reason: it shows what happened without connecting it to what anyone should do differently. My work has always been to close that gap.

At Tribedo I built the company's BI reporting infrastructure from scratch — starting with identifying which data points actually mattered, defining them precisely, selecting the tooling, and leading the rollout. The result was a reporting system that let operational managers run their teams independently, see their own results in real time, and identify problems before they escalated. That project ran from 2018 to 2019 and became the foundation the whole organization's performance management was built on.

The strategic steering group's performance dashboard — designed and built together with reporting specialists — was another layer of the same work: taking complex operational data and making it legible to people making decisions at a company level. Getting that right requires understanding both sides deeply enough to know what to show and what to leave out.

On the commercial side, I built a pricing tool that supported contract negotiations — a structured model that let the business walk into framework agreement discussions with defensible numbers rather than estimates. That work contributed to a 30% reduction in pricing. A separate operational improvement initiative achieved a 20% reduction in unit costs.

The bridge between business and technical rarely holds on its own. I've seen the pattern repeatedly: a data analyst or controller who understands exactly what needs to be optimized, and an operational unit that makes decisions without the visibility to act on that insight. Fixing that gap requires understanding both sides — the logic of the business unit's daily decisions and the structure of the data behind them.

The complexity behind the interface

Every system a company runs is a set of commitments — to a process, a data model, a way of working. Changing a system means changing all three simultaneously, and making sure the people who depend on it don't notice the difference on payday.

My deepest area of expertise is workforce management and HR systems. At Mehiläinen I own a WFM system — Ortec OWS/ESS — that handles shift planning, time tracking, payroll data, and regulatory reporting for approximately 10,000 employees. The system is business-critical in the most literal sense: errors don't show up in a dashboard, they show up in someone's salary. My responsibility covers the development roadmap, vendor relationship, integration maintenance, user support escalations, and the ongoing work of aligning the system with changing collective agreements and business requirements.

Earlier at Tribedo I led the full WFM system selection and implementation — from requirements gathering through vendor evaluation, integration design, user training and rollout. That project covered roughly 500 people and connected into payroll processing via a payroll automation robot, which required precise definition of every pay event and how it should be handled by the system.

Beyond WFM: I've worked extensively with Mepco and CGI Palkat on the payroll side, Workday and Sympa HR as core HR systems, Nepton and MaxTech for time tracking, Genesys Cloud for contact center telephony (including a full migration from a previous provider), and ServiceNow and Zendesk for service management. Each of these has required the same core skill — understanding what the system actually does at a logic level, not just how to use the interface — because that's where integration problems live and where configuration decisions have consequences.

Integration design is a distinct skill within this area. I've mapped system architectures across complex multi-vendor environments, defined data flows between HR, WFM, payroll and operational systems, and communicated those specifications to both internal developers and external suppliers. The work requires being precise enough that nothing is ambiguous, and practical enough that it can actually be built.

Beyond the demo

There's a version of AI expertise that lives entirely in slide decks — use cases, potential, transformation. I'm not interested in that version. I got interested in AI when I realized I could use it to build things that actually run.

My understanding of AI tooling operates at several levels simultaneously. At the application level, I use Claude, ChatGPT, Gemini, Microsoft Copilot, and Nano Banana as daily working tools — not interchangeably, but with a sense of what each does well. At the integration level, I've built production applications on top of the Claude API, which requires a different kind of understanding: system prompt architecture, token economics, how to structure multi-turn conversations, how to handle failures, and how to keep costs predictable at scale.

Fuseapt is a real estate investment analysis SaaS I built and deployed independently. It runs on Cloudflare Workers, integrates live property listing data from Oikotie via a server-side API, processes it through the Claude API with structured system prompts, and returns financial analysis including yield calculations, cash flow scenarios and capital appreciation modeling. The architecture includes rate limiting, access key authentication, and tiered usage logic. Cost per analysis is approximately €0.02.

VirtualFuture.net is a B2B AI chatbot service I built and brought to market for Finnish SMEs — including the product, the pricing model, the campaign landing pages, and the outreach infrastructure.

Automation work spans several platforms. In Make (formerly Integromat) I've built functional automations connecting Telegram, Make, and Notion — a pipeline where a message triggers task creation and tracking without manual input. In Copilot Studio I built a practical calendar management agent to help colleagues find shared meeting availability. GitHub is my standard for version control across all projects.

My approach to prompt engineering is practical rather than theoretical. I work at the level of structured system prompts — defining role, context, constraints, and output format explicitly — and I build prompts that are reusable and predictable rather than one-off. When I work at the API level, I think about prompts as code: they need to be version-controlled, testable, and maintainable.