The Promotion Metric That Isn't on Your Performance Review

Why I proactively gave a young programmer a raise and promotion

Author: SamDeepThinking Tags: Backend, Programmer, Java

Over the past two years, I promoted a junior developer on my team to mid-level, gave him a raise, and his year-end bonus was also much higher than before.

Many people often ask:

What exactly does a leader look at when promoting someone?

I don't want to talk about vague terms like responsibility, execution, or ownership.

I'll just tell a real case.

Look at what this young man did that made me proactively fight for his promotion and raise.

---

He joined the team in 2024.

When he first started, like most managers, I assigned him some relatively simple requirements.

I have a habit. I record all task assignments for the team.

I've been recording from 2024 until now. Who was responsible for each requirement and how it was completed can basically be traced.

The first task he received was:

Support a cancel function for store material loss reports.

The core code he submitted at the time looked roughly like this:

/**
 * Cancel loss report
 */
public void cancelLossesDocs(CancelLossesDocsCommand command) {

    LossesDocsAggregateRoot root =
        LossesDocsRepository.findRootById(command.getDocsId());

    if (Objects.isNull(root)) {
        throw BusinessException.of(
            ErrorEnum.PARAM_INVALID_VALUE.getCode(),
            "Loss report does not exist!"
        );
    }

    if (!newSystemGrayProperties.isDocsCancelFlag()) {
        throw BusinessException.of(
            ErrorEnum.AUTH_FAIL.getCode(),
            "Store {" + root.getShopName() + "} has not yet launched this feature!"
        );
    }

    // 1. Cancel document
    root.cancel(command.getUserName());

    // 2. Sync to inventory center
    this.syncToStockCenterCancel(root);

    // 3. Update database
    LossesDocsRepository.updateStatus(root);
}

The first time I saw it, I felt great. Not because of any advanced technology. But because the structure was very clear.

Validate parameters, execute business logic, sync inventory, update database. The entire flow is clear at a glance.

Over the years, I've encountered many young programmers. Those with about two years of experience who can write code this clean are actually not that common.

So I casually asked him two questions.

• First: If the document cancellation succeeds, but the call to the inventory center interface fails, how do you handle it?
• Second: If the inventory center cancellation succeeds, but the database update fails, what then?

His answer that year was:

The first problem doesn't exist. Because this uses a DDD approach, root.cancel() only modifies the state of the in-memory object and does not immediately update the database. The actual data persistence happens in the last step. So there won't be a situation where the business logic has been committed but the database hasn't been updated yet.

For the second problem, the database update is based on the primary key, so under normal circumstances it won't fail. Unless the database itself has a failure.

This answer was okay at the time. It showed that he understood the code he wrote and didn't just piece it together from a template.

Of course, I still gave a suggestion. When syncing to the inventory center fails, it's best to provide a compensation mechanism or a retry tool. This makes subsequent troubleshooting and recovery much easier.

---

Later, this feature went live. It has been running until now with almost no changes. The stability is very good.

Next, I assigned him some similar tasks one after another.

The results were all similar:

• Stable delivery quality;
• Very few bugs;
• Quick response when problems occurred;
• Positive attitude.

For a manager, this is actually a very important signal.

Because only when simple tasks are consistently done well do you qualify to take on more complex things.

---

Later, I decided to increase the difficulty for him. I gave him a project involving integration with a third-party system.

The business was roughly:

After a store places an order, it needs to be synced to an external system, which is responsible for delivery to the store.

From requirements review and technical solution design to development and launch, he was fully responsible. At the same time, I pulled him into the communication group with the third-party technical team. Let him be directly responsible for communication.

Anyone who has done third-party system integration knows. This kind of project is much harder than ordinary requirements.

Because the third party is uncontrollable.

Many problems are not caused by your own code. You must consider various abnormal scenarios in advance.

At the time, I only gave a few directional suggestions:

• Monitoring and alerting must be in place;
• Fully consider stability and exception flows;
• Go over the technical solution with me first.

I let him handle the rest mostly on his own.

---

Later, something happened that left a particularly deep impression on me.

The solution proposed by the third party was:

Batch sync orders via scheduled tasks.

And he directly raised an objection during the solution review. His reasoning was simple.

This third-party company serves many brands simultaneously. If all clients push orders centrally via scheduled tasks, their system could easily have problems during peak times.

Ultimately, it would affect us.

His suggestion was:

Change to real-time sync.

Generate one order, sync one order. One success counts as one.

After I learned about this, I immediately supported his solution.

And required the third party to add an order cancellation interface. We push orders in real-time on our side, while also supporting real-time cancellation.

This incident gave me a new understanding of him. Because from that point on, what I saw was no longer just someone who could write code. But someone who thinks about the overall stability of the system.

Many developers, even at this stage, still just execute requirements. Whatever others say, they do.

But he had already started to think independently:

Is this solution reasonable? Is there a better way? Will there be problems in long-term operation?

This ability is very rare.

---

By 2025. I formally nominated him for promotion to mid-level developer, while also giving him a 2,500 yuan raise and a performance rating of A.

Because in my view, he already possessed the capabilities a mid-level developer should have.

---

And by 2026.

I had already started assigning some large modules directly to him.

For example:

• Store scheduling system;
• Store material production estimation system;

From design to implementation, he basically pushed forward independently. I rarely intervened in the implementation details anymore. The results were also done well.

---

So back to the original question:

What exactly does a leader look at when promoting someone?

My answer is: It's not about how many technologies you know. Nor is it about whether you are usually good with words. It's about whether you can continuously take on responsibilities greater than your current position.

Do simple tasks well, and you get more complex tasks. Do complex tasks well, and you get bigger projects. Do projects well, and you get even bigger systems.

When a leader finds that:

You can always handle things slightly beyond your current ability.

Then promotion, raises, and more opportunities are often just a matter of time.