Lavkesh Dwivedi
Senior Software Engineer · AI · Cloud · Leadership · Books · Travel
I'm Lavkesh, and I build and ship cloud-native systems and AI across the major cloud platforms, which I've been doing in some form for fifteen years now. Fifteen years in and I still write my own code, which matters to me more than the title ever has or ever will, because I don't think you keep your judgment sharp by drifting away from the work; you keep it sharp by staying close enough to it that you can still feel where it bends.
I've shipped across medical imaging, fintech, telecom, federal government, and enterprise platforms, and over time the domains start to feel more alike than different. What changes is the vocabulary; what stays the same is the underlying question, which is always some version of: how do you build systems that don't fall apart, and how do you build teams that don't burn out trying to keep them upright. I've been working on both of those problems my whole career, which is to say I'm still working on them.
I care as much about how a team works as what it ships, and honestly probably more, because a team that communicates well and trusts each other will outperform a technically brilliant one that doesn't, every single time and without exception that I've ever seen. I've sat on both sides of that, and there is no clever architecture or favourite tool that can substitute for a group of people who can disagree out loud and still ship together. Blissful Bytes is where I share what I've picked up doing this work, with no filler and no fluff, just the things I actually had to figure out the hard way.
I'd also argue, and I'd hold this position fairly strongly, that most problems in software engineering are people problems wearing a technical disguise. The architecture review that keeps getting pushed. The team that's slower than it should be. The system that nobody wants to touch and that everyone politely talks around in meetings. If you pull on those threads honestly, you tend to find something human at the other end, which is part of what keeps this work interesting for me even now.
Currently: building agentic AI systems and engineering a next-gen enterprise commerce platform in the cloud.
Background
I started writing code professionally in 2011, on federal government case management systems, doing FOIA processing, case workflows, and Section 508 accessibility compliance work that nobody at a glamour-job interview talks about wanting to do. It wasn't fashionable and it wasn't going to be on the cover of anything, but it was rigorous in a way I'm grateful for now, because it taught me very early that software, in the wrong hands at the wrong moment, has real consequences for real people, and that stuck with me long after those particular codebases were retired.
Then I co-founded an IT services company, which was a completely different education from being an employee, because suddenly I wasn't just the engineer in the room; I was also doing sales, managing cash flow, hiring and firing, and explaining to a client at 11pm on a Tuesday why the deployment hadn't gone the way I said it would. I ran that for about a year and a half, which doesn't sound like a long time on paper, but I learned more in that stretch about business, people, and what pressure does to a small team than I had in all the years before it combined.
After that came energy management, then telecom, then healthcare, then fintech, and each domain pushed me into territory that was genuinely new rather than just a different paint colour on the same building. Healthcare taught me what reliability actually means when the system is sitting between a clinician and a patient with something on the line. Telecom taught me distributed systems at a scale that quietly humbles any prior intuition you thought you had. Fintech taught me that the blast radius of a bad deployment can be measured in millions, and that the people on the other end of those numbers are not abstractions. Each one raised the bar on what I expected from myself and from the teams I led, and most of them raised it more than once.
One thing that's genuinely unusual about my background, and I don't say this to puff up the resume, is the multi-cloud spread. Most engineers go deep on one cloud and stay there, often for entirely good reasons, but I've ended up shipping production systems across Azure, AWS, GCP, and PCF, not because I wanted a bingo card but because the work itself kept asking for it. That breadth changes how you think about architecture; you stop treating any one platform as the obvious default and start asking, every time, what actually fits the problem and what you're trading off when you pick.
My personal arc has had a lot of interesting stops too, from small-town Uttar Pradesh to Hyderabad for grad school and then to the US, and across that arc I've sat in rooms in every kind of organisation, from tiny federal teams to scrappy startups to large enterprises with their own gravity. The one thing I keep noticing across all of them is that the technical problems are almost never the hardest part of the job, even when everyone in the room is convinced they are, and I try to bring that perspective into how I build teams and how I approach the problem at hand.
Core Skills
- Agentic AI Development & Emerging Technology
- Enterprise Architecture & Technical Strategy
- Technical Leadership & Governance
- Cloud Infrastructure · Azure, AWS, Microservices
- Prompt Engineering & AI-Native Development
- C# / .NET Core / ASP.NET / Python
- Healthcare IT · DICOM, HL7, Medical Imaging
- Federal Government Systems & Compliance
- Angular / React / TypeScript / VueJS
- SQL Server / NoSQL / Cosmos DB
- Docker / Kubernetes / Terraform / IaC
- Business Development, P&L & Corporate Governance
Roots & Home
I'm from Orai, a small town in central India in the Bundelkhand region, where Uttar Pradesh meets Madhya Pradesh on the map and in temperament. Bundelkhand has a culture all its own, direct and warm in the same breath, plain-spoken in a way that doesn't always travel well across borders, especially in rooms where people have been trained to say everything four times softer than they mean it. I'm proud of that, and I've carried it with me everywhere I've gone, which probably explains a fair amount about how I work and how I show up for people: quick to say what I think, slower to leave once I've said it.
Orai isn't a place that announces itself, but it leaves a mark. The summers cook the road tar soft, the winters arrive politely and overstay, and the town is small enough that you ran into the same five people in three different markets in a single afternoon, while still being big enough that those five people had complicated opinions about each other you'd be expected to mediate. You learn early how to listen for what isn't being said, and you learn faster how to say what you do mean without burning the room down, and both of those skills come up more than I'd have guessed in engineering.
Computers weren't something everyone in Orai had when I was growing up, and they weren't something everyone wanted either, since they were strange, expensive boxes that made phone lines unusable and gave parents something new to worry about. I found my way into them anyway, partly out of curiosity and partly because I was genuinely bad at being bored. The first machine I really sat with was slower than my watch is now, and I have no nostalgia for it, but I do remember the specific feeling of typing something in and having a piece of the world do exactly what I asked, and that combination of stubbornness and curiosity has been the most useful thing I've brought to my career. Everything else is replaceable.
I'm in the Dallas-Fort Worth area of Texas now, which is about as far from Orai as you can get in almost every measurable way you can think of: the climate, the food, the language, the way strangers behave in checkout lines. I've made peace with the weather, mostly, though Texas summer is its own country and the people who pretend it isn't are usually new. I'm happily married, an equal partner to my better half, raising two boys who are already too clever for their own good and will, I assume, find new ways to remind me of it well into their twenties. We share the house with a Shih Tzu, a Pomeranian, and a Persian cat, none of whom hold back their opinions, and honestly, neither do I. The cat believes she pays the mortgage; the dogs believe they negotiated her down.
Building a life in a country that isn't the one you grew up in is its own kind of education, and not the kind any brochure prepares you for. You learn to read rooms faster, picking up who has decision-making authority, who has informal authority, and who's politely waiting for someone else to speak first. You learn to translate context, not just language, because "we should chat sometime" means different things in different cities, and so does silence. Eventually you get comfortable being the person in the meeting who asks the question everyone else was too polite to ask, which has been worth more in engineering and in leadership than any framework I've ever read.
Always Learning
I pick up languages the way some people collect hobbies, without racing any of them and without chasing fluency on a deadline. I'm not going to claim there's a grand plan behind it; the honest version is that languages are the cheapest way I've found to be reminded that the way I think isn't the only way, because every language sneaks a different worldview into your head, with its own opinions about what gets a tense, what counts as polite, and what doesn't deserve a word at all. You don't need fluency to feel that; you just need enough of a foothold to be uncomfortable for a while.
The stars are rough self-assessments: three means I can hold a conversation and only occasionally embarrass myself, while one means I can read a menu and ask for the bathroom, which, depending on the country, may be the most important sentence I'll ever learn.
Svalbard is on my travel list, and people usually assume the appeal is the cold or the polar bears, but it's neither. Svalbard is the kind of place that's more honest about what it is than most places bother to be: there is light or there isn't, the weather has the last word, and the rules are written by the geography rather than by a committee, and I find that restful in a way I don't get from most vacations.
The longer retirement plan is a small place in the mountains and a snake farm, which I know is not what people expect to hear, but I find it entirely logical. Mountains demand patience and reward attention, and snakes are honest creatures who don't pretend to be something they're not, so the combination keeps me away from anything that wastes either patience or honesty. If that's not retirement, I don't know what is.
I read a lot, across history, science, philosophy, fiction, and the occasional book I would have hated in school and now consider essential. Not for professional development; I don't keep a list of "books that made me a better engineer," and I'd be suspicious of mine if I did. I read because the world is genuinely interesting and I'd rather understand it better than not, and the best ideas I've brought to my work have come from outside of it, while the ones that have wasted the most of my time usually came from inside the bubble, where we were all reassuring each other we were right.
If anything on this page resonated, I run free sessions on Topmate for engineers and leaders who want a focused conversation with someone who's been in the room. Whether the topic is a career path you're trying to map out, an architecture call you're wrestling with, a cloud strategy that needs a sanity check, or just a specific problem you want to think through out loud with a second pair of eyes, the format is the same and the cost is the same, which is to say it's all free with no strings attached and no upsell at the end.
I'm open to conversations about engineering leadership, architecture, AI systems, and interesting problems worth solving, especially the ones that sit slightly outside the usual boundaries of any one job description. LinkedIn is the best way to reach me for anything that needs a paragraph or two of context, while X is fine if you'd rather keep the exchange short and direct, and either way you'll get a response, though probably not the same evening unless the message lands at a convenient time on a slow week.