Technical leadership is a production responsibility #
My work sits between company intent and running software. I translate product goals into technical direction, shape the architecture and delivery system, and stay involved in implementation where the highest-risk decisions need evidence.
The objective is not to produce more technology. It is to build the smallest dependable system that creates durable value—and an engineering organisation capable of changing it safely.
What I own #
- Technical direction — architecture, platform boundaries, build-versus-buy decisions, and sequencing
- System design — domain models, APIs, data flows, failure handling, security, and operability
- Delivery architecture — turning an ambiguous goal into independently shippable vertical slices
- Engineering quality — review standards, observability, testing strategy, and production readiness
- Technical leverage — choosing tools and abstractions that make the next change easier rather than merely accelerating the first release
Selected work #
Saleslyt #
AI-assisted relationship management for sales teams. The product brings pipeline visibility, analytics, automated planning, follow-ups, and field-team context into one operating surface.
The architectural challenge is not simply adding AI. It is making automated decisions traceable, keeping customer and activity data coherent, and ensuring workflows remain useful when an external model or integration is degraded.
Myotrek #
Companion software for an ultra-thin connected home gym. The system supports guided exercises, workout logging, user profiles, and progress tracking around a physical training product.
Connected products require software and hardware behaviour to form one understandable experience. State, connectivity, safety, and recovery paths matter as much as the feature list.
Healthcare Microservices #
A distributed healthcare platform built with Spring Boot services, gRPC communication, and Kafka-based events. The focus is clear ownership, reliable inter-service workflows, and observable failure boundaries.
Agromon Core #
Open digital infrastructure for smart-agriculture monitoring, built in Rust. The system explores dependable collection and processing for environments where resource use and connectivity cannot be assumed away.
Offline UPI #
An exploration of tamper-resistant offline payment transport, replay prevention, and idempotent settlement over untrusted relays.
How I make decisions #
- Name the outcome. What changes for the user or business if this succeeds?
- Find the invariants. What must remain true regardless of implementation?
- Map the failure model. What can be delayed, duplicated, unavailable, compromised, or misunderstood?
- Reduce the design. What is the smallest end-to-end system that tests the important assumptions?
- Create feedback. What signals will tell us the system is useful, healthy, and still aligned with the outcome?
What I refuse to optimise for #
- Architecture theatre. A sophisticated diagram is not a substitute for clear ownership, tested failure paths, and operating evidence.
- Velocity that exports its cost. Shipping faster is not progress when the price is paid later through fragile data, unsafe releases, or permanent operational load.
- Microservices by default. Distribution must earn its coordination cost through independent ownership, scaling, reliability, or release needs.
- AI without evaluation. Model capability is only one component. Traceability, authority, latency, cost, degradation, and trust are part of the product.
- Abstraction before repetition. The right abstraction is usually discovered through several real cases, not predicted from the first one.
The artefacts of good leadership #
Good technical leadership leaves more than decisions. It leaves a legible system: written invariants, explicit trade-offs, owned services, observable boundaries, reversible delivery plans, and engineers who understand why the system is shaped the way it is.
My goal is not to remain the person required for every important decision. It is to raise the quality of decisions the system and team can make without me.
The standard #
A useful architecture makes ownership clearer, failures smaller, operations calmer, and future changes less expensive. If it only makes the diagram more impressive, it has failed.
For deeper technical material, see my engineering notes, papershelf, and writing.
For a focused overview, see CTO leadership in Kolkata, database engineering, and systems architecture.