Engineering Leadership · AI-First Development

Dmitry Rechkin

I build software, engineering teams, and the systems that help them perform at their best.

Get in touch

Engineering leadership

High-performing teams that do not need to be managed

Most of my work is getting a team to the point where it makes good calls without me in the room. Today that means a team of direct reports, delivery across a portfolio of products, and engineers I coach in four countries. In practice it comes down to handing people problems slightly bigger than they are comfortable with, then backing them. The rest is unglamorous maintenance: keeping priorities and ownership visible, and clearing the small frictions that slow a team down without anyone ever naming them.

Coaching and growth

Mentoring engineers through career levels, with feedback tied to work they actually shipped, and backing them when they are ready for the next one.

Autonomy and judgment

Engineers who own the decision, and know when to pull other people into it.

Distributed by default

Coaching engineers across four countries, where what you write down matters more than who is in the room.

Predictable delivery

Scrum and Kanban used as tools. Jira and workflow automation to take the routine coordination off people.

A team that asks early

Open, no-blame communication and regular meetups, so people raise a problem while it is still small.

Less key-person risk

Turning undocumented practice into something the team can actually run when one specific person is not there.

AI-first engineering

AI as an engineering discipline, not a code generator

Most teams adopt AI as autocomplete and stop there. What actually pays is putting it inside a real engineering process, with evidence in front of it and review behind it. On work it suits the difference is large enough to change what a team is willing to take on, and none of it costs you the technical bar.

Research and evidence

Establish what is actually true about the problem and the technology before any code exists.

Prototype / spike

Prove the risky assumption cheaply. A spike that fails early is the cheapest result available.

Specification

Write down the intended behaviour and constraints so the work can be reviewed before it is built.

Critical review

Attack the specification deliberately. Most defects are cheaper to find here than anywhere downstream.

Implementation

Build against the reviewed specification, with tests and CI guardrails carrying the verification load.

Review

Human ownership of the result. AI-assisted review widens coverage; it does not transfer accountability.

Coaching adoption

Getting sceptical and inexperienced developers onto AI-assisted workflows without dropping their standards.

Reusable AI skills

Building shared AI skills and automation workflows, then leading their adoption across multiple products.

Agentic workflows

Multi-agent workflows where one agent drafts and another is pointed at it to find what is wrong.

AI-assisted review

Wider review coverage than one reviewer can give, with a human verdict at the end of it.

Unfamiliar technology

Getting a team productive in a stack it has never shipped before, in days rather than months.

Guardrails

Automated testing and CI carrying the verification load, so the speed comes from the system.

Principles

How I think about engineering

Make work visible

Teams do better when priorities, ownership and blockers are visible. If it has to be reconstructed in a standup, it was never visible.

Automate the routine

Tooling, CI and AI are there to take repetitive work away. When they add a layer of it instead, something has gone wrong.

Give engineers ownership

Developers should understand the problem and make the call, then get feedback early enough for it to change something.

Move fast with guardrails

Speed should come from better systems. Skipping tests and review is not speed, it is borrowing against next quarter.

Share knowledge

What one team learns should be reachable by the others. Knowledge that only lives in one head is a risk, not an asset.

Product leadership · 0→1

An AI-powered operations-intelligence product, concept to beta in about three months

I led a new AI-first product for IBM i operations from concept to beta in roughly three months. It investigates operational issues and helps engineers work toward a resolution. The model was the easy part. The harder problem was running a real engineering process at that speed: evidence before design, specs reviewed before anyone implemented them, testing and delivery guardrails from week one. Validating quickly with the market never meant shipping something we could not stand behind.

0→1 delivery

From concept to a beta customers could use, on a timeline set by market validation.

Technical and product leadership

Owning both the architecture decisions and what the product needed to be.

AI-first process

The research → specification → review loop applied to a product where the technology itself was new.

Guardrails at speed

Testing and delivery controls built in from week one, while they were still cheap.

Technical background

Deep enough to lead the technical decisions

Two decades of building software, before and alongside leading the people who build it. It is the reason I can be useful in an architecture review instead of just present for one.

Architecture and systems

Software architecture, distributed systems, SaaS and product engineering, APIs.

Languages

TypeScript, PHP, C++, C#, SQL, PostgreSQL, MySQL, Redis.

Platform

AWS, Google Cloud, Docker, Terraform, CI/CD, DevOps.

Quality

Automated testing, review practice, and delivery guardrails.

Career

Full history and references available on request.

  • 1

    Software Development Manager

    People leadership, portfolio delivery, and AI-first engineering transformation.

  • 2

    Team Lead

    Technical leadership, mentoring, delivery, and engineering practices.

  • 3

    Senior Software Engineer

    Architecture, product engineering, modernization, and complex systems.

  • 4

    Earlier engineering career

    Software development and technical leadership dating back to 2003.

Beyond the team

Organizational impact

Company-wide Show & Tell

Created a recurring forum, now a standing fixture, where teams demo real work to everyone else.

AI knowledge sharing

A regular contributor to the internal forums where people compare what is actually working with AI, and what is not.

Cross-team practice

Shared engineering practices and reusable AI skills that outlive the team that wrote them.

Coaching past my own team

Teams in other countries, on review discipline and the standards everyone is meant to be holding.