Home on George Cherenkov

Engineering Organization

Mon, 01 Jan 0001 00:00:00 +0000

Engineering organizations become hard to operate when the formal structure and the real flow of work diverge.

I usually start by looking at where decisions are made, who owns outcomes, where work waits, and which problems require informal heroics to keep moving.

The goal is not to install a process. The goal is to make the organization understandable enough that people can make decisions without constant escalation.

The Expensive RAM Optimization

Mon, 01 Jan 0001 00:00:00 +0000

An async image-import worker consumed significant memory.

The local technical answer was plausible: rewrite it in a runtime with better concurrency and lower memory overhead.

The broader cost was larger than the infrastructure problem:

several engineers spent months rewriting;
the team had no prior production experience with the new stack;
the old implementation still needed support during migration;
infrastructure savings were small compared with engineering cost and opportunity cost.

total technical cost =
infrastructure
+ engineering time
+ delivery delay
+ operational burden
+ opportunity cost

The lesson is not “never rewrite”. The lesson is that a technically better runtime still has to earn its organizational cost.

Technical Leadership

Mon, 01 Jan 0001 00:00:00 +0000

A technical leader is not just the person who can solve the hardest task alone.

The useful question is whether the person increases the capability of the team around them: clarifies trade-offs, creates decision boundaries, raises engineering judgment, and reduces dependency on themselves over time.

This is why a middle engineer with ownership instincts can sometimes become a better lead than a senior engineer who remains the central escalation point.

How to Find a Lead in Your Team

Wed, 16 Sep 2026 00:00:00 +0000

The question is often framed like this:

Who should we promote to Team Lead?

I would start with a different question:

Who is already acting as a leader — and what kind of leadership are they actually providing?

Leadership often appears before the title does. You can appoint someone as a manager, but you cannot make them an authority by decree. And the opposite is also true: someone may have no Lead in their title, yet the team still waits for their opinion, invites them into difficult discussions, and trusts their judgment.

Hiring and Evaluation

Mon, 01 Jan 0001 00:00:00 +0000

Hiring breaks when interviews select for the wrong signal.

Confidence is not seniority. Familiarity with a technology is not ownership. Memorized architecture patterns are not system design judgment.

Good evaluation should expose how a person thinks under constraints: what they simplify, what they escalate, what risks they see, and what they intentionally choose not to solve yet.

Architecture Decisions

Mon, 01 Jan 0001 00:00:00 +0000

A technically correct architecture can still be a bad decision.

Architecture decisions have a blast radius: delivery time, team skills, operational burden, migration cost, reliability, compliance, and future ownership.

Good architecture is not the most advanced design. It is the design whose cost, timing, and ownership model make sense for the organization that must build and operate it.

Change and Transformation

Mon, 01 Jan 0001 00:00:00 +0000

Reasonable changes fail when the organization cannot absorb them.

Resistance is data. It may expose budget limits, hidden commitments, compliance constraints, leadership misalignment, staffing gaps, or risks that were invisible from the outside.

I look for the adjacent layers that can make a change viable, then reduce the change to something the organization can actually adopt.

Progressive System Design Interview

Fri, 11 Sep 2026 00:00:00 +0000

System Design interviews are supposed to test engineering judgment.

Too often, they test something else: whether a candidate has seen the same architecture diagram as the interviewer.

“Design YouTube.”

“Design Uber.”

“Design Twitter for one billion users.”

A few minutes later, the whiteboard contains Kafka, Kubernetes, object storage, several databases, CDN, queues, caches, multiple regions, analytics pipelines, and enough infrastructure to keep several platform teams busy.

The architecture may even be technically correct.

About

Mon, 01 Jan 0001 00:00:00 +0000

My name is George Cherenkov.

I have worked in engineering environments ranging from small teams to large, multinational enterprises, contributing as an individual engineer, leading teams, and working within complex, multi-team delivery structures.

My responsibilities have also included coordinating software delivery involving around 50 people and leading a product engineering department of 30–40 people. In the latter role, I was responsible for the department’s people, hiring, compensation, budgets, delivery processes, architecture, infrastructure, and technical operations.

Page not found

Mon, 01 Jan 0001 00:00:00 +0000

The page does not exist or has moved.

Return home.