In the past two years, I promoted a junior developer in the team to a mid-level developer, and at the same time increased his salary, and the year-end bonus was much higher than before.

Many people often ask:

What does a leader look for when he promotes a person?

I don’t want to talk about general terms, such as sense of responsibility, execution ability, sense of ownership and so on.

Let me tell you a real case directly.

Look at what this young man has done, let me take the initiative to get him a promotion and a raise.

He joined the team in 2024.

When I first joined the company, like most managers, I first arranged some relatively simple needs for him.

I have a habit. I will record all task assignments of the team.

From 2024 to now, who is responsible for each requirement and how it has been completed can basically be traced.

The first task he received was:

Store material loss reports support the cancellation function.

The core code he submitted at that time was probably like this:

/**
 * Withdraw 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() + "}This function has not been launched yet!"
        );
    }

    // 1. Document cancellation
    root.cancel(command.getUserName());

    // 2. Sync Inventory Center
    this.syncToStockCenterCancel(root);

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

When I saw it for the first time, I felt very cool. It's not because of any advanced technology used. It's because the structure is very clear.

Verify parameters, execute business, synchronize inventory, and update database. The entire process can be understood at a glance.

I've met a lot of young programmers over the years. After working for about two years, there are not many people who can write code so cleanly.

So I asked him two questions.

  • The first one: What should I do if the document cancellation is successful but the call to the inventory center interface fails?
  • Second: The inventory center was canceled successfully, but the database update failed, what should I do?

His answer back then was:

The first problem does not exist. Because the writing method of DDD is used here,root.cancel()It only modifies the memory object state and does not update the database immediately. The real data persistence comes in the last step. Therefore, there will be no situation where the business has been submitted but the database has not been updated.

As for the second question, the database update is based on the primary key and will not fail under normal circumstances. Unless the database itself fails.

This answer was OK at the time. It shows that he understands the code he wrote and did not spell it out according to a template.

Of course, I still gave a suggestion. When synchronizing the inventory center fails, it is best to provide a compensation mechanism or a re-pushing tool. This will make subsequent troubleshooting and recovery much easier.

Later this function was launched online. It has been running until now with almost no changes. The stability is very good.

Next, I successively arranged some similar tasks for him.

The results are similar:

  • Delivery quality is stable;
  • The number of bugs is very small;
  • Respond quickly when problems arise;
  • Have a positive attitude.

For managers, this is actually a very important signal.

Because only if you continue to do simple tasks well will you be eligible for more complex things.

Later I decided to make it more difficult for him. I gave him a project involving third-party system docking.

The business is probably:

After the store places an order, it needs to be synchronized to the external system, which is responsible for delivering it to the store.

From requirements review, technical solution design, to development and launch, he is responsible for everything. At the same time, I pulled him into a docking group with the third-party technical team. Put him directly in charge of communication.

Anyone who has done docking with third-party systems knows this. This kind of project is much more difficult than ordinary requirements.

Because the third party is uncontrollable.

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

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

  • Monitoring and alarming must be in place;
  • Give full consideration to stability and abnormal flow;
  • Talk to me about the technical solution first.

The rest was basically left to him to advance on his own.

Then something happened that left a particularly deep impression on me.

The solution given by the third party is:

Synchronize orders in batches through scheduled tasks.

And he directly raised objections during the plan review. His reason is simple.

This third-party company serves many brands at the same time. If all customers push orders centrally through scheduled tasks, their systems are prone to problems during peak periods.

It will eventually affect us.

His advice is:

Change to real-time synchronization.

When an order is generated, an order is synchronized. Every successful order counts.

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

And require third parties to add order cancellation interfaces. We push orders in real time and support real-time cancellation.

This incident gave me a new understanding of him. Because from that time on, I saw more than just a person who could write code. But someone who thinks about the overall stability of the system.

When many developments reach this stage, they are still just executing requirements. He does what others say.

And he has begun to take the initiative to think independently:

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

This ability is very rare.

By 2025. I formally nominated him for promotion to mid-level development and gave him a salary increase of 2,500 yuan and a performance rating of A.

Because in my opinion, he already has the capabilities that intermediate development should have.

And by 2026.

I've started putting some of the larger modules directly in his hands.

For example:

  • Store scheduling system;
  • Store material production estimating system;

From design to implementation, he basically promoted it independently. I rarely interfere with implementation details. The results are also well done.

So back to the original question:

What does a leader look for when he promotes a person?

My answer is: It doesn’t depend on how technical you are. It doesn’t depend on whether you are good at talking. It depends on whether you can continue to take on greater responsibilities than your current position.

The simple tasks are done, and more complex tasks are given to you. The complex tasks are done, leaving you with bigger projects. Once the project is done, we will give you a larger system.

When the leader discovers:

You can always do things that are slightly beyond your capabilities.

Then promotions, salary increases, and more opportunities are often just a matter of time.