DigitableCourses
Русский
Career

Career map

A career in development is not one ladder. Higher up it branches, and the branches are not “above and below” but different work: a manager, an architect and a staff engineer answer for different things and are measured by different metrics. People walk it in every direction, backwards included, and the move back is not a failure.

Below is the portal’s grid of roles with the links between them and a list of reference competencies for each “role × level” pair. Every competency leads into the catalogue track where that topic is covered.

Career forks What seniority levels are

The roles and the moves between them

10 roles in 4 groups and 35 moves. There is more than one ladder here: some moves go sideways — from analytics into product, from backend into SRE — and some go back, and the portal counts a move back as a normal move rather than a failure.

Who writes the product

Development for a specific surface: server, browser, phone.

  • Backend developer

    The server side: data, APIs, integrations, reliability under load.

    What people call it: Job ads call it 'backend', 'server-side development', 'fullstack leaning towards the back'. Look at the list of tasks, not at the word in the heading.

    Where people go from here
    • SRE and platform engineering sideways — a different profession, not a promotion Your own developers become the customers. The subject changes: not a feature but reliability and tooling.
    • Data and machine learning sideways — a different profession, not a promotion The shortest way in is through data and queues. You will have to pick up statistics, not just engineering.
    • Architect deeper — the same engineering track at a larger scale Not a promotion: the horizon grows to several systems, and you will write less code.
    • Team lead, tech lead, engineering manager sideways — a different profession, not a promotion A different profession with different measures of success. Roughly one in three comes back, and that is normal.
    Reference skills: 4 levels, 19 items
    Junior

    What is expected is not ready-made answers but the speed of learning and the quality of the questions.

    • I write and run code in my working language without looking up the syntax I can assemble a small service from scratch: dependencies, running it, formatting, linter. Go
    • I understand what happens between the browser's request and the service's response I can explain why a request returned 502, instead of saying the server is broken. Computer networks
    • I write SQL queries and understand what a transaction is I put together a query with a join and grouping without googling it, and I know how a transaction differs from separate queries. Databases
    • I work in a shared branch without breaking the history for everyone else I resolve a conflict, open a meaningful pull request, recover a lost commit. Git and teamwork
    • I pin a bug down from logs and a stack trace, not by trial and error I state a hypothesis and test it instead of changing lines at random. Programming from scratch
    Middle

    Holds the whole path of a feature: from incomplete requirements to running in production.

    • I take a feature all the way: requirements, code, tests, deployment, watching it run After my release there are no loose ends left for somebody else to finish. How software gets made, and careers
    • I write tests that catch regressions instead of repeating the code I can explain what exactly each test checks and why deleting it would be no loss. Software testing
    • I read a query plan and fix a slow query I spot a seq scan where an index belongs, and I know what an insert pays for every extra index. Databases
    • I design an API that will survive the next version I can add a field without breaking old clients, and I know the price of the API style we chose. Architecture patterns
    • I work in old code written by other people without rewriting all of it I can change a module whose author has left, and explain why I did not refactor everything. Development principles
    Senior

    The pay is not for typing code fast but for the risk taken off the table.

    • I choose a solution by its consequences rather than by fashion, and I write the choice down Decisions have an ADR: what we considered, what we gave up, and on what conditions we revisit it. Architecture patterns
    • I design for failure: retries, idempotency, consistency I know what happens to the data when the network drops in the middle of an operation, and I have accounted for it in advance. Distributed systems
    • I run an incident and write the post-mortem without hunting for someone to blame A post-mortem leaves behind a change in the system or in the process, not a line saying be more careful. CI/CD, infrastructure and clouds
    • I review in a way that leaves the other person stronger than before My comments carry the why, not only the redo this; the team has a shared standard. Development principles
    • I see the attack surface inside my own feature I sort out authorisation and secrets before the release, not after the pentest report. Application security
    Further on: a branching, not a rung

    After senior the ladder forks. Stopping here is a full choice, not a ceiling.

    • I take on work that does not fit inside one team I carried through a piece of work that had neither an owner nor a clear statement. How software gets made, and careers
    • I change practices without formal authority My idea was adopted by teams that do not report to me. How software gets made, and careers
    • I optimise by measurement, not by feel I start with a profile and a load test and finish with a number saying how much faster it got. Systems performance
    • I count the money a system costs, not only its architecture I can say what the service costs per month and which option is cheaper when it doubles in size. CI/CD, infrastructure and clouds

  • Frontend developer

    The interface in the browser: markup, state, performance, accessibility.

    What people call it: 'Frontend' in one company means building pages from mockups, in another a whole client architecture with its own backend for frontend. Ask about it at the interview.

    Where people go from here
    • Mobile developer sideways — a different profession, not a promotion Similar problems of state and navigation, a different runtime and a different release cycle through the stores.
    • Backend developer sideways — a different profession, not a promotion Through BFF and APIs. You will have to pick up data and reliability in earnest.
    • Product manager sideways — a different profession, not a promotion A common trajectory: being close to the user helps, but the measures of success change completely.
    • Team lead, tech lead, engineering manager sideways — a different profession, not a promotion A different job: you no longer have a task of your own, you have other people's.
    Reference skills: 4 levels, 19 items
    Junior

    The base platform matters more than the framework: frameworks change, the browser stays.

    • I understand what the browser does between the load and the first frame I can explain why the page flickers and which part of that is my code's fault. Frontend development
    • I write markup that works without styles and from the keyboard The form submits on Enter, and a button is a button element, not a div with a handler. Accessibility (a11y)
    • I build a layout that does not fall apart on a phone I understand flow, flexbox and grid, and I do not fix everything with absolute positioning. Frontend development
    • I write components and understand where their state comes from I tell component state from application state and do not duplicate the source of truth. Frontend development
    • I can deal with the project build, not only with npm run dev I understand what happens between the source and the bundle, and I can fix a broken build. Frontend development
    Middle

    Owns the behaviour of a screen entirely, including errors and empty states.

    • I choose how to store state to fit the problem, not out of habit I can explain why useState is enough here and a cache of server data is needed there. Frontend development
    • I build forms that behave honestly when the network and the validation fail A double click does not create two records, and a server error does not wipe what was typed in. Frontend development
    • I use types as a design tool, not as a formality An invalid state is inexpressible in my types rather than checked at runtime. TypeScript
    • I test the behaviour of the interface, not implementation details The test does not break when a class is renamed, but it does break when the scenario breaks. Software testing
    • I check accessibility before the release, not after a complaint I go through my own screen with a keyboard and a screen reader, and I know where aria is genuinely needed in it. Accessibility (a11y)
    Senior

    Owns the client side as a system, not as a set of screens.

    • I hold the client architecture: module boundaries, shared contracts, other people's code A new developer adds a screen without asking where to put the file. Frontend development
    • I improve load metrics from measurements taken on real users I work from field data, not from a lab run on my own laptop. Systems performance
    • I choose the rendering model deliberately and understand its price I can explain what we gained and what we lost by moving to server rendering. Frontend development
    • I understand the client-side classes of attack and do not rely on checks in the browser I know what CSP is for, and I do not count validation on the client as protection. Application security
    • I speak the same language as design and argue on the substance I can say what is expensive in a mockup and what to replace it with, instead of just saying it cannot be done. UX and interface design
    Further on: a branching, not a rung

    Platform, product, management are different jobs, not different altitudes.

  • Mobile developer

    Apps for iOS and Android: the platform, offline, background work, releases through the stores.

    What people call it: 'Mobile developer' covers both native development for a single platform and cross-platform work in Flutter or React Native. These are very different sets of skills.

    Where people go from here
    • Frontend developer sideways — a different profession, not a promotion The nearest neighbour in problems of state and navigation; the release cycle becomes far faster.
    • Backend developer sideways — a different profession, not a promotion Through APIs and synchronisation. You will have to pick up data, transactions and load.
    • Team lead, tech lead, engineering manager sideways — a different profession, not a promotion A different profession. It shows especially in mobile teams: the release cycle starts to run you rather than the other way round.
    Reference skills: 3 levels, 12 items
    Junior

    The platform and its limits first, frameworks after.

    • I understand the lifecycle of a screen and of the app on my platform I know what happens to my screen on rotation, on an incoming call and when the process is killed. Mobile development
    • I build screens and navigation from a mockup The layout survives a small screen, a large font and a long text. Mobile development
    • I go to the network and handle the errors, not only the happy path The app does not crash in the underground and says clearly that there is no connection. Computer networks
    • I work in a shared branch and understand the team's release cycle I know where my branch merges to and what will make it into the next build. Git and teamwork
    Middle

    Owns a feature entirely, including offline, background work and the release to the store.

    • I lay the app out in layers, not in screens The logic can be tested without launching the UI. Mobile development
    • I build offline and synchronisation knowing that conflicts will happen I have a rule for resolving conflicts, not a hope that none will occur. Mobile development
    • I work with background tasks and push notifications within the limits of the platform I understand why the system kills my background work, and I do not fight it with hacks. Mobile development
    • I take a release through the store and can roll back I know what to do about a bug in production when review in the store takes a day. Mobile development
    Senior

    Owns the app as a product with a million installed copies of different versions.

    • I keep startup, memory and battery within limits I measured myself I have the numbers before and after, taken on a real low-end device. Systems performance
    • I protect data on a device that does not belong to me I do not keep secrets in the app, and I know that a client can always be cracked open. Application security
    • I build testing that survives a zoo of devices I know what we automate, what we deliberately check by hand, and why. Software testing
    • I choose native or cross-platform deliberately I can name the price of the choice for a specific team instead of arguing about frameworks in general. Mobile development

Who owns quality and production

Work where the value is not the code written but the fact that the system neither falls over nor lies.

  • QA engineer

    Quality as a job of its own: test design, automation, feedback into the process.

    What people call it: The portal separates a manual QA, an automation engineer and an SDET. Job ads mix these three words up constantly — ask what exactly the subject of your work will be.

    Where people go from here
    • Backend developer sideways — a different profession, not a promotion The usual trajectory, through SDET. You will have to pick up design in earnest, not just automation.
    • SRE and platform engineering sideways — a different profession, not a promotion Through tests in CI and observability: the subject is the same — trust in the system.
    • Systems and business analyst sideways — a different profession, not a promotion QA is often the first to spot contradictions in the requirements — and that is half of an analyst's work.
    Reference skills: 3 levels, 12 items
    Junior

    The main skill is not being able to click but describing what you observe so that it can be reproduced.

    • I use the terminology of testing the same way the team does I do not confuse a defect, a failure and an error, and I do not argue about words at a bug review. Software testing
    • I design the checks instead of going through options blindly I use equivalence classes and boundaries, and I can explain why these checks are enough. Software testing
    • I write a bug report that reproduces the defect on the first try The developer does not come back asking how to repeat it. Software testing
    • I check the API directly, not only through the interface I can send a request by hand and work out whose side the problem is on. Software testing
    Middle

    Answers for automation saving time rather than eating it.

    • I write automated tests that do not flake The suite has no sometimes-red tests that everyone is used to rerunning. Software testing
    • I wire tests into the pipeline so that their result is trusted A red build stops the deployment, and nobody treats that as an obstacle. CI/CD, infrastructure and clouds
    • I program well enough to maintain the test code My test project is no worse than the product one: it is readable and refactorable too. Python
    • I check more than the functionality I can set up a load run and check the basic things about security. Software testing
    Senior

    The subject of the work is not tests but how far the team can trust its own release.

    • I build a testing strategy around the risks of the product, not around the template of the pyramid I can explain why there are few unit tests here, and it is a deliberate decision. Software testing
    • I catch a defect at the requirements stage, not in production My questions about the statement of work change that statement before development starts. Systems and business analysis
    • I measure the quality of the process, not the number of tests written I look at the time to restore and the share of failed releases, not at coverage for the sake of coverage. Project Management
    • I understand the forks inside quality work and choose mine deliberately I can explain the difference between an SDET, a process quality engineer and a risk analyst. Software testing

  • SRE and platform engineering

    Reliability and tooling for other teams: infrastructure as code, observability, on-call.

    What people call it: DevOps engineer, SRE and platform engineer are three different sets of duties under three names that keep getting swapped. Sometimes all these words hide is a general dogsbody with some YAML.

    Where people go from here
    • Backend developer back — the portal does not count this as a failure The move back is common and is not counted as a failure: operations experience makes an engineer worth more.
    • Architect deeper — the same engineering track at a larger scale Whoever has held production sees non-functional requirements better — and that is half of an architect's work.
    • Data and machine learning sideways — a different profession, not a promotion Through pipelines and storage. The infrastructure part is familiar, the statistics is not.
    • Team lead, tech lead, engineering manager sideways — a different profession, not a promotion A different profession. A risk of its own: in an on-call team the manager quickly turns into an incident dispatcher.
    Reference skills: 3 levels, 15 items
    Entry

    Almost nobody arrives here from scratch: you need experience either in development or in administration.

    • I live confidently in Linux with no graphical interface I can find what ate the disk and the processor without installing anything extra. Operating systems
    • I take a network problem apart layer by layer, not by rebooting I can get from it does not work to a specific place: DNS, a route, TLS, the load balancer. Computer networks
    • I build and run containers deliberately I understand how a container differs from a virtual machine and why my image weighs a gigabyte. CI/CD, infrastructure and clouds
    • I build the pipeline for build and deployment The project has a repeatable build that can be run from somewhere other than my laptop. CI/CD, infrastructure and clouds
    • I write code, not only configs My scripts live in a repository, go through review and have tests. Python
    Core level

    Owns the platform that other teams use.

    • I keep infrastructure in code, not in clicks in a console The environment comes back up from the repository, and we have tested that. CI/CD, infrastructure and clouds
    • I operate the orchestrator, not only write manifests I understand why a pod will not start, and I can read the events of the cluster. CI/CD, infrastructure and clouds
    • I build observability you can run an investigation with The dashboard shows what broke, not only that something is red. CI/CD, infrastructure and clouds
    • I deploy without downtime and can roll back A canary or blue-green release actually works here rather than being described in a wiki. CI/CD, infrastructure and clouds
    • I do not keep secrets in the repository and I can change them Rotating a secret is an ordinary operation, not a special operation. Application security
    Senior and beyond

    The subject of the work is not servers but reliability as an agreement with the product.

    • I set the reliability targets together with the product and live by them The service has an agreed level of availability, and it affects decisions about releases. Distributed systems
    • I design the system for the failures that are certain to happen I know the failure model of my system and what happens when the network splits. Distributed systems
    • I manage the cost of infrastructure as an engineering problem I can name what costs the most and propose a trade-off that does not lose reliability. CI/CD, infrastructure and clouds
    • I build an on-call rota that does not burn people out Night-time pages get looked into and reduced rather than counted as normal for the profession. Time management for engineers
    • I treat my platform as a product for internal customers The platform has documentation, a feedback loop and a clear path for migration. Product Management

Who works with meaning and data

Roles where the main question is «what and why», not «how».

  • Data and machine learning

    Data pipelines, models, getting models into production and an honest assessment of their quality.

    What people call it: Data engineer, data scientist, ML engineer and 'AI engineer' are different professions. Some of the vacancies with AI in the title are a renamed backend job — read the contents.

    Where people go from here
    • Backend developer sideways — a different profession, not a promotion The engineering part carries over almost entirely; the statistics goes away, the load arrives.
    • Systems and business analyst sideways — a different profession, not a promotion Data is the shared subject, but the analyst's customer sits inside the business rather than being a model.
    • Product manager sideways — a different profession, not a promotion The usual move for those who are tired of proving the value of a model and want to decide what gets built at all.
    • SRE and platform engineering sideways — a different profession, not a promotion Through MLOps: the same pipelines and observability, only the subject is a model rather than a service.
    Reference skills: 3 levels, 15 items
    Entry

    The base here is double: engineering and mathematics. Without the second half what you get is copied notebooks.

    • I use probability and statistics, not only the mean I understand how a distribution differs from a mean, and why a sample can be unrepresentative. Mathematics for programmers
    • I get the data myself and understand where it came from I write non-trivial SQL and know which fields in the source lie. Databases
    • I write reproducible analysis code, not a throwaway notebook My result repeats on another machine and a month later. Python
    • I prepare features and understand that the data is always dirty I check for missing values, outliers and target leakage before training. Machine learning
    • I start with a simple model and compare everything against it I have a baseline that had to be beaten, not only a neural network. Machine learning
    Core level

    Answers for the model being useful outside the notebook.

    • I evaluate a model honestly, including where it is wrong I pick the metric that fits the problem rather than the one that looks nicer, and I know the price of each kind of error. Machine learning
    • I build data pipelines that survive a source going down Recomputing yesterday is an ordinary operation, not a repair by hand. Data Engineering and ETL
    • I answer for the quality of the data, not only for the code that reads it The data mart has checks, and they fire before the business notices. Data Engineering and ETL
    • I take a model to production and watch it after the launch I know when a model has gone stale, and I have a plan for retraining. Machine learning
    • I work with language models as an engineer, not by guessing at prompts My solution has an evaluation of quality and an estimate of the cost per request. AI agents and prompt engineering
    Senior and beyond

    The subject of the work is solving a business problem, not a score on a held-out sample.

    • I translate a business problem into a learning problem — or say honestly that no model is needed here I have projects I proposed to close because a rule with three conditions was enough. Product Management
    • I set up an experiment so that its result can be trusted I compute the power in advance and know what peeking at interim results does. Product Management
    • I keep the load and the cost of model inference under control I know what a single request costs and can bring that number down. Systems performance
    • I see the risks of a model: the data, privacy, the harm from an error I can name who my model's error harms and how, and what we did about it. Application security
    • I explain a result to people who do not read charts After my talk a decision gets made, rather than a request to send the slides over. Logic and fallacies

  • Systems and business analyst

    Turns a vague 'we need this done' into requirements you can build a system from and check it against.

    What people call it: A business analyst and a systems analyst are different roles, and in small companies they are one person who is the product manager and the technical writer as well.

    Where people go from here
    • Product manager sideways — a different profession, not a promotion One of the most common trajectories. The question changes: not 'how do we write this down correctly' but 'is this worth doing at all'.
    • Backend developer sideways — a different profession, not a promotion Possible if you pick up engineering in earnest. Knowing the domain stays an advantage while you do.
    • Data and machine learning sideways — a different profession, not a promotion Through data analytics. You will have to pick up statistics and the engineering of pipelines.
    • QA engineer sideways — a different profession, not a promotion Adjacent work: acceptance criteria are the shared subject of both roles.
    Reference skills: 3 levels, 12 items
    Junior

    The main ability is asking questions, not producing documents.

    • I pull requirements out of people who cannot state them What my meeting leaves behind is not a retelling but a list of decisions and open questions. Systems and business analysis
    • I tell the kinds of requirements apart and do not mix them up I do not blend a business goal, a user scenario and a technical constraint into one item. Systems and business analysis
    • I write a document that gets read and worked from The developer does not come back asking what was meant here. Systems and business analysis
    • I draw diagrams in a commonly accepted notation, not with arbitrary boxes My diagram is understood by a person who was not at the meeting. Systems and business analysis
    Middle

    Answers for what was built matching what was intended.

    • I design the data model together with development I understand what my entity turns into in the database and why that matters. Systems and business analysis
    • I describe integrations and contracts between systems My contract covers the behaviour on errors, not only the happy path. Systems and business analysis
    • I state non-functional requirements in numbers Instead of it should be fast I have written down at what load and with what response time. Systems and business analysis
    • I write acceptance criteria you can check the result against A test can be written from my criteria without asking me anything. Systems and business analysis
    Senior and beyond

    The subject of the work is not a document but agreement between parties who do not understand each other.

    • I work with the domain, not only with the wording I can challenge a customer's requirement because I understand their business better than they described it. Domain-Driven Design
    • I do the analysis inside the iterations, not as one big document up front Requirements get refined along the way, and that is not counted as a failure of planning. Systems and business analysis
    • I bring the conflicting requirements of different parties to a decision I can move an argument out of who outranks whom into what each option costs us. Logic and fallacies
    • I understand the architectural consequences of my own requirements I know which requirement has just made the system distributed. Architecture patterns

  • Product manager

    Decides what to build and why, and answers for the outcome rather than for the volume shipped.

    What people call it: Product manager and product owner mean the same thing in some companies and something fundamentally different in others. In a startup the product manager is often the analyst and the marketer too.

    Where people go from here
    • Systems and business analyst back — the portal does not count this as a failure Going back into analysis is a normal move, especially if you would rather not answer for the commercial result.
    • Team lead, tech lead, engineering manager sideways — a different profession, not a promotion Adjacent work with people, but the subject is different: not the team but the value for the user.
    • Data and machine learning sideways — a different profession, not a promotion Through product analytics. You will have to stop ordering numbers and start counting them yourself.
    Reference skills: 3 levels, 12 items
    Entry

    People usually arrive here from development, analysis or support, not from scratch.

    • I talk to users without feeding them the answers What I take out of an interview is a description of the problem, not a confirmation of my idea. Product Management
    • I choose a metric that cannot be gamed without making the product better I can explain how my metric is connected to money and where it can be cheated. Product Management
    • I prioritise in a way that lets me explain the decision to the team A refusal has a reason behind it, not a line about what was decided upstairs. Product Management
    • I state a problem so that it can be built The team does not come back asking what to do if the service is unavailable. Systems and business analysis
    Core level

    Owns the direction, not the list of tasks in a sprint.

    • I test hypotheses with an experiment, not with a meeting The hypothesis says in advance which result would refute it. Product Management
    • I hold a strategy and can say no to a good idea The roadmap has a logic to it, not only a list of wishes from stakeholders. Product Management
    • I count the unit economics of my product I know what acquisition costs and what a user brings in, not only the DAU. Business for engineers
    • I work with the development team without turning into a dispatcher of tasks The team knows why it is building a feature and can propose a cheaper solution to the same problem. Project Management
    Senior and beyond

    The subject of the work is a portfolio of bets, part of which is required not to pay off.

    • I manage bets, not tasks I have directions I shut down, and I can explain what they taught us. Product Management
    • I tell data apart from the interpretation of it I do not confuse correlation with cause, and I spot a survivor sample in somebody else's report. Logic and fallacies
    • I negotiate with stakeholders whose goals are opposed The agreement holds for longer than one meeting. How software gets made, and careers
    • I understand the technical price of my decisions I can discuss technical debt as a product decision, not as a whim of the developers. How software gets made, and careers

Who owns scale

A different profession, not the next rung: the subject of the work changes from code to people and systems.

  • Team lead, tech lead, engineering manager

    Work about people and the flow of tasks. Not a developer's next level but a different profession.

    What people call it: The word 'team lead' covers three different sets of responsibility: a tech lead owns the technical direction, a team lead owns the flow of work, an engineering manager owns people and their growth. Ask which of them is meant in this particular place.

    Where people go from here
    • Backend developer back — the portal does not count this as a failure Roughly one in three goes back into engineering, and that is good news. After a year in management a person is worth more than before.
    • Product manager sideways — a different profession, not a promotion Adjacent work. The subject of responsibility changes: not the team but the outcome for the user.
    • Architect sideways — a different profession, not a promotion Back into the technical branch, but keeping the scale: several systems instead of one team.
    Reference skills: 3 levels, 13 items
    Tech lead

    The subject is the team's technical direction. Still writes code, but less of it.

    • I set the technical direction and explain it to the team The decisions are written down, and people can argue about them without me. Architecture patterns
    • I hold the quality bar without becoming the bottleneck A review does not wait a day for me, and the standard lives in the linter and in CI. Development principles
    • I manage technical debt as a plan, not as a complaint The debt has a list, an assessment of its consequences and a slot in the schedule. How software gets made, and careers
    • I grow people through work, not through advice I hand over a stretch task and stay nearby instead of taking it back on the second day. How software gets made, and careers
    Team lead and engineering manager

    The subject is people and the flow of work. There is no work of your own any more, there is other people's.

    • I hold regular one-on-one meetings where people tell the truth People bring their problems in before they hand in their notice. How software gets made, and careers
    • I give feedback in time, including the unpleasant kind There are no surprises at the performance review. How software gets made, and careers
    • I delegate the authority along with the work, not only the responsibility The task leaves my hands whole, and I do not redo it at night. Management: core materials
    • I look at the flow of work, not at how busy people are I measure how long a task takes to get through, not the number of tickets closed. Project Management
    • I hire and run interviews I am not ashamed of My interviews check the work, not general knowledge, and the candidate gets an answer on time. How software gets made, and careers
    Head of and above

    The subject is several teams and the rules they work by.

    • I design the boundaries between teams, not only their composition I understand which dependencies between teams the chosen split has created. How software gets made, and careers
    • I fit the process to the context instead of rolling out a framework whole I can explain which specific problem each element of the process solves. Project Management
    • I talk to the business in the language of money and deadlines My budget and my promises meet reality more often than they miss it. Business for engineers
    • I keep the load on the team at a level that can be held for years We have no heroics as the norm and no overtime as a planned resource. Time management for engineers

  • Architect

    Owns the decisions where the price of a mistake is years, not a sprint.

    What people call it: The most confusing word in the industry: software architect, solution architect and enterprise architect are three different jobs. At the interview always ask which one is meant.

    Where people go from here
    • Backend developer back — the portal does not count this as a failure Going back into development is normal: an architect two years away from code starts designing blind.
    • Team lead, tech lead, engineering manager sideways — a different profession, not a promotion A different profession at the same scale: there the subject is people, here it is systems.
    • SRE and platform engineering sideways — a different profession, not a promotion Adjacent work: non-functional requirements and fault tolerance are the shared subject.
    Reference skills: 3 levels, 12 items
    Software architect

    The architecture of a single system. The closest to code of the three.

    • I choose an architectural style to fit the problem and know its price I can explain why a modular monolith belongs here rather than microservices. Architecture patterns
    • I record decisions so that they can be revisited Every major choice has an ADR with the context and the conditions for revisiting it. Architecture patterns
    • I draw the boundaries along the domain, not along the layers of code My modules line up with the way the business thinks about its own work. Domain-Driven Design
    • I understand what being distributed does to data I know where we have eventual consistency and what the user sees at that moment. Distributed systems
    Solution architect

    Several systems and the integrations between them, often with outside contractors.

    • I design integrations between systems that have different owners The contract survives the other side changing its system without warning. Architecture patterns
    • I turn reliable and fast into concrete numbers and then check them The solution has a load calculation, not only a diagram on a slide. Systems performance
    • I build security into the architecture instead of hanging it on afterwards The threat model is discussed before implementation and affects which solution is chosen. Application security
    • I plan a migration that can be stopped halfway The transition has intermediate states, and the system works in every one of them. Databases
    Enterprise architect

    The landscape of the whole company. There is almost no code here, but there is politics and money.

    • I see the landscape of the company's systems and know what is connected to what I can say which systems will fall over if this one is switched off. How software gets made, and careers
    • I introduce rules that teams follow without a supervisor The standard is more convenient than breaking it, so nobody works around it. How software gets made, and careers
    • I justify architectural decisions with money and risk I talk to the finance director in their own language instead of showing diagrams. Business for engineers
    • I account for the requirements of regulators before designing, not after an audit I know where our personal data is and what the law allows us to do with it. Application security

Self-assessment: mark yourself up and see the gaps

The three states per item — “I do this”, “I do this with support”, “I do not” — come from “How to grow: a development plan and feedback”. The result of the self-assessment is a map of gaps, not a level. The portal will not call you a junior, a middle or a senior: it has no data for that, and the words have no shared meaning across companies.

The marks are kept in this browser only (localStorage, keys digitable:career:*). No sign-up, nothing is sent anywhere, and the reset button deletes them all.

The self-assessment needs JavaScript: it computes the map of gaps in the browser and keeps the marks locally. Without it the page is still useful — the whole lattice of roles and the full list of skills with links to the tracks are above.

The list of skills is this portal's guide, not an industry standard and not your employer's matrix. External matrices worth comparing against are listed in the piece on seniority; read them two adjacent levels at a time — the value is in the delta between them.