Engineering Leadership · AI-First Development
D. Rechkin
I build software, engineering teams, and the systems that help them perform at their best.
20+ years engineering · 6 direct reports · 8 products · ~10 engineers coached · 4 countries
Engineering leadership
Building teams that make good calls without me in the room
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 — including two who have moved to the next career level, while coaching others toward greater technical judgment, ownership, and autonomy.
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.For suitable research, repetitive implementation, and unfamiliar-technology work, I've seen this approach produce roughly 5–10× faster execution—while keeping testing, review, and human accountability in place.
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.
Getting sceptical and inexperienced developers onto AI-assisted workflows without dropping their standards.
Building shared AI skills and automation workflows, then leading their adoption across multiple products.
Multi-agent workflows where one agent drafts and another is pointed at it to find what is wrong.
Wider review coverage than one reviewer can give, with a human verdict at the end of it.
Getting a team productive in a stack it has never shipped before, in days rather than months.
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
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
Architecture and systems
Software architecture, distributed systems, SaaS and product engineering, APIs.
Languages
TypeScript, JavaScript, C++, C#, SQL, PostgreSQL, MySQL, Redis.
Platform
AWS, Google Cloud, Docker, Terraform, CI/CD, DevOps, legacy modernization.
Quality
Automated testing, review practice, and delivery guardrails.
Career
Engineer to engineering manager
Engineer → Senior/Staff Engineer → Team Lead → Engineering Manager
Software Development Manager · Fresche Solutions
2026–Present
Team Lead · Fresche Solutions
2023–2026
Staff / Senior Software Engineer · Fresche Solutions
2009–2023
Software Engineer / Senior Software Engineer · The Nation Traffic Ltd.
2005–2009
Earlier Software Development
2003–2005
Beyond the team
Organizational impact
Created a company-wide recurring Show & Tell, now attended by roughly 20 people, where teams demo products, engineering approaches, experiments, and lessons learned.
A regular contributor to the internal forums where people compare what is actually working with AI, and what is not.
Shared engineering practices and reusable AI skills that outlive the team that wrote them.
Teams in other countries, on review discipline and the standards everyone is meant to be holding.
Building something difficult?
I'm interested in Engineering Manager and Software Development Manager opportunities where strong engineering, autonomous teams, and practical AI adoption matter.