Technical leader · product-minded engineer

Problems rarely arrive as Jira tickets.That’s the part I like.

You can read the polished version—or ask the impolite questions.

Cross-examinationChoose your suspicion

Ask the impolite questions.

Short answer: yes

The useful measure is scope, not calendar occupancy.

Leadership has meant talking directly to customers, setting technical direction, turning ambiguous systems into executable work, giving engineers room to operate and staying available for the decisions that change the outcome.

It has also meant being present when production is inconvenient. Ownership becomes much less abstract when the system is failing and a client needs an honest answer.

People management is not the headline. Judgment, context and responsibility are.

DirectionArchitecture and solution design across cloud, automation, integrations and AI-enabled workflows.

ExecutionLed and co-led teams of three, seven and ten engineers while retaining responsibility for important technical decisions.

Next questionFine. Does he still build?

Selected work / 01Agentic engineering

t0rque

It started with an engineering-capacity problem, not an AI demo.

An agentic engineering system conceived after observing real maintenance and capacity bottlenecks—then architected, built and demonstrated as a working implementation.

Observed constraintProduct decisionWorking implementationHuman approvalHuman control

Inspect the whole story

Three other kinds of proof

The systems changed. The responsibility widened.

02 / Enterprise systems

Turb0

Modern cloud and AI systems meeting automotive workflows, browser constraints and Windows-native software.

Inspect the boundaries ↗03 / Founder experience

Skap & Daugh

Product, technology and customers—from a strong original belief to the evidence that complicated it.

Read the scar tissue ↗04 / Applied AI and R&D

Thomson Reuters Labs

Foundry, ContentCraft and the less theatrical work of turning agent experiments into useful product workflows.

Inspect the R&D work ↗

The career arc

The technology changed. The unit of responsibility kept getting larger.

Read the full chronology

2017–2020Engineering foundation
Frontend, backend, APIs, data and direct customer collaboration across payroll and legal technology.
2020–2022Technical leadership
Architecture, client communication, mentoring and delivery across teams of seven and ten engineers.
2022–2024Founder ownership
Product, technology, design, customers and the expensive difference between conviction and validation.
2024–2025Applied AI and R&D
Agentic platforms, document workflows and full-stack experimentation with multidisciplinary teams.
2025–presentArchitecture and product leadership
Complex automotive systems, engineering direction and an agentic workflow built around real capacity constraints.

What tends to survive contact with reality

A few opinions earned the expensive way.

01Customer evidence beats senior-person certainty.
02A prototype should reduce uncertainty, not decorate a decision.
03Autonomy needs context, boundaries and an honest information flow.
04Being able to build something does not mean it should exist.

Outside the system diagram

Usually moving, occasionally sitting still.

Motorcycles, long road trips, travel, hiking, cars, football and cricket. A useful counterweight to work that otherwise happens mostly inside a screen.

Portrait of Akshay Satheesh — Akshay, without a system diagram.

The boring but useful part

Yes, there is a résumé.

Roughly nine years across application engineering, technical leadership, founder ownership, applied-AI R&D and solution architecture—edited for humans, printable for systems.

Read the web résumé Download the public PDF

Public-safe by design

The public version keeps professional chronology and contact information. Date of birth, gender, nationality, home address, phone number and employer-issued email addresses stay out of it.