Skip to content
back to the presentation
Talk summary2024CTO

Hard Skills Maxed Out — What's Next?

A talk at the Soft Weekend conference: Alexander, the CTO of T-Bank, explains why maxed-out hard skills stopped being enough, walks through a growth matrix that holds no technical skill at all, and the five things he worked on himself — planning, responsibility, communication, motivation and curiosity. Questions from the floor close it.

Soft Weekend9 min read

This summary is shorter than the full talk; examples and assessments reflect the author’s experience and views.

The main thread of the material
01

Why hard skills alone stopped working

Alexander starts not with soft skills themselves but with why an engineer needs them. Twenty years ago you could write code, push it to a server almost over FTP, and somehow it ran. Now system design, tests, reacting to production problems, security requirements, data and product managers' wishes all land on the developer: you can add letters in front of Ops for ever, and his slide is named accordingly. The answer he likes is pipeline organization: not separate roles with their own pipelines, and not security as a barrier at the end, but one shared process everyone builds into as far left as possible. The second reason is abstractions: infrastructure as a service and platforms let you forget the details until the first problem, after which you look under the bonnet and negotiate with the people who run the thing. The third is Cynefin: the world used to change more slowly and checklists were enough; now the plan changes on the move and large-scale events force sharp turns.

You can close yourself inside a role: many companies have an informal level where an engineer calmly does his tasks for twenty years — unlike consulting, where you are eventually shown the door. But the matrix T-Bank uses to assess growth works differently: it holds no hard skills at all. It has the scale you work at, the impact on the company — money and users brought in or saved — the complexity of the problems you solve, and leadership. He illustrates complexity: a tool everyone relies on stops holding up at scale, and you need someone at contributor level willing to fork and improve it, not a developer who treats another team's project as dogma carved in stone. Leadership he pictured as a paladin in a role-playing game: not just a strong unit, but an aura that strengthens everyone around him. The initiative for promotion at the bank has been handed to employees themselves, instead of the usual talk about a better offer elsewhere.

02

The promotion request, goals and checkpoints

The rules are spelled out: agree with your manager that you want to grow and need large, complex tasks, carry them to the end, and file a request at the next review, where peers from your profession look at it — usually grouped by stack, though at high grades the circle widens and the language stops mattering. Alexander then lists the five things he worked on himself: planning, ownership of the result, communication, motivation — his own and other people's — and curiosity, added to the first four. Planning he lays out on the important-versus-urgent matrix. Important and urgent is an incident you drop everything for. Important but not urgent is browser bookmarks: they pile up endlessly and you never read even the one that would have changed your career. Urgent but not important to you can be delegated: routine that bores you may be a growth challenge for somebody else.

The hardest thing is a goal that lies far away. The standard approach from development-plan trainings — look at where you are, decide where you want to arrive, invent the steps — traps you in the present moment: the goal comes out incremental, because you only set what you know the road to. Alexander suggests counting the other way round, as in the book written by people from Amazon: state the result you want without looking at today's conditions, then build the steps backwards until you reach one that is obvious from where you stand. Then you know how you intend to win the game rather than moving pieces at random. A big goal, on the advice of a book he liked, is better broken into checkpoints and pushed out of your head, or you burn out along the way: instead of a book he wrote posts, and now assembles several books from them. Project management he defends separately: without it you cannot combine the effort of ten thousand engineers, as during the rebranding to T-Bank.

03

Responsibility, communication, questions from the floor

Responsibility, in his telling, starts with recognising and accepting it for your role. A funny detail: eight years ago, joining the bank as a manager, he wrote his own job title and list of duties — and was later assessed against that very text. Hence the habit of settling upfront what the goal is and what result is needed in six months or a year, and focusing on what is inside your zone of control. Pointing a finger at what is bad is easy, doing something about it is hard: large companies periodically have far more advisers than people willing to do it. A leader also works by example: tell people to work hard and then go off to rest, and you stop being believed. Communication he calls a difficult subject for himself: his listening was tuned like autocomplete — understand the other person and finish their sentence faster, which annoys people. Style has to be adapted to the audience: at a non-profit helping homeless people and raising money for veterinary care he spent fifteen minutes talking as at a technical conference, gave an example about roles built on a salad and mayonnaise, and was asked to switch to culinary language.

Curiosity he unpacks through two paths: his own, the theorist's — take a complex problem, read a pile of books, understand how it works and check the findings in practice — and the practitioner's, that of a friend who ran his infrastructure: the manual only when needed, then straight into implementation. The second scales worse: without an RFC or a plan the knowledge does not spread, and you end up with an expert nobody else is allowed near, because he might bite. Hard skills do not go away either: engineers are tested on design and on coding, and a separate group gets its own section where the host, like a game master, sets an incident. From the floor came a question about motivating a team to work on soft skills: without them, Alexander answers, you will not get past senior, who is already expected to show leadership and own the shared result. For a unique but toxic expert the bank builds a configuration: a platform team, written documents, and a different person to deal with the outside world. And how do you measure soft skills, asked Evgeny: self-assessment is biased, so an outside view is needed — a test with a benchmark, a coach, a walk-through of experience at interview, or a call to acquaintances at a former employer.

Takeaways

What to take away

  1. 01The growth matrix holds no hard skills: scale, impact on the company, complexity of problems and leadership — and the employee files the grade request himself.
  2. 02A goal is better built the other way round — from the result you want back to a step that is obvious today; otherwise it comes out incremental.
  3. 03A unique expert without soft skills can still be kept useful: a platform team, written documents and a separate person for the outside world.
  4. 04Self-assessment of soft skills is biased, so an outside view is needed: a test with a benchmark, a coach, or a walk-through of a candidate's experience at interview.

Sources