For organisations · embedded, interim, project or permanent role

How I can strengthen your organisation

I join an existing engineering organisation and take responsibility for a hard situation — with a measurable result. I work with your people, in your processes, and don’t break what already works.

Discuss a problem About

30+ / 20 people and engineers led~50 M RUB annual budget~50 / 2 clients and data centres as founder

Four situations where it’s worth calling me

I built engineering organisations with hands, processes and budget — and I know what they look like from the inside when an “implementation” fails. Most useful where there is a complex system, people with different interests, and a result that has to be measured.

Stalled software project turnaround

Stuck for months, and the teams argue about why?

A rollout or vendor project with no result for months; the teams and the vendor blame each other; budget drains, and “change the vendor” or “buy bigger servers” decisions get made on emotion.

What I do

I stop the argument on assumptions and agree objective metrics with all sides. I measure: load, resources, bottlenecks, code quality. I agree the solution architecture and a staged plan with success criteria. As a rule I don’t change the teams — I change how they work together. Vendor proposals are evaluated on data, including hidden risks.

Format. Project: diagnosis, then support until the plan is back on track; or embedded leadership of the initiative through to the result.

Teams + vendordispute, no signal
Shared metrics
Root cause
Staged plan
Delivery

~6 / ~12 mo1C MVP and production after months of standstill
0teams replaced
> ½ annual revenuehidden costs a manufacturing client was protected from (estimate)

More: the proof

A 1C rollout stalled for months in a “code or servers” dispute between infrastructure, support and the vendor. After measurements — an agreed architecture and plan: a working version in ~6 months, production in ~12, without replacing teams.

A manufacturing client: a replacement of its industry software whose hidden costs would, by our estimate, have exceeded half a year’s revenue. Together with my partner I gathered the evidence, asked the vendor the uncomfortable questions and shifted implementation risk onto them — the vendor withdrew from the deal itself.

Engineering operations, support, incident management

Support grows with headcount, and the problems keep coming back?

Tickets don’t decrease, strong engineers handle recurring failures instead of development, missed deadlines are discovered from the client, the SLA exists in the contract but not in the process.

What I do

I classify the flow and find the causes: usually a large share of tickets are recurring failures. I split the service into operations and systematic root-cause elimination. I build a managed process: competence levels, severity with automatic targets, escalation before the SLA expires, blameless incident reviews, maturity metrics. Changes go through a short pilot with metrics.

Format. Project: diagnosis → process design → pilot → scale-out; or interim leadership of operations for the duration of the rebuild.

Tickets a day~30~4
First response~2 h~15 min
SLA compliance~80 %~90 %

~7 %fewer escalations between levels
2 yearsof backlog cleared in one year
1 weekthe first pilot; the scheme became permanent

More: the proof

Ticket flow ~30 → ~4 a day and a two-year backlog cleared within a year — by removing causes, not by restricting registration. Mean time to first response ~2 hours → ~15 minutes, SLA compliance ~80 → ~90%, escalations down roughly 7% (estimates from helpdesk data).

A reorganisation carried through the CEO’s resistance: a one-week pilot with metrics agreed in advance — the scheme became permanent. Two data centres with no single point of failure, where monitoring reported a link failure before the client did.

Technical leadership: interim, embedded, permanent

The stream exists. Nobody owns the result.

The founder-CTO is overloaded, the leader has left or the company is scaling: decisions are postponed, the team works without priorities, technical debt accumulates, hiring drags on.

What I do

I take the stream under my responsibility: priorities, architectural decisions, processes, people, budget, vendors. I build it to run without manual control: levels of responsibility, documentation as part of the work, “grow your own replacement” mentoring, outcome metrics. I do the economics: automate, build in-house or buy; grow without headcount growing in proportion.

Format. Permanent role, interim for a transition, or fractional leadership of a stream — I’m open to all three.

BusinessCustomers · budget · P&L

Technical owner of the streampriorities · architecture · economics · people

EngineersOperationsVendors

30+ / 20people and engineers, ~50M RUB a year
~50 / 2clients and data centres from zero
2022 →the company runs after my exit

More: the proof

Technical Director at INCO: 30+ people, 20 engineers, a ~50M RUB annual budget, contractual SLAs with business-critical clients. Founder and CTO of IT Native: from one person to ~50 clients, two data centres and ~50M RUB peak revenue; the company has run since my exit in 2022.

Insourcing workstation assembly with automated deployment — external payments gone, quality and motivation up. Re-pricing roughly half of the client base on an hours-versus-revenue analysis — economics restored. An engineer grown from first line to infrastructure architect.

A similar situation? Let’s discuss

New layer · AI in delivery — a pilot in one team

AI already writes the code. Now you need managed delivery.

Engineers use AI tools each in their own way: speed went up on tasks but not in delivery; unreviewed code is growing; it’s unclear who answers for what an agent wrote; there’s nothing to measure the effect with.

What I do

I don’t roll out a tool — I rework one team’s process so that AI operates inside the existing discipline: project rules for agents, mandatory review, tests as a condition of acceptance, limits on autonomy. A pilot with metrics agreed in advance: cycle time, share of changes with tests, defects in production. Based on the result — scale-out, or an honest “it didn’t work here”. Not tool training and not an AI strategy: my model is proven in my own projects; I haven’t built an AI-native organisation at scale and don’t promise that.

Format. Embedded in one team for the duration of the pilot; beyond that — based on the result.

Engineer + AI agent
Review
Tests
Metrics
Controlled delivery

2025 →daily in this model
85+e2e scenarios in CI in the flagship project
1team — the pilot’s boundary

More: the proof

I have worked in this model daily since 2025: two products where a significant share of code, tests and migrations is written by agents under project rules, while architecture, review and production stay with a human; in the flagship project — 85+ end-to-end scenarios in CI and dedicated agents for deployment and migrations. Before that — leading test-automation teams in international outstaffing (Python, CI/CD) and a culture of “a change isn’t done until the documentation is updated”.

How I work inside an organisation

In your processes and tools.I change only what gets in the way of the result, and explain why.
Through a pilot, not a decree.Sceptics are convinced by data, not by me.
All sides at one table.Conflict becomes shared criteria, not a search for the guilty.
People stay.The rules and how people work together change — not the team.
A measurable outcome.Escalations disappearing, deadlines holding, before/after numbers.
A change is done when the cause is closed and the documentation is updated.Otherwise it all comes back in six months.

Engagement formats

Permanent roleleading an engineering stream, operations or product engineering
Interimfor a transition or until a permanent leader arrives, with handover
Embeddedinside an existing team, accountable for a stream or initiative
Projectdiagnosis → design → pilot → scale-out, with an agreed result

Remote from Belgrade; open to on-site presence for a permanent or interim role. Timelines — once the context is understood.

400+ · ~96 h the email recovery the vendor considered impossible — The story →

Have a problem inside your organisation that isn’t moving?

Write in 2–3 sentences what is happening and what you have tried. I’ll reply with how I would approach it; if it isn’t my kind of problem, I’ll say so straight away.

Discuss a problem About

Emailsaltykov.nikita@hotmail.com LinkedInlinkedin.com/in/nikita-saltykov

Need a standalone system built autonomously? What I can own end to end.