KT.Team developer grades: L10, L20, L30, and IDP

A developer's final product is independently delivered value used by a real person in the client's business. Not a closed task, not a merged branch, and not a deployed release, but working functionality that has already received feedback from actual users in production.

Everything else follows from this. The engineer takes responsibility from idea to use, so direct contact with the business user is necessary. The result is expressed in business terms, so the engineer is evaluated by process shift rather than by the amount written. The engineer covers the value end to end as a full-stack engineer, so there are no separate scoring scales for frontend and backend.

AI here is a core tool, not a bonus. The engineer does not write what a machine can write, uses agentic development, and brings AI analysts and AI critics into the daily review of requirements and implementation. Assessment reflects this: it is not tied to the volume of manual code.

At L10, there is no question of how it should work, and what the business needs is obvious. The client describes not only what to do, but also how, or the task is so clear that the how does not need to be described. In this kind of interaction, the team does the hands-on work, and the engineer applies only technical skills.

Volume is irrelevant here. Building a large section from finished designs together with data is L10, no matter how many weeks it takes. Repeating an integration that has already been done with different data is also L10, because the uncertainty has already been removed.

Technical quality is mandatory. A junior who implements a task carelessly does not receive a high L10 rating.

L20 is a medium-sized business value with almost no uncertainty: the meaning of the entities is clear, the data model is generally clear, and usability is easy to verify by clicking through the result within the team. The client defines what should be delivered but does not break the task down into technical steps.

Only the person who delivers the value end to end receives L20. If the value is delivered by a frontend engineer plus a backend engineer, neither gets L20: responsibility is blurred, an extra synchronization point appears, and the engineer starts optimizing the contract with a colleague instead of the result for the user. That is why L20 is always full-stack.

At this level, the engineer writes less code and instead designs workflows, automates development processes, and relies on AI agents. Business requirements are analyzed by an AI analyst, and the result is checked with the user in small increments every day.

An epic is a meaningful new state of an end-to-end business process or the entire project. The set of values inside an epic gives the project a new meta-property, not just the sum of separate features. Such a state can be described in the language of the decision maker and ideally implemented by a team in two to four weeks.

The key difference between L30 and L20 is hypothesis-driven thinking. We do not know for sure whether the intended set of values will lead to the desired state; each value within an epic is an assumption validated with real users. A simple rule: if you can precisely describe in advance what to do and how to verify it, that is L20 or L10. If you can only describe the desired new state, while the path to it emerges along the way, that is L30.

It is important to distinguish between delegated and retained level. The client may hand over the state in full, but if the team does not define scenarios, test cases, and readiness criteria on its own, and the client has to do the analyst's or tester's job, L30 is not retained. In the assessment this is recorded explicitly: L30 delegated, retained level L20.

Questions are asked on a five-point Likert scale: each statement is answered with a degree of agreement, from "strongly disagree" to "strongly agree." If a level cannot be assessed, it is left blank - for example, a lone developer on a project does not receive a TECHLEAD rating, because there is no team to lead.

The rule is to round down: "almost four" means three. A four appears only when it is definitely a four. An optimistic assessment may seem kind, but it deprives the engineer of an honest picture and time to grow, and deprives the team of an understanding of how things are done here.

If an engineer does not complete tasks of a given level end to end, they are not rated at that level. This is a project constraint, not a verdict on the person.

The points add up to a salary benchmark. Each level and badge has its own weight: scores below four do not count, a four counts half, a five counts fully, and intermediate values count proportionally. The total is the benchmark.

This is an indicator, not an automatic salary recalculation. If an engineer earns more than the calculated benchmark, their salary is not reduced. A downward gap usually points not to the person, but to the project: where the client trusts only L10 tasks, only technical skills can be assessed, and the manager, together with the client, should address that, not the engineer.

A reverse gap is a signal to discuss a raise, which usually happens not in one step but over several months so that another evaluation cycle can pass. A small difference between the actual salary and the review target does not require action.

The scale emerged not from personal preference, but from several consistent results:

• DORA and Accelerate
• Google SRE
• Putnam's equation and the Norden-Rayleigh curve
• Domain-Driven Design
• lean manufacturing principles

The Norden-Rayleigh curve describes how effort is distributed across a project and shows that deadlines have a physical minimum. Any additional role in the chain adds communication links: the curve stretches, the schedule grows, and the amount of work stays the same. Putnam's equation adds nonlinearity to this: trying to offset organizational complexity with people and phases makes launch disproportionately more expensive. According to QSM, the team optimum for a medium system is three to seven people.

DORA provides empirical evidence from modern teams and highlights two key architectural factors: loose coupling and the team's freedom to choose tools. That is why technical details play almost no role in the assessment, except for loose coupling, which determines how cheaply the system absorbs change.

Loose coupling is not about coding style and not about following SOLID. It is the system's ability to keep a change in one place. Strong coupling leads to slow changes, long checks, and complex releases, which means longer time to real use.

We verify this quantitatively, not by words. The main method is analyzing co-changes in files: once a month we review the repository history and look for modules that regularly change together. Sustained co-change indicates a hidden dependency, even if everything is formally separated by interfaces.

If an engineer explains loose coupling only through interfaces, dependency injection, and SOLID, that is a sign of superficial understanding. The discussion should be about change localization, hidden dependencies, and coupling at the workflow level.