Why are technical KPIs needed

In business technology teams, there is a bad tendency for teams to become more businesslike and less technical. Everyone talks about business. At technical conferences they talk about business, at weekly meetings they talk about business, and in the weekly papers they write about business items…… The only thing less talked about is the technology itself. This is not to say that the business is unimportant, but that understanding the business and managing the business requirements is the base of the technical person, not the whole thing.

Price to pay

This lack of technical flavor is a great pity for the technical team, and is not conducive to the growth and development of technical personnel. Because it’s hard to imagine a team without technical aspirations developing a robust, maintainable, scalable system. The code stack, on the contrary, this business in the short term may be “fast” to achieve the needs of the business, but in the long run, this kind of rotten system increase greatly hinder the development of business, to form a black hole application (eat people don’t spit bones), and the engineer was enveloped in the business requirements and lousy between systems, struggling to cope with that.



This compromise leads to system corruption, mounting technical debt, and ugly code growing like a tumor that drains all your energy. As Robert C. Martin put it, “No matter how dedicated you are and how many hours you put in, you’re still stuck with a broken system because most of your energy is spent not developing requirements but dealing with chaos.”

As technologists, we can’t forget that our primary technical mission as technologists is to manage software complexity.

Failure of technical Leader

Our technical manager, our TL, is mainly responsible for this situation. To put it more seriously, is dereliction of duty at work, which is mainly reflected in two aspects, one is technical inaction, the other is business not thinking.

Technical omission

Now many technical students, once promoted to TL post, start to break away from technical work, just like a natural appearance. Imagine a TL that never pays attention to technology, never writes code, has no passion for technology, doesn’t learn about technology, and even sucks at technology. How can you expect a team under this TL to be technical? !

So when Ali vp of Technology Xuan Nan asked to see the amount of code development for P8 (I should give Xuan Nan credit for being pragmatic), it was simple and crude, but to some extent it did reflect the reality of many TL’s being out of technical work. It is also a clear signal that we need to return to the technology itself, because we do not need so many technical managers who are “high above” and “guiding the country”, but technical leaders who can really go deep into the system and code details and bring real changes to the team.



Business not thinking

Nowadays, many TL are busy in various meetings every day, doing all kinds of things, but do we really need so many meetings, so much communication?

It’s not that communication isn’t important, it’s just that we have too many meetings now, and in my personal experience, many of them are inefficient and pointless. So TL needs more independent thinking, not conformity.

Lei Jun said: “never try to use tactical diligence, to cover up your strategic laziness.” “That phrase is perfect for most PD’s (product managers), so I’d rather PD’s” do nothing “than go around and make a lot of worthless products. Because a lot of the complexity on the system is caused by these unproductive requirements.

Therefore, my advice to PD is that please understand the business deeply and think deeply. Do not degenerate into a PPT Designer and a microphone for business needs. Do not just write PRD and draw Demo, but plan products and solve business problems with systematic thinking, so as to win the respect of technical staff.

The internal cause of the technical staff’s fatigue is the lack of technical taste of the team analyzed above, and the external cause is mainly PD’s disorderly behavior.

Therefore, our TL must also think deeply about the business, strictly control the “customer demands” produced by PD YY, keep out these fake and worthless demands, and prevent them from encroachment on the limited technical resources of the team. Thus, more energy is put into system optimization and complexity governance.

Quantification of technical KPI

Xuan’s hard to say: “human nature is selfish, who pay”, so promote technology atmosphere, building engineering culture not only stay in oral, needs certain compulsory means, such as technical personnel to the interests of the binding, the binding is need we can contribute to the technology to analyze and quantify a relatively fair. Those of you who have been a promotion judge know that there is a reference to THE ATA article in your Profile this year, which is also an attempt to quantify the impact of technology.

Technology of KPI

Based on this, I decomposed the KPI of technical personnel into three major parts, namely business contribution, technical contribution and team contribution, which are detailed as follows.

Business contribution: including demand control, business projects and business innovation.

Technical contribution: including design refactoring, technical impact, Code Review, innovation improvement, and Code quality.

Team contribution: including recruitment, new talent development and team atmosphere.

So how do we understand these dimensions of technical contribution? I won’t go into the explanation, but I’ll use some cases from our work to describe it.



Q&a on technical KPI

As for the KPI mentioned above, most technical students agree with it. Of course, there are also many voices of doubt. Let me choose some typical answers here.

Q: Will the proposal of technical KPI cause technical students to focus only on technology and not do business projects?

A: In terms of performance, it must be A combination of business contribution, technical contribution and team contribution. However, as an important reference and weathervane, technical KPI is of positive significance.

Q: How do you quantify this design refactoring?

A: This is difficult to standardize with the system and depends more on TL’s professional ability to score, but even so, it is better than nothing completely black box before. At least the message is that we encourage good design, we encourage constant refactoring and optimization.

Q: Our current business needs are piling up, and front-line students have no time to do reconstruction and optimization

A: This question has already been addressed in the beginning. Do you want to constantly stick to business requirements and bad code, or do you want to take the time to improve and support the business faster? This tradeoff should not be difficult to make. The key is determination and ability. For some mature businesses, I don’t see a business scenario where the delay of launching a few days will affect the business pattern. Therefore, as a Technical team, we should add our Technical Story to the User Story and take the completion of business requirements and system reconstruction as our core task.

About the author: Zhang Jianfei, alibaba senior technical expert, graduated from Yunnan University in 2007 with a master’s degree in computer Application engineering and 12 years of experience in software design and application architecture. Keen on complex business analysis and code complexity governance, worked in a foreign company for 6 years and Ali for 5 years.


Author: Zhang Jianfei

The original link

This article is the original content of the cloud habitat community, shall not be reproduced without permission.