About
Engineering Manager · Distributed Systems · High Traffic
I'm Sertaç. I have been in this industry for twenty years. I started out writing code; today most of my job is designing high-traffic systems and growing the teams that build them. The most durable thing I learned along the way is this: most technical problems turn out to be team problems, and most team problems turn out to be communication problems.
Twenty years is a long time, and I have spent it in domains that look nothing alike: e-commerce, defence, automotive, retail and finance. Each has its own kind of pressure — a traffic spike at the hour a campaign starts, latency measured in milliseconds, confidentiality and process discipline, stock consistency, or integration with dozens of legacy systems.
What working in so many different places taught me was the opposite of what I expected: the problems repeat. Tools, languages and industries change, but systems keep breaking in the same places — two writes happening at once, a queue left unbounded, a dead service that looks healthy, and an assumption nobody said out loud. Most of the posts on this site are about exactly those recurring places.
Where I come from
The turning point in my career was a job that started as a one-person project at an enterprise customer. I was the only developer, there was one project, and we met the customer once a month. What I heard at the first delivery still sticks with me: "It works, but this is not how we do it."
After that I changed exactly one thing — I put the customer in front of a real screen every two weeks. Four years later, 1 project had become 9 and a team of 1 had become 14, and I had not prepared a single sales deck for any of the new work; all of it came from the people using the product advocating for us inside their own company. I wrote up that whole experience here.
Today I work mostly on high-traffic infrastructure: streams carrying tens of thousands of messages a second, real-time data processing, and how distributed systems actually behave under load. The one-line lesson from this domain: average latency lies, the tail does not.
What I focus on
Correctness in distributed systems
Concurrency, delivery guarantees, idempotency and locks. In other words, the things that look fine and break under load.
Staying up under load
Scaling is a capacity solution, not a performance solution. Measure where the bottleneck is before you move it.
Building and growing teams
Hiring, seniority, feedback, and what breaks along the way from a team of 1 to a team of 14.
Fitting process to the team
Running Scrum against the team's real problem rather than the book. The number of ceremonies is not a measure of agility.
Working with AI
Writing code got cheap, verifying it got expensive. Building the rituals for that in a team, and protecting the junior learning path.
Leaving the reasoning behind
Six months later, the person asking "why did we build it this way?" is usually you. Writing the answer down is the cheapest investment there is.
What I write here
This site is a set of notes on things I ran into in the field. I try to write about how something that looks good in the book actually behaves — and where it breaks. Under three headings:
- Scrum and process — what each ceremony is for, how it breaks, and what to do differently tomorrow morning.
- Team leadership — hard conversations, performance, and what replaced authority.
- Engineering — concurrency, distributed systems, messaging, scaling; all with real incidents and code.
Every post ends with a checklist. If you are in a hurry, read only those and share them with your team; that is usually the part that actually gets used.
I do not write about things that have not happened to me. Every incident in these posts is real, the numbers are real, and so are the mistakes. I also write about the things that turned out not to work — those are usually the more useful ones.
Get in touch
If you disagree with something here, have a correction, or have lived through something similar, I would like to hear it.