Hello, I'm
Akhilesh Maurya
I like understanding how systems work. And then making them work better.
Director of Engineering · Backend Systems · Exploring AI
Hello, I'm
I like understanding how systems work. And then making them work better.
Director of Engineering · Backend Systems · Exploring AI
I have been working on backend systems for well over a decade now. Not just writing code, but trying to understand why systems behave the way they do. Why something is slow. Why it breaks in a specific way. Why a simple problem became complicated over time.
I started as a software engineer and slowly moved into leading teams. But I never really moved away from the technical side. I still get involved in architecture decisions, production issues, and the parts that actually matter. I think that is important.
Right now I am a Director of Engineering at MoveInSync. I look after 40 plus microservices and work with a team of engineers. The title has changed over the years but the way I work has not changed much. I still ask a lot of questions. I still want to understand things before I change them.
Outside of work I have been spending time with AI. Not because it is trending but because I genuinely think it changes how engineers work. I am still figuring out what that means for me.
"A leader who is too far from the system cannot really help the system."
Not a list of skills. Just how I actually approach things day to day.
Before I fix something, I want to know why it was built that way. There is usually a reason. Sometimes it is still valid. Sometimes it is not. Either way, I want to understand it first.
I care about solutions that work in real systems, not just in theory. A good enough solution that ships is more useful than a perfect one that is still being discussed.
I go back to things I have already done and ask if they can be simpler or cleaner. If something is not needed, I would rather remove it than leave it around just in case.
I try to think about how something will look six months from now. A system that is hard to maintain is a problem waiting to happen. Clarity in code and communication both matter.
A few things I keep thinking about. Will write more on these soon.
Loading...
Where I worked, what I built, and what stuck with me. A lot of systems built and broken along the way.
This is where I have spent the last five years and done some of the most interesting work of my career. I joined as a Senior Member of Technical Staff when WorkInSync was just an idea. We built it from nothing. Desk booking, meeting rooms, visitor management, floor plans, parking, meals. All of it from scratch. 25 plus microservices, designed and owned by the team.
As the product grew, my role grew with it. I moved from SMTS to Engineering Manager, and eventually to Director of Engineering. But through all of that, I kept doing both the technical and the people side. I still get involved in architecture, production issues, and the decisions that actually affect how the system runs. I think that is the only way to lead an engineering team well.
This is where I really learned what performance means. I worked on the ad serving team. The bidder had to respond to every request in under 5ms. Around 70 billion requests a day. That kind of pressure changes how you think about code. Every unnecessary operation matters.
I also built a prediction model pipeline from scratch, moved data jobs from MapReduce to Hive and Spark, and worked on feed and budget systems.
I worked on APIs for Android apps and payment systems. Also integrated HSM into the middleware for security and worked on a Windows POS system that used Protobuf to talk between a Node server and a C++ application. Good early experience in how different parts of a system communicate with each other.
My first job. I built REST APIs for Android apps and worked on the VAS billing team. Nothing fancy but it taught me the basics of building things that real people use. That matters more than it sounds.
Where it all started. Four years of learning algorithms, data structures, and how computers actually work. I still use a lot of what I learned here, even if I did not realise it at the time.
I am not chasing AI because it is popular. I am interested because I think it genuinely changes how engineers work.
I have been working on backend systems for well over a decade. I have seen a lot of things change. Microservices became normal. Observability went from optional to essential. Each shift changed how we build things.
AI feels like the next shift. But what interests me is not AI as a product feature. It is AI as a tool for engineers. How does it change the way we write documentation? How does it help with debugging? What does it mean for how we design workflows?
I have already started using it in my own work. I use it to organise my thinking before writing. I use it to generate documentation faster. I use structured prompts the same way I would design an API. The goal is not to replace judgment. It is to spend less time on the parts that slow you down.
I am still learning. But I find this space genuinely interesting and I want to understand it properly, not just use it on the surface.
How they reason, where they go wrong, and how to use them in a way that is actually reliable.
Systems that do not just answer questions but take actions. Plan, execute, adapt. The architecture side of this is what I find most interesting.
Using AI to reduce the friction in everyday engineering work. Better docs, faster debugging, cleaner code review.
I think about prompts the same way I think about APIs. Clear input, expected output, handle the edge cases. It works.
"I use AI as a thinking tool. Not just to get answers, but to organise ideas and move faster without losing clarity."
I am not always looking for something new. But I am always open to a good conversation. About systems, AI, engineering, or just something interesting you are working on.