Akshay Katyal | MrDHat

High Standards Begin With Bare Minimum Standards

Mon, 01 Dec 2025 23:34:03 +0000

Everyone (rightfully so!) wants high standards. We admire craftsmanship, discipline, and excellence. In fact, we encourage others to push harder and aim higher. In the early days of my first real startup, our code base was a mess, and every single pull request was a disaster. A total dumpster fire, honestly. We all wanted high standards, but we were absolutely drowning in not even having a floor. We had to learn the hard way - before you can aim for excellence, you have to define the bare minimum ruthlessly.

Okay, listen. ‘bare minimum’ is a terrible name. It’s not about slacking off. They are about providing the minimum level of effort and responsibility that allows growth. They are the foundation we build high performance on. Without them, even the most supportive mentor eventually throws up their hands.

Thinking it through, these are the reasons it matters:

They create fairness: If two people are working together and one is consistently putting in effort while the other doesn’t meet basic expectations, the relationship immediately collapses. Bare minimum standards protect the time, energy, and goodwill of everyone else involved.
They reduce noise: Teams drown when people force others to read their mind or constantly mop up after them. On the other hand, when a minimum standard exists, real problems rise above the noise, which makes helping easier and much, much faster.
They make learning scalable: Mentoring requires bandwidth, a finite resource, right? If mentors have to drag people to the starting line, they’ll never have the capacity to guide them toward advanced skills. The basics must be covered. Bare minimum effort from the learner frees up space for the mentor to teach.

Seeing the “Floor” in the Wild

These are some of the most obvious examples of how the floor enables growth in practices:

Stack Overflow: A pretty well-known fact that on platforms like Stack Overflow, there is only one rule: you must show your work. You need a clear description, a code sample, the exact steps you’ve already tried, etc. You don’t earn the right to get help until you show your work first. When the minimum is met, the community becomes incredibly supportive.
Open Source: Every large open source project relies on contribution guidelines. Contributors must follow formatting rules, include tests when needed, and explain the reasoning behind changes. If someone cannot meet these basic requirements, maintainers cannot review the code or teach best practices. Bare minimum rules keep the door open, but they also keep the project healthy.
Wikipedia: Editors on Wikipedia must provide citations and maintain a neutral tone. These are simple requirements, but without them, volunteer editors would spend all their time cleaning up junk claims instead of guiding new contributors.
Engineering Teams: Go to Google, Intercom (we’re hiring!), or any place with a high-functioning engineering team, and the floor is simple: PRs are small, tests pass, and you explain the problem up front. That’s it. No excuses. My absolute favourite explanation of this, and apologies if it’s overquoted, comes from No Rules Rules. It describes how Netflix built high talent density first, before it could go for anything else. High-performance environments aren’t just built on exceptional people. They’re built on removing the friction created when someone does not meet even the basic expectations of the group.

Bare Minimum Standards Are Not Low Standards

Bare minimum standards are not about encouraging mediocrity. They are about making sure the learner is engaged enough that others can invest in them. When people meet the baseline, the focus can shift to real improvement. Only once everyone has done the basic work, the team can spend energy on excellence, depth, and mastery.

The environments that actually work understand this simple, painful, liberating truth: high standards simply cannot exist without bare minimum standards. One creates aspiration. The other creates structure. I’ve watched teams that look effortless from the outside, but underneath there’s a simple pact - everyone shows up ready to do the basics. When that happens, mentors can give sharper feedback, people trust each other quicker, and you see the bar rise automatically. Honestly. For years, I actually thought high standards were the floor. I was wrong.

My Shelf

Tue, 26 Aug 2025 22:00:00 +0100

I’ve been exploring a hybrid approach to learning that combines the depth of traditional books with the breadth of AI-generated research. Traditional books give me the foundational knowledge and deep insights from experts, while LLM-generated research books allow me to explore specific topics with comprehensive, up-to-date information synthesized from multiple sources.

I find that reading a traditional book on a topic, then diving into an LLM-researched book on a specific aspect, creates a powerful learning combination.

The following are some of the content I am currently reading or have recently read (or re-read). I am not planning to make this a comprehensive list. I will probably add more as I read more.

📚 Books

🛠️ To sharpen the Craft

Database System Concepts by Avi Silberschatz, Henry F. Korth, S. Sudarshan
The Staff Engineer’s Path by Tanya Reilly
Hard things about hard things by Ben Horowitz
Zero to One by Peter Thiel

❤️ To Feed the Soul

Genghis Khan and the Making of the Modern World by Jack Weatherford
A Thousand Splendid Suns by Khaled Hosseini
The Godfather by Mario Puzo
The Kite Runner by Khaled Hosseini
Roma by Steven Saylor

🤖 LLM-Generated Research Books

These are books (if you can call them that), I’ve created using AI research on specific topics. Each contains deep research and insights synthesized from multiple sources.

ClickHouse Internals Explained - Deep dive into ClickHouse’s architecture, storage engine, and performance optimizations
Building a Dynamo-like Database - Comprehensive guide to building distributed key-value stores inspired by Amazon’s Dynamo
Apache Doris Internals Explained - Analysis of Apache Doris’s MPP architecture and analytical capabilities

📄 Research Papers

Bigtable - A Distributed Storage System for Structured Data
BitCask - A Log-Structured Hash Table for Fast Key/Value Data
Dynamo - Amazon’s Highly Available Key-value Store
ClickHouse - Lightning Fast Analytics for Everyone

How Elasticsearch Handles Deletions (and Why Our 30TB Purge Didn’t Break Anything)

Mon, 23 Jun 2025 21:00:00 +0100

I recently joined a new team & my onboarding task was to optimize storage in one of our Elasticsearch clusters which held 100s of terabytes of data. One of the first things we needed to figure out was whether the system could survive a massive deletion during peak traffic. We expected indexing to clog up and search latencies to spike. What actually happened was more interesting: the cluster remained stable, but there was clearly a lot happening behind the scenes.

That led me to a deeper understanding of how Elasticsearch handles deletions—and why it works as well as it does at scale.

Deletions Aren’t What You Think

When a document is deleted, it doesn’t vanish immediately. Instead, Elasticsearch (and the Lucene engine beneath it) uses a two phase strategy:

Logical deletion — the document is marked as deleted and the change is written to the translog.
Physical deletion — the document is eventually removed during a segment merge.

This design lets the system respond quickly while deferring the expensive cleanup work to background tasks. Elasticsearch stores data in immutable segments. Since a segment can’t be changed directly, deletions are handled using delete markers.

Here’s what happens when a document is deleted:

A delete request is written to the translog.
A delete marker is created in memory.
On the next refresh, the marker is persisted to disk.
Search queries check these markers to filter out deleted documents.

Why Our Cluster Didn’t Break A Sweat

We deleted 30TB worth of documents and… everything held up. That’s because the initial operation wasn’t physically moving or deleting much but was just tagging documents as deleted.

That said, we did see:

Increased memory usage from tracking millions of delete markers.
“Merge pressure” building up as the system prepared to clean things up later.

The user facing performance stayed consistent but the system was definitely working harder under the hood.

Real Cleanup Happens Later

The actual deletion—reclaiming disk space and removing data—happens during segment merges.

During a merge:

Smaller segments are combined into larger ones.
Deleted documents are left out.
Old segments are discarded.
Disk space is reclaimed.

These merges run in the background and they take time. That’s why deletions don’t immediately reduce the disk usage.

What This Taught Me

This experience highlighted how Elasticsearch is built:

Speed over instant cleanup
Availability over simplicity
Scale over direct control

Deletions aren’t free, they’re just deferred.

Appendix

Metrics Worth Tracking

In case this is something you are doing right now, here are some metrics you can watch:

# Check deleted vs total documents
GET _cat/indices?v&h=index,docs.count,docs.deleted&s=docs.deleted:desc

# See segment layout
GET /your_index/_segments

# Monitor ongoing merges
GET _cat/nodes?v&h=name,merges.current,merges.total_time&s=merges.current:desc

Intrapreneur: Secret Superpower of an Ex-Entrepreneur

Thu, 02 Jan 2025 03:41:58 +0400

In my last post, I described the transition from entrepreneurship to employment and how I felt during it. Today, I want to discuss how I view that transition from a practical point of view.

As an ex-entrepreneur, I knew what my superpowers were. I had learned to empathize with customers naturally, read market trends & build a strong fundamentals-focused team. As I started looking for a role, I had a strong gut feeling that these were the traits that could help me stand out & I projected them as “core features” for the product I was offering - myself. While I thought these were strong things to offer, what I didn’t know was they may not apply directly to my role, so, I had to tweak them a bit.

Using Customer Empathy

For most people who have not done customer-facing roles (majority of engineers working in big companies), it is very hard to relate to a customer. Don’t get me wrong, it’s not their fault. They rarely get that opportunity - maybe because of the way orgs are run or just because they were always taught that code is their superpower. Now, imagine what happens when an engineer shows up in product meetings & starts their conversation by talking about the customer or when they are discussing an important feature to be built with their reportees & the first thing they start with is the business problem it solves. The kind of discussions that are sparked are just magical. Teams start thinking from the first principles. Slowly, it becomes a habit & every other engineer in the room starts focussing on solving customer problems rather than just building a schema for the solution. This, I think created a big impact & established me as a leader. Remember, I was not the one with the best engineering solution or the most amount of context of the systems but doing this one small thing meant I could create a large impact immediately.

Market Trends

In my roles for the past 3 years, I have worked in different industries every time. At Postman, I was working on a security product. In my current role, I work on a financial exchange. I had zero idea about any of these industries when I joined. The entrepreneur in me felt uncomfortable, so, I started spending time, trying to understand the market. For example, to build API Security, I tried every product known to man that can do endpoint security. I read papers to understand how hackers think & what the industry expects from a product that protects them from these hackers. Attended every security webinar I could find, just to make sure I understood the ins & outs of this market. The result was that in the first few months of joining, I was sitting in the room where product strategy was being discussed & I could make meaningful contributions there. Similarly, when I joined my current company, which is a crypto exchange, apart from doing a few trades a few years back, I had no idea about the industry. What did I do? Started trading with my money. Used any exchange I could find (centralized or decentralized) & started doing different types of trades. To be fair, my boss here is fantastic & he helped me a lot with understanding the market. But the point is that I could understand the market fairly quickly & try to predict where it can go which helps me even today!

Fundamentals-Focussed Team

While I have not been a “people leader” in any of my roles, a big part of my job has been to help my team perform at their potential by providing technical leadership. My entrepreneurial journey had taught me a lot about people’s motivations & I had built instincts to figure out what makes people tick. I used it to my advantage in each of my roles. As I mentioned earlier, whenever I spoke with a team member—whether a direct report, a peer, or even someone outside my immediate project, I started the conversation by clarifying the problem we were trying to solve. It sounds simple, but I’ve found that when everyone clearly understands the “why,” they naturally become more invested and engaged. By consistently returning to questions like “What’s the core problem?”, “Is there a simpler solution at the core?”, I helped create a team culture that values deep thinking over quick fixes. That’s a trait I carried over directly from my startup days. When you’re a founder, you often can’t afford to overlook the basics. This allowed me and my teammates to connect the dots between the problem at hand and the broader business context, making our work feel more meaningful and strategic. Additionally, I applied the same principles while writing code or giving feedback to other engineers on their code - which helped us get to more elegant solutions that we would not have built otherwise.

Closing Thoughts

Looking back on my journey from founder to employee, one thing is clear: my entrepreneurial superpowers - customer empathy, market awareness, and a fundamentals-focused approach didn’t need to be shelved the moment I joined a larger org. Instead, with a few tweaks, they became some of my biggest assets, helping me stand out and add value in ways I hadn’t fully anticipated. Lastly, if you are an entrepreneur looking to make a similar change or have made this change in the past, I would love to talk to you & get your thoughts. This is not something a lot of people have talked & I want to change that. Please reach out to me at @mrdhat and I’d love to buy you a coffee.

Hi 👋 I am Akshay

Sun, 29 Dec 2024 16:12:01 +0400

I’m an engineer with a passion for building things and seeing how they grow. I’ve spent over 10 years in tech, with almost 7 of those as an entrepreneur. Engineering, to me, is more than just a job - it’s an art form, a way to solve problems and create something meaningful. After running startups, including one that got acquired, I’ve moved into product development roles at some exciting companies. Along the way, I’ve learned how to combine my technical skills with the lessons from entrepreneurship to create real impact. I am currently working at Intercom, on their Datatores team.

When I’m not working, I love to travel with my wife and explore new destinations. Fun Fact: we once packed up, gave up our house, and spent a year traveling as digital nomads through places like Thailand, Vietnam, Cambodia, Austria, Italy, Croatia and Spain. I recently moved to Dublin, after spending a short (but fun!) year in Dubai.

I’m known as mrdhat everywhere on the internet. If you’d like to reach out to me, I am at i(at)akshay.co.

From Entrepreneur to Employee: A Journey of Transition and Growth

Sun, 29 Dec 2024 15:58:20 +0400

Around 3 years back, after spending seven years as an entrepreneur—I found myself at crossroads. Having built startups, one of which was acquired, I decided to step away from the rollercoaster of entrepreneurship to explore what being an employee is like. This transition wasn’t just about changing roles; it was about navigating a shift in mindset, skillset, and priorities.

Why I Made the Transition

The decision to move from entrepreneurship to employment was driven by two key factors. First, I wanted financial stability. Starting a new life after getting married, I yearned for a role that allowed me to focus on my family without the constant uncertainties of running a business. Second, I wanted to learn. My startups were modest in scale—not runaway successes. I was curious about how larger organizations tackle challenges, build products, and scale operations.

At Postman, for example, I joined as a technical lead for a new product that had already achieved its MVP stage. I was eager to see how a company like Postman, known for its rapid growth and innovation, managed the process of launching new products. Were big companies as slow and bureaucratic as they were rumored to be, or could they actually execute quickly and efficiently? I wanted answers, and this role gave me the chance to find them.

First Impressions: The Entrepreneurial vs. Corporate Experience

When I moved from running my own business to joining a corporate job, I wasn’t sure what to expect. Could I adjust to a structured environment after making all the decisions myself? This change wasn’t just about a new role—it was a whole new way of thinking.

One of the starkest realizations I had during this transition was the difference in impact. As an entrepreneur, every decision I made—whether it was engineering, business, or hiring, directly affected the lives of my customers and team. The creativity I could apply to solving problems was boundless, and the sense of ownership was unparalleled.

In contrast, as an employee, especially at larger companies, the scope of influence felt significantly narrower. Opinions from roles like SDE3 or SDE4 often don’t carry as much weight in strategic decision-making. The vision typically comes from the top, and your role is to execute it. While there is room for creativity in engineering decisions, it is limited compared to the freedom of entrepreneurship.

That said, both roles require unique skillsets. As an entrepreneur, you are your own boss, setting the vision and figuring things out independently. While I thought this would translate seamlessly into corporate roles, the reality was more nuanced. My entrepreneurial skills helped in certain areas but didn’t always have the impact I had hoped for.

When I think about how my previous entrepreneurship experience helped me in my corporate role, a specific moment comes to mind, where my entrepreneurial mindset made a difference. I noticed that the project wasn’t aligning with customer values—something I’d learned as an entrepreneur could be a death trap. Drawing from my experience, I made the case for tweaks that would prioritize the customer’s needs. This intervention shifted the project in the right direction, reinforcing the value of my background even in a corporate setting. There were a few more instances like this. I will hopefully write more about that later.

The Emotional Side of Transitioning

Adapting to a role with less autonomy was one of the hardest parts of this journey. As an entrepreneur, I was used to making all the decisions; suddenly, I was in a role where my influence was limited. At times, it felt like wearing the “Chains of Olympus” — bound by the constraints of hierarchy and process.

Yet, there were moments of liberation. For the first time in years, I could focus solely on building, free from the pressures of fundraising, hiring, and running the business. This duality—feeling both constrained and relieved, was a constant during my transition.

One of the biggest adjustments was recognizing that my role in a corporate job required more focus and specialization. As an entrepreneur, I was used to wearing multiple hats—handling strategy, execution, and team management all at once. In a larger organization, I had to embrace the value of collaboration and trust in others’ expertise, which was both humbling and liberating. This shift taught me to channel my adaptability and decision-making skills into areas where they made the most impact.

A Work in Progress

My journey from entrepreneur to employee is far from over. While the transition has been challenging, it has also been rewarding. I’ve gained new perspectives, honed my skills, and learned to adapt to environments where my impact is less direct but no less significant.

For those considering a similar path, my advice is simple: embrace the change. Understand that the skills you’ve gained as an entrepreneur—resilience, problem-solving, and creativity are invaluable, even if their application looks different in a corporate setting.

This transition is a work in progress, but it’s one I’m committed to mastering. After all, growth lies in stepping out of your comfort zone and exploring new ways to create value.