With more than two decades of experience across infrastructure, platform engineering, and technical leadership, Andrei Skopenko has built and scaled engineering organisations in some of the most demanding environments in fintech and crypto.
He began his career managing servers and hosting infrastructure in Moldova, and progressed through senior engineering roles at Parallels and Malwarebytes. Most recently, he served as CTO at NoOnes, a crypto P2P platform in Dubai, where he scaled the engineering team to 80+ people and launched ML-powered fraud detection that reduced fraud losses by 30%.
In February 2026, he joined Wallester as Vice President of Engineering, with a mandate to accelerate delivery, improve platform reliability, and build a stronger engineering organisation.
We sat down with Andrei to talk about his career, his philosophy on engineering leadership, and what he is focused on at Wallester.
Interviewer: You’ve spent 20 years in infrastructure and engineering leadership, from hosting companies in Moldova to crypto platforms in Dubai. How did you end up in this field, and what’s kept you here?
Andrei: I started very hands-on – managing servers, networking, and hosting infrastructure in Moldova in the early 2000s. Back then, infrastructure wasn’t glamorous. It was about uptime, power redundancy, backups, and fixing things at 3 AM.
What pulled me in was automation and ownership. Infrastructure teaches you that reality doesn’t care about intentions – only about resilience and outcomes.
Over time, I realised I was less interested in just scaling systems and keeping them alive, and more interested in building teams and organisations that could build resilient systems at scale. That’s when engineering leadership became the natural next step.
What’s kept me here for 20 years is simple: engineering is where ambition meets reality. You can debate strategy endlessly, but in the end the system either performs under load or it fails. There’s no spin – only outcomes.
Interviewer: You’ve scaled engineering teams to 80–95+ people at companies like Paxful and NoOnes. What’s the hardest part of growing an engineering organisation that quickly?
Andrei: It’s not hiring fast. It’s keeping coherence.
When you grow quickly, communication complexity explodes. Informal influence networks form, standards fragment, and ownership becomes blurry. The hardest part is maintaining cultural consistency and decision velocity.
At around 20 engineers, alignment happens organically. At around 90, alignment must be engineered and constantly supported. You need clear architecture principles, decision-making clarity, strong engineering managers, non-negotiable quality standards, and a strong incident management process. Without that, you multiply chaos instead of scaling.
Interviewer: You’ve given talks on hiring with titles like “Hire or die!” What’s your philosophy on building engineering teams, and what do most companies get wrong?
Andrei: “Hire or die!” was about the hiring process, but if we’re talking about my philosophy, then under-hiring is often the biggest hidden risk in a company.
In my article “When Hiring Becomes the Safest Decision” I argue that hiring shouldn’t be framed as headcount growth – it should be framed as risk management. Most companies get this wrong in three ways.
They ask for people instead of defining the problem. “We need more engineers” is weak. “Our MTTR increased 40%, compliance delivery is delayed, and we have a single point of failure” is strong. They also speak technical language to business leaders, when executives think in terms of revenue, churn, downtime, and regulatory exposure. And they treat hiring as a cost rather than a protection mechanism. But the real cost is burnout, instability, and missed market windows.
My philosophy is simple: if you can clearly show the cost of inaction, hiring often becomes the safest and most rational decision leadership can make.
Interviewer: You joined Wallester as VP of Engineering in February. What attracted you to the role, and what are you focused on in the first year?
Andrei: Wallester sits at the intersection of regulation, payments, and platform engineering. That’s intellectually challenging in the right way.
It’s a regulated, card-issuing business. Reliability, compliance, architecture, discipline – all that matters, and that’s my environment.
In the first year, the focus is on reducing architectural bottlenecks, improving deployment reliability, shortening time-to-production, raising engineering accountability, and building a stronger leadership layer. The goal isn’t simply to move faster but to move faster without breaking trust.
Interviewer: Your background is heavily metrics-driven – DORA (DevOps Research and Assessment) , MTTR (Mean Time to Recovery), deployment frequency. How do you balance measurement with the messier, human side of engineering leadership?
Andrei: Metrics are essential, but they’re instruments, not answers.
DORA metrics – lead time, MTTR, deployment frequency, change failure rate – tell you where friction exists, but they don’t tell you why. If MTTR is increasing, that could mean architectural complexity, unclear ownership, fear of making decisions, burnout, or a lack of senior depth. Dashboards surface signals while leadership requires interpretation.
The human side of engineering is about psychological safety, clarity of responsibility, ownership, and trust. If engineers are afraid to deploy, no metric will fix that. If managers don’t create ownership, deployment frequency won’t improve sustainably.
So my balance is straightforward: measure systems rigorously, diagnose root causes carefully, and coach people intentionally. Metrics guide the conversation and the culture determines the outcome.
Interviewer: You’ve implemented ML-powered fraud detection and AI-driven testing at previous companies. Where do you see AI genuinely adding value in engineering – and where is it overhyped?
Andrei: AI adds the most value where there’s pattern density and decision fatigue.
In fraud detection, ML is powerful because it can identify subtle behavioural anomalies across millions of transactions, that’s something humans simply can’t do at scale. It doesn’t replace risk teams; it augments them with better signal prioritisation.
In engineering more broadly, I’ve seen real value in intelligent alert filtering, unit and integration test generation, anomaly pattern recognition, and developer copilots that accelerate routine implementation. These are leverage multipliers. They reduce cognitive load and free engineers to focus on higher-order decisions.
Where is it overhyped? Fully autonomous engineering teams, AI replacing senior architectural thinking, and blind trust in generated code without domain understanding. AI is very good at optimisation and pattern recognition. It’s not good at accountability, trade-offs, or long-term system design. The biggest gains happen when experienced engineers use AI as a tool – not as a replacement for junior engineers.
Interviewer: You’ve worked across fintech, crypto, and cybersecurity. How different is the engineering challenge at a card issuer like Wallester compared to a P2P crypto platform?
Andrei: The biggest difference is in the security risk profile and threat model.
In a P2P crypto platform, the primary risks are custody breaches, private key compromise, sophisticated fraud schemes, and social engineering. It’s an adversarial environment – attackers are highly motivated, technically skilled, and financially incentivised. You design for constant probing and assume you are being targeted at all times. Security is active defence.
In card issuing and embedded finance, the threat landscape is different but not lighter. It’s more regulated and systemic: PCI DSS compliance, card data protection, transaction fraud, AML monitoring, partner and API abuse, and regulatory penalties for control failures. Here, the biggest risk isn’t just theft – it’s also control breakdown. If audit trails fail, reconciliation drifts, or monitoring gaps exist, the impact isn’t only financial but reputational and regulatory.
In crypto, you defend against highly technical direct attacks. In card issuing, you defend against fraud networks, internal control weaknesses, data exposure, and compliance violations. Both require strong security engineering. But in embedded finance, security must be deeply embedded into process, governance, and architecture, not just perimeter defence.
Interviewer: You’re a strong advocate for on-site work. Your recent job posts say “Real impact happens in person.” Why do you feel that way, and how do you make that case to engineers who’ve grown used to remote?
Andrei: I’m not against remote work. I’m against slow trust.
Remote work works well for execution, that is, when you have clearly defined tasks and outcomes. But leadership, architecture debates, incident response, and hard alignment conversations move faster when people are in the same room. When you’re building complex systems, nuance matters: tone in disagreements, speed of whiteboard iteration, spontaneous problem-solving, cross-team alignment. Those compound faster in person.
My argument is less about control and more about cohesion. High-performing engineering teams aren’t just collections of skilled individuals. I see them as networks of trust.
To engineers used to remote, I frame it this way: if we want autonomy, impact, and real influence on company direction, we need strong alignment and fast decision loops. Physical proximity accelerates both. The goal isn’t presence for the sake of presence. It’s reducing friction in collaboration and increasing the velocity of trust.
Interviewer: What’s the biggest technical or organisational challenge you’ve inherited at Wallester, and how are you approaching it?
Andrei: The biggest challenge is structural friction, not a single bug or system.
Technically, there’s architectural concentration: a few large services carrying too much responsibility, which creates deployment risk, slower iteration, and tighter coupling between teams. That naturally increases coordination overhead and reduces engineering velocity. Organisationally, the challenge is clarity of ownership. When systems are tightly coupled, accountability is blurred. And when accountability is blurred, decision speed drops and incident resolution slows down.
My approach is deliberate, not disruptive. First, map reality – understand actual dependency chains, deployment bottlenecks, and failure patterns. Then make friction visible, using data to show where delays, rollbacks, or instability originate. From there, strengthen ownership boundaries: clearer service responsibility, clearer decision rights. And raise standards gradually – testing discipline, release confidence, architectural guardrails.
Transformation at this level isn’t about rewriting everything. It’s about systematically reducing friction so teams can move faster without increasing risk. The goal is higher reliability, clearer accountability, and faster delivery but without compromising regulatory trust.
Interviewer: You’ve spoken about “contribution scores” as a performance framework. Can you explain how it works and why you think it’s fairer than traditional performance reviews?
Andrei: Contribution scores are a structured, continuous way to evaluate impact instead of relying on occasional, emotionally charged performance reviews.
Engineers are assessed across clear dimensions: delivery against expectations, quality, discipline, initiative, and teamwork. The evaluation happens regularly – per sprint or weekly – and accumulates over time.
Why is it fairer? It removes recency bias. It reduces subjectivity and politics. Finally, it doesn’t reward fake activity, because commits don’t equal impact. And it provides continuous feedback instead of end-of-quarter surprises. It’s about transparency, predictability, and aligning contribution with real business outcomes.
Interviewer: Finally, when you’re not thinking about deployment pipelines and reliability metrics, how do you switch off?
Andrei: Sometimes it’s writing, sometimes it’s exploring new technologies without deadlines attached. Sometimes it’s helping founders think through problems where I’m not accountable for the outcome.
I also spend intentional time with my family. That helps me switch off the most.
Engineering leadership is high-intensity. The best way to recharge is to do something where failure doesn’t trigger an incident call. And occasionally, that’s just closing the laptop and going offline.
