3 Lessons I Didn’t Fully Understand in the Past

Feb 2026

Forever Grateful for the Writers that Helped Me Level Up

About four years ago, we were trying to build a product that processed streaming data in real time, with a unique MLOps strategy in place.

To deliver with a young team of engineers, we had to learn an enormous amount about different technologies.

I remember how we literally assigned research time to each person, betting on their ability to understand a tool, evaluate it, and translate it into something usable for our needs.

These included Kafka, Spark, MlFlow, Flink, Grafana, Prometheus and many more. We chose the open-source route, which meant building and maintaining everything in-house.

Looking back, I realize the value of three lessons I want to remember from that time.

These were things we did well, perhaps without even fully understanding why at the time.

1. Keep Your Users Happy

There is this wonderful quote from the book The Staff Engineer’s Path. Charity Majors, CTO of Honeycomb, says:

Nines don’t matter if customers aren’t happy.

"Nines" here refer to the service level objectives, a common mechanism for measuring system availability.

It’s tempting to report the performance of your work using what you can easily measure (SLOs, uptime, latency). But the details that take much longer to polish are often what make or break a product.

You have to understand what your customer is trying to achieve. What risks do they perceive? How can you offer risk reversal? You need to know what your claim is, not just from a product perspective, but in terms of how it improves their life or work.

2. Understanding and Taking Action.

As an engineer (or anyone who produces something), you’re always operating with incomplete information.

Jim Keller, the man behind Apple's A4/A5 processors and AMD's Zen architecture, explained this beautifully:

If you constantly unpacked everything for deeper understanding you'll never get anything done. If you don't unpack understanding when you need to, you'll do the wrong thing.

In our case, we had to learn the tools well enough to use them as intended, but not unpack them so deeply that we paralyzed ourselves.

Progress required balance.

3. Articulate the Problem Until the Sale Is Obvious

We worked on the product so deeply that customers were often shocked by how well we articulated their problems.

In a sense, the following is possible:

Articulate the problem so well that the customer is sold without even seeing the product.

When you go that extra mile for the people you’re serving, things change.

You can understand their pain so deeply that they think:

“There’s no way this person doesn’t know what they’re talking about. No one has described our issue with this level of detail before.”

Thanks to this approach, we eventually shipped something we were confident not only met expectations but exceeds them.

I hope these are useful to consider.

PS: In a way, this is a love letter to my team at that time. We should all write more of them! Grateful to have been part of a team with you, Özlem Er & Elif Altunok .