Brief
The essential idea
Staff+ is not another name for a very strong Senior engineer. It is a level of systemic influence: shaping architecture boundaries, decision processes, delivery resilience, and the engineering environment across several teams without relying on formal people-management authority.
T-Bank uses dual management and IC career tracks, explicit signals across Scope, Impact, Complexity, Leadership, and Improvements, and a T-Rost self-promotion process backed by outcome artifacts. Internal growth is supported with work at the required scale, ADR and RFC evidence, Staff+ community calibration, and rotations that broaden context.
A conventional engineering funnel overweights algorithms, coding, and a finished system-design diagram. A separate Architecture + SDLC section examines how candidates make constrained decisions, evolve systems without a big rewrite, manage debt and migrations, change review and release mechanics, improve incident learning, and create durable cross-team ownership.
According to the source material, the Architecture + SDLC section was used for Staff+ and Tech Lead hiring for about four years, and in 2025 the approach began expanding into engineering interviews more broadly.
Decision lens
Key takeaways
Staff+ level is defined by system-wide impact, not a larger personal task queue.
Architecture and SDLC are a distinct competency and must be evaluated explicitly.
Scope, Impact, Complexity, Leadership, and Improvements provide more reliable level signals than impression.
Internal growth needs assignments, artifacts, calibration, and sometimes rotation across contexts.
Interviewing should inspect the decision and migration process, not only the final architecture.
Durable Staff+ work changes people, process, architecture, and operations after its author steps away.
Workplace experiment
Apply it at work
- 1
Define Staff+ expectations across Scope, Impact, Complexity, Leadership, and Improvements.
- 2
Give candidates and internal engineers cross-team problems that produce reviewable ADR, RFC, migration, and SDLC artifacts.
- 3
Add an Architecture + SDLC interview run by calibrated Staff+ interviewers.
- 4
Review whether each solution establishes ownership, reversibility, operational learning, and mechanisms that survive the author.
Choose one action, define the observable effect, and keep the first test small enough to reverse.
Evidence
Sources and further reading
Primary source
Additional sources
Channel, aggregator, and commentary links confirm the work; they are not the primary source.