Ten Years On, We Set Off Again: My Journey with TiDB

From day one, PingCAP has been a company built by and for builders. In this special 10-year reflection, our very first employee and SVP of Product & Engineering shares the raw, unfiltered journey behind TiDB—from the first lines of Go code to running mission-critical workloads across the globe. We hope this inspires the next generation of open-source dreamers.

Acknowledgments

This article was spoken by me, transcribed by ChatGPT, and then shaped into prose with GPT-4.5. I guess the model caught a bit of my style; I only did light edits. AI is getting insanely good. In the next decade TiDB will have many more AI stories—but that’s for another time.

The Most Valuable Treasure in Life? Memories and Reflections

Time flies, and ten years have passed. It all started on April Fools’ Day, 2015, when Max asked me—very seriously—if I’d like to start a business together. That conversation was the ticket that put me on this wild ride called TiDB. It’s been full of ups and downs, but also full of exciting adventures.

Over the last decade, I’ve witnessed TiDB grow from a tiny open-source project into a global phenomenon. At this milestone, I’d like to share my genuine experiences and reflections—not to brag or gloss over the difficulties—but to honestly recount how:

• A simple technical ideal gradually became reality.
• Programmers painfully yet necessarily transformed through product commercialization.
• Open source and customer success became our core values.
• Technology and products won global customers’ trust.
• I evolved from a programmer to a manager, then a technical leader.

I believe these real stories have the most value, and they deserve to be told.

Enough of the introduction—let’s dive in!

1. The April Fools’ Day Invitation

A Startup Invitation on April Fools’ Day

April 1, 2015, April Fools’ Day. Programmers usually take it lightly, joking around carefree. But I got an utterly surreal message from Max, whom I knew only through open-source collaborations:

“We’re starting a company to build an open-source distributed database. Wanna join?”

My first reaction? “Are you kidding?”

Max quickly replied, “I’m dead serious.”

Why Me?

Turns out, open source connected us deeply. Collaborating via GitHub, we built mutual trust without ever meeting face-to-face. Open-source was like a programmer’s “dating platform”—far more effective than coffee dates.

Two Mind-blowing Ideas: Open Source and Remote Work

Despite initial skepticism, Max’s vision sounded surprisingly legit—an open-source distributed database aimed to “change the world.” It sounded crazy, especially considering we had no experience building databases.

Initially, I declined since the company was in Beijing, and I lived in Zhuhai. But Max shocked me by saying, “You don’t have to come to Beijing; work remotely.”

Remote work in 2015? Revolutionary. This company was either doomed or destined for greatness.

First Meetup Felt Like Old Friends

I booked a flight immediately, met Max, Ed, and Dylan—and bizarrely, felt like meeting old friends, all thanks to our shared open-source experiences. Open-source became TiDB’s DNA and a major competitive edge globally.

Radical Transparency and “True Open Source”

From day one, we decided on radical transparency. All our code, bugs, and discussions were publicly on GitHub. Skeptics worried customers would be scared off by visible bugs. But transparency built deeper trust.

Why a Distributed Database?

Our initial goal was simple: end the pain of sharding in MySQL. We wanted an infinitely scalable database to save programmers from sharding nightmares. This genuine pain point became TiDB’s key strength.

Ignorance is Bliss: A Programmer’s Adventure

Ironically, our inexperience in database development helped. Without knowing better, we jumped into this wild adventure fearlessly. I became PingCAP’s first official employee, beginning a thrilling decade-long journey.

2. Those Blissful, Code-Driven Days

When is Building a Product the Most Fun?

Engineers love to ask deep questions like, “What’s the best part of coding?” For me the answer’s easy: before a single customer shows up.

When nobody’s using your stuff yet, life is sweet. You write code all day, no angry tickets, no “ASAP” calls at 3 a.m., no fire-drills. It’s pure, undiluted hacker joy.

Sadly, that bubble pops the moment real users arrive—and it has to, because software exists to be used.

Starting a Database from Scratch? We’re not that Crazy

Kicking off TiDB felt a little wild—databases are not exactly weekend projects.

But we weren’t leaping blindfolded. Google had already published papers on things like Spanner, and CockroachDB (a.k.a. the “roach”) had launched a year earlier. Even good old HBase offered lessons.

Re-inventing wheels isn’t shameful—reinventing them with your eyes closed is. We stood on those giants’ shoulders and borrowed the parts we knew would work.

Why Go?

First decision: pick a language. Zero hesitation—we went with Go.

Why? Because it’s the one we knew and loved. In unfamiliar territory, the safest bet is the tool you wield best.

Strategy: get something running first, polish later.

MySQL Compatibility—Blessing and Curse

Early on, we vowed to speak MySQL. That bet later made TiDB the drop-in MySQL replacement people wanted.

But wow, did we step on landmines:

• MySQL’s… “creative” syntax edge-cases
• Quirky, undocumented compatibility gotchas

It’s a double-edged sword, but on balance the wins beat the pain.

The “so simple it hurts” Optimizer and Executor

Nowadays, TiDB has a fancy cost-based optimizer, but back then none of us had written one before. So we did the programmer thing: shipped the dumbest rule-based optimizer possible. The executor? Straight-up Volcano model—operators call next() down the stack. Ugly, but it worked.

Being clueless and fearless let us ship a first usable build fast.

Test-driven or Bust

From day one we lived and died by tests. Databases hold people’s data—mess that up once and you’re out of a job.

At one point, we chased 100% test coverage. Nuts, but it caught buckets of bugs.

On top of unit tests, we went hardcore:

• Ported SQLite’s gigantic sqllogic tests. Painful then, lifesaver now.
• Learned just enough Clojure to run Jepsen and flush out nasty transaction bugs.
• Wrote TLA⁺ specs of core algorithms so we could actually sleep at night.
• Dove into chaos engineering, built our own tool, which morphed into the open-source hit Chaos Mesh.

Rust, TiKV, and Dodging the C++ Black Hole

Next up: storage engine. C++? Nope—too hairy, impossible for staff. Just as Rust hit 1.0, we jumped.

Rust perks: speed, memory safety, “if it compiles, it probably works,” and a buzzing community that flocked to TiKV. Rust pains: glacial compile times and a near-empty ecosystem—lots of wheels to forge.

And yes, we named our data shard “Region.” Cloud vendors also call datacenters regions, so every customer call turns into “which region do you mean?” Lesson learned: names matter.

Borrowing from Spanner, Living without Google’s Toys

We copied plenty from Spanner, but our customers ran on plain-ol’ data centers—no TrueTime, no Colossus.

So we settled on a shared-nothing design. Perfect then, but cloud era hits differently, and TiDB is shedding that baggage bit by bit.

TL;DR—the Golden Hacker Age

Looking back, those early TiDB days were the golden era:

• Heads-down coding every day—simple, happy.
• New technical dragons to slay nonstop—massive dopamine hits.
• Raw passion pulled in a crew of like-minded hackers.

All that groundwork set us up for everything that followed.

3. Commercialization: How Do We Keep the Lights On?

Brutal Question: “Where are the customers?”

Back in TiDB’s early dev days we were bathing in tech‐driven bliss, and almost no one sat down to face the soul-searching question:

“How are we actually going to make money?”

Cranking out awesome code felt way more urgent than figuring out revenue. Plus, most programmers have a streak of idealism—words like “commercialization” or “profit” sound tacky.

Reality, though, is reality. A company isn’t a charity; no cash, no future. The earlier you nail where the customers are and why they’ll pay, the fewer beatings you’ll take later.

Looking back, I seriously regret not asking those questions sooner. Thinking about customer needs earlier would’ve helped both the company and my own growth.

The Painful Pivot from Tech-self-high to Customer-first

Hardest mindset shift for an engineer? Moving from “tech-driven” to “customer-driven.”

Our biggest smack-in-the-face came from that mindset. TiDB once shipped with a parameter default set to false: killer performance, but possible data loss on crash. In 2.0 we “sensibly” flipped it to true.

Tiny flag, massive fallout—some OSS users upgraded, performance tanked, businesses fell over.

The obvious fix (keep old default for upgrades, new default for fresh installs) never crossed our minds because we were still high on “technical elegance” and didn’t think about real-world usage.

Every repeat of that mistake screamed the same lesson:

“Design around the customer’s reality, not your own tech ego.”

Painful Lesson: Game-launch Face-plant

Worst bruise ever: a global game studio picked TiDB. Launch day, a single hot SQL key nuked the cluster. We watched it crash in real time—zero recourse.

In hindsight, had we:

• Reviewed their SQL early;
• Shipped hotspot-splitting tools in advance;

the disaster might’ve been avoided. But there’s no “if” button—the launch failed. The takeaways:

• Real workloads are gnarlier than we imagine.
• Databases are equal parts tech, delivery, and support.
• Always respect the customer’s business.

After that, we swore off blind tech swagger.

Bank go-live: the Turnaround Milestone

Luckily, we soon got a redemption shot—a core-system revamp for a bank. This time we went all-in pragmatic:

• Walked through every business rule with the client;
• Pre-reviewed every possible trap;
• Filled capability gaps on the spot;
• Built belt-and-suspenders launch and rollback plans.

Result: flawless rollout, huge client praise. That win flipped us from “tech-driven” to “customer-success-driven.”

“Only the customer gets to say if a product is good. When the customer wins, the product wins.”

The Long Road from Tech Love to Real Business

Truth: moving from tech-first to truly commercial and customer-first is a long, painful haul—and we still have tech-driven quirks.

But database work has taught us:

• It’s not just code; it’s an entire service stack.
• Quality, delivery, support, after-sales—all matter.
• Customer success is the ultimate scoreboard.

Mini-wrap: Making Money ≠ Selling Out

Dear engineers:

“Getting paid isn’t dirty; a customer paying you is the highest praise your code can get.”

Code exists to create value. Clients win, company wins, and we devs realize our own value.

4. The Power (and Weight) of Scalability

From Complaints to Liftoff: TiDB 3.0’s Turning Point

Early TiDB flashed the “distributed” badge, but performance was, well… meh. Clients griped: “Scaling’s cool, but this thing’s slooow.”

We knew we had to cross the perf threshold to earn trust. In 3.0 we rewrote critical paths with hardcore multithreading and got multi-X speed bumps.

Once perf cleared the bar, scalability became a super-weapon, and adoption exploded.

The Bike-lock Embarrassment

Bigger scale → more users → bigger blast radius.

One morning I scanned a shared bike; the lock wouldn’t open. Everyone around me was stuck. Turned out our TiDB cluster had crashed, freezing the whole fleet.

Nothing like torpedoing your own commute to realize:

“TiDB now sits in truly core production paths.”

Clients believe in TiDB’s scale; when we stumble, their pain is huge.

Midnight Full-disk Horror

Another vivid tale: a top internet client ran a 100 TB+ TiDB cluster. One night disks filled, TiKV crashed in loops, the system teetered. They pulled the fire alarm.

Problems:

• Deleting logs/trash was slower than incoming writes.
• Moving data created Raft snapshots—more disk burn.

We camped in their office till 4 a.m., finally:

• Slowed scheduler frequency to curb snapshots.
• Throttled writes so the cluster could breathe.

It worked, but the night drilled in:

“Scale raises the stakes. The more they trust us, the heavier the load we carry.”

Why Customers Boomeranged from Big-name Rivals

Overseas we lost deals to famous brands—then six months later those clients came back. Reason: the rival choked once real scale hit; TiDB kept humming at hundreds-TB, even PB.

That’s when we felt it in our bones: scalability isn’t marketing fluff—it’s a make-or-break requirement.

Growth Whiplash

Post-3.0, growth was so fast it bred overconfidence. Hidden quality debt piled up and later blew up—but that’s another story.

Mini-wrap: Scale is Both Sword and Burden

TiDB won hearts with scalability—and inherited massive responsibility. The deeper we sit in core systems, the less room we have for error.

“Scalability is our ultimate weapon—and a weight we have to shoulder.”

5. From Chaos to First Light (The Shift to Product- and Customer-Success-Driven)

The Pain of Shipping TiDB 4.0

Early TiDB grew so fast we slid into a messy, chaotic state. Exhibit A: the 4.0 release.

We clung to a “one big release per year” rhythm. Looked tidy on paper—inside it was mayhem: tons of new features jammed into each cycle, test time gutted, quality fell off a cliff.

After TiDB 4.0 dropped we had to crank out twelve patch releases just to steady the ship. Customer complaints hit an all-time high, our morale an all-time low.

I was waking up to pager pings at 3 a.m. and starting every morning by checking which client blew up overnight.

Eventually we told ourselves:

“Time to change the way we work.”

The Hubris of Having No PMs

Looking back, our biggest blunder was running almost the whole company with zero PMs.

Funniest part? We bragged, “Who needs product managers—devs are the best PMs!”

Yeah, no. That idea was spectacularly stupid.

Without PMs:

• No one managed feature priority
• No one thought about product strategy
• No one dug deep into customer scenarios

The result was a stew of random features, no clear direction, and lots of unsolved real-world pain points.

Bringing In PMs—The Tech-to-Customer Pivot

We finally faced the truth:

“Engineers can’t do everything; product needs dedicated owners.”

So we hired real PMs. Their impact was huge:

• Clear, ranked feature priorities
• Every release got a focus theme
• Shift from “tech coolness” to “solving customer problems”

Trust slowly crept back.

From “Yearly Big Bang” to “Two-Month Trains” to “Half-Year Releases”

The 4.0 fiasco taught us the risk of yearly drops. We switched to train releases every two months—quick iter- ation, bite-size changes, easier quality control.

New headache: too many versions; customers puzzled over which to run; bug fixes meant constant cherry-picks.

Final compromise: a six-month cadence—

• Stable enough, fewer branches
• Devs get breathing room to keep quality high

Quality-First Pivot: Starting with 6.0

Burned by 4.0, we made 6.0 all about quality:

• Big memory-usage rewrite—killed OOMs
• Systematic disk-IO jitter fixes
• Poured energy into stability over shiny features

Customer feedback after 6.0? Way better.

Cloud Era: Back to “One LTS a Year”

Then the cloud wave hit:

• We could roll new features to cloud users fast, get feedback early
• Once rock-solid, roll them into an annual on-prem LTS

Fast innovation + stable long-term branch = sweet spot.

Rethinking the Essence of a Database

We started asking:

“What is a database, really?”

Simple answer:

• It doesn’t need a bazillion fancy features.
• It needs to help users handle data simply, safely, reliably.

That mindset now drives TiDB’s roadmap.

Mini-Wrap: From Chaos to Product & Customer Success

The journey from disorder to product-driven clarity was long and painful, but we finally learned:

• PMs matter—hard.
• Quality beats everything.
• Small, fast steps + cloud feedback work.
• Never forget the core: we’re a data tool.

6. TiDB Cloud—A Rough but Rewarding Journey to the Sky

Cloud Misconception #1: “Just stick the DB on a VM, done!”

The TiDB Cloud story is long—and full of bumps. In the early days we thought:

“Cloud DB? Easy—spin TiDB up on the cloud. What’s so hard?”

Reality slapped us over and over: cloud database ≠ lift-and-shift.

It’s like your first brush with Kubernetes: “Just write a YAML and deploy, right?” Production shows it’s a hundred times messier.

Early-Stage Kubernetes Potholes

Way back in 2018 we decided TiDB Cloud would run on k8s. AWS had no mature EKS yet, so we naively picked an open-source project called Gardener and ran the clusters ourselves.

Nightmare:

• Gardener’s stability was trash; ops cost skyrocketed
• One engineer basically lived in pain every day
• It took years to migrate off Gardener onto managed EKS

Lesson carved in stone:

“In cloud, trust the cloud vendor’s pace of evolution.”

Local Disks vs. Cloud Disks: A Philosophy Flip

Worse, we were obsessed with local disks:

• “Local NVMe is fast—no way we’re using cloud disks.”
• We bent K8s in knots to schedule local storage nodes.
• Meanwhile, cloud-disk performance leapt forward and local-disk ops became a horror show.

As customers grew, local-disk ops alone could’ve killed us.

Looking back, it was pure:

“Developer perfectionism meets cloud-era reality, and reality punches.”

Ops in the “New World”: We Sell Service

Traditional software: ship bits, customer runs it.

Cloud service: customer buys the service:

• You own the SLA
• You plan maintenance windows
• Security & compliance must be airtight
• When a client’s down, you jump—period

Running TiDB Cloud taught us:

“Running service ops is ten times harder than writing software.”

But that pain forged a true cloud-native team.

Next-Generation TiDB Cloud: From Shared-Nothing to Shared-Everything

TiDB’s first design was shared-nothing—perfect for classic IDC deployments—but in the cloud it started to show cracks:

• If a node dies, we have to reshuffle data all over again.
• Scaling storage means adding physical nodes—crazy expensive.

So we kicked off a massive overhaul:

• Data moved from cloud disks to Amazon S3 object storage.
• The architecture shifted to a far more elastic shared-everything model.
• We broke the monolith into true micro-services, which boosted both scalability and agility.

People asked, “Won’t sticking data on S3 tank performance?” Short answer: nope—we layered in serious caching and optimized every access path. (A story for another day.)

The micro-service split paid off instantly:

• Heavy I/O jobs (like compaction) became stand-alone services.
• When load spikes, we scale out; when it drops, we shrink back fast—cloud bills plunge.

After the pivot, we finally found the right way to live in the cloud era.

Wrap-up: TiDB Cloud’s Tears and Tomorrow

Looking back, TiDB Cloud is equal parts heartache and harvest:

• Early cloud misconceptions cost us plenty of tuition fees.
• Every stumble—K8s choices, disk debates, micro-service cuts—pushed us closer to true “cloud wisdom.”
• Building a rock-solid ops culture turned us into a service-first team.

Today TiDB Cloud brings in more than half of company revenue—proof that cloud isn’t just the future; it’s the present.

The road’s been rough, but we’ve found our groove. And we’re sure TiDB Cloud’s best miles are still ahead.

7. The Road to Going Global — An Engineer’s International Challenge

Globalization: a Game of Trust

The first time PingCAP truly stepped onto the world stage we had to ask:

“Why on earth would customers around the globe trust a scrappy crew’s home-grown database?”

A database isn’t a random app—you’re asking people to hand over their crown-jewel data.

Trust isn’t handed out that easily.

Open Source, Our Biggest Global Ace

Luckily, TiDB was open source from day one, giving us a built-in edge:

• Folks can download the code and kick the tires themselves.
• When trouble hits they can pop the hood and read the source.
• The trust barrier drops dramatically.

One story I love: a Japanese payment company kept flattening AWS Aurora every time they ran a promo. They went code-hunting on GitHub, found TiDB, gave it a whirl, and never looked back. Today they’re one of the biggest payment users in Japan—and TiDB is a staple in that market.

Never underestimate the power of OSS.

Three Years Nonstop, TiKV Crashes, Yet We Grin

That same Japanese customer later filed a bug: “One TiKV node just died!”

We checked the logs:

“Uh… that node’s been up for three years straight.”

First shock, then pure joy—three years of uptime proved TiDB’s stability had hit a new level. The story became one of our favorite proof points with global prospects.

Later, when an AWS AZ in Japan suffered a big outage, their business layer took a hit but TiDB kept serving traffic. Trust skyrocketed overnight.

Donating to CNCF: Open Source is More Than Tossing Code Online

To boost TiDB’s global profile we did two big things:

1. Donated TiKV to the Cloud Native Computing Foundation—it’s now a graduated CNCF project.
2. Donated Chaos Mesh, our chaos-testing tool, to CNCF so anyone can hammer-test distributed systems.

Those moves leveled up our reputation and exposure worldwide.

Rust: the Unexpected MVP

Our early, gutsy choice to write TiKV in Rust paid off internationally:

• The global Rust scene is vibrant, so contributors flocked in.
• Foreign engineers pumped PRs, and the ecosystem blossomed.

TiKV turned into a Rust rock-star project, which quietly opened more overseas doors.

The Real Test: Localization or Bust

We once thought “going global” meant translating docs and flying a salesperson over.

Later we learned:

“The best globalization is localization.”

Cultural gaps are huge. No matter how slick your tech, botch local support and customers will roast you.

So we got serious:

• Opened engineering hubs in the US, Europe, Japan, and Southeast Asia.
• Rolled out 24/7 localized support.
• Hired native sales and pre-sales folks who genuinely grok local culture.

That’s how we built real global muscle.

The Computer History Museum Day-dream

In 2018 Ed and I roamed the Computer History Museum in Mountain View and joked:

“One day maybe TiDB will sit in these glass cases.”

If that ever happens it’ll mean TiDB has truly earned global respect.

That dream still fuels us.

Mini-wrap: from Coders to a Truly International Crew

Our global run has been rough but rich:

• Open source cracked the trust code.
• Rust and CNCF projects gave us street credit.
• Localization is the heart of internationalization.
• A worldwide team is the bedrock of customer success.

Today—with customers on every continent, we can finally say, proudly:

“TiDB is the open-source database trusted around the world.”

8. Customer Success—A Programmer’s Greatest Pride

What is Customer Success, Anyway?

Since day one at PingCAP, customer success has been the north star.

We coders used to believe:

“Shipping elegant, blazing-fast code is success.”

After a few years in databases, we learned the single yardstick:

Customer success.

If the customer’s business thrives because of our database, then—and only then—have we succeeded.

Customers are the Best Teachers

Why hammer on customer success?

Sure, customers paying us keeps the lights on.

But more importantly, we discovered customers are our best mentors:

• They understand the business domain better than we ever will.
• Their real-world pains push our tech forward.
• They drag us past limits we never imagined.

A North American client once had an engineering head who’d spent two decades on Spanner and Bigtable. His feedback leveled us up like crazy.

Pushing Boundaries: Importing a 50 TB Single Table

A different NA customer hit us with a wild request:

“Can you import a 50-terabyte single table?”

We thought they were kidding. Early attempts failed, tension rose, deadline threats flew.

We bled over the code, optimized everything, and nailed it.

Then another client swaggered in: “Cool—how about 100 TB?”

Thanks to the 50 TB battle scars, they got it done themselves.

We realized TiDB could tackle extremes we’d never dreamed of.

SaaS + One Million Tables: Customers Teach us Product

One leading SaaS outfit asked:

“Can TiDB handle one million tables?”

Jaw-drop moment. Regular OLTP setups never hit that.

But in SaaS each tenant has its own DB schema; millions of tenants = millions of tables.

We overhauled TiDB’s internals—schema layer, optimizer, memory footprint—and hit the mark.

Word spread; more SaaS vendors signed on. That single ask opened an entire market.

Should Engineers Support Customers? Absolutely

Early on we debated: “Should R&D directly support clients?” Many devs prefer quiet coding caves. We decided yes—devs must back customers.

We spun up the Customer Advocate program:

• Each key client gets a dedicated engineer.
• That engineer masters the client’s use cases.
• Any issue? They’re the first stop.

One engineer clocked 200+ meetings with a single customer in a year—nuts but priceless:

• Clients got expert care.
• Engineers soaked in real-world feedback.
• Customer loyalty soared.

That client is now migrating massive Aurora clusters over to TiDB.

The Value of Customer Success

In hindsight:

• Customers are the real experts.
• Live business beats white-paper designs.
• Only by living on the front line can we build the DB people actually need.

This ethos of customer success won us fans across the globe.

Mini-wrap: the Coder’s Proudest Badge

Switching from tech-driven to customer-driven wasn’t easy for a room full of engineers.

But once we did, we saw it:

“Customer success is a programmer’s greatest pride.”

Every thank-you, every ounce of trust, every business win—that’s our fuel.

TiDB stands where it does today because we keep that flame lit—and we’ll keep building only for one goal: our customers’ success.

9. My Ten-Year Growth: Metamorphosis from Coder to Tech Leader

A Decade as “First Employee”

Ten years ago I joined PingCAP as the very first full-time hire and lived through TiDB’s entire zero-to-one journey. The company’s turbo-charged growth yanked me through a massive personal transformation too.

I started as a pure, code-loving engineer; today I steer the whole R&D org. The ride has been equal parts challenge and reward.

First Management Lesson: Respect Conway’s Law

The first big principle I learned is Conway’s Law:

“The system mirrors the structure of the organization that built it.”

Build a good product? First design the right org.

Because TiDB is distributed, our org had to be distributed too—cue extra headaches:

• People spread across multiple regions—how do you keep comms tight?
• How do you kill info silos and keep teamwork humming?

We stumbled plenty at first, but slowly cracked the code for high-efficiency async collaboration.

The Art of Async: Code & Docs Beat Meetings

In a global, distributed team you can’t just book a meeting. We centered everything on GitHub, fully async:

• Every feature ships with clear docs.
• Every major design decision goes through an open design-doc review.
• Daily chatter lives in issues and pull requests.

Turns out that’s way more efficient than marathon Zoom sessions.

The Power of Terminology

At first we ignored terminology tooling. Chaos ensued:

• A single term meant different things in different teams and time zones.
• We wasted hours just untangling concepts.

I eventually led a terminology-standardization push. Once vocabulary aligned, comms sped up and teamwork smoothed out.

Level-up Challenge: from Team Lead to Head of Engineering

Climbing from IC to team lead was tough enough. Moving up to run multiple managers was a whole new beast:

• I had to delegate and trust.
• Culture and morale mattered more than solving every technical bug myself.
• I had to think about motivating my reports’ reports so the whole engine fired smoothly.

Soft-skill territory—way beyond raw tech chops.

Org Remake: Building a Product- and Customer-Success Culture

One giant takeaway:

• Culture beats process.
• And the heart of that culture is customer success.

We kept repeating in every meeting and review:

“Everything we do is for the customer’s success.”

Over time the whole org absorbed it:

We write code not for self-glory, but to nail real customer needs. Product quality—and client happiness—spiked.

Personal Reflection: What Makes a Real Tech Leader?

A decade in, I ask myself:

“What is a truly great tech manager?”

I used to think raw tech was enough. Now I know:

• Tech is table stakes.
• Communication, organization, empathy, and a customer lens matter just as much.
• A stellar tech leader codes, but also understands people, business, and clients.

That’s my single biggest takeaway.

Mini-wrap: the Next Decade is Just Kicking off

TiDB’s first decade took me from ordinary coder to leader in a global tech company.

I’ve witnessed the product go worldwide and watched myself morph from specialist to manager.

Today, I still feel that spark:

• I want to keep growing.
• I want to lead the team to even bigger wins.
• I want to become the best tech leader I can be.

Just like that first day at PingCAP:

“My next ten-year adventure is only beginning.”

10. See You in Ten Years—Onward to the Next Journey

So that’s the tale of TiDB and me over the last decade. Of course, ten years hold way more stories than I can fit here.

Looking back, we hit plenty of surprises and challenges, but so many more joys and growth moments—from Max’s April-Fools-day DM to TiDB becoming a globally known distributed database; from chasing tech perfection to locking onto customer success; from a simple startup dream to a cloud-era, worldwide product.

If I had to distill a few truths:

• Open source is a belief system—it won us trust fast.
• Product focus + customer success is the true growth engine.
• Scalability is more than tech; it’s the backbone of growth and client wins.
• Globalization is a mandatory quest—and an unforgettable culture trek.
• A programmer’s pride isn’t lines of code—it’s customers winning because of your work.
• Growing from techie to manager hurts—but teaches priceless non-code lessons.

TiDB clocked its first ten years, and my journey is just warming up.

I’m sure the next decade will bring fresh growth, new challenges, and an unshakable commitment to helping customers thrive.

Thanks to every customer, partner, and teammate who believed in us—you made this ride possible.

See you in ten more years!