Building an Architect Career

Alexander introduces himself: five years at Tinkoff, now heading a division responsible for the retail mobile bank and online acquisition — around 400 people; he calls himself the technical director of that part of the company, not an architect. The hosts frame the chapter's problem: someone moving into a leadership role drifts away from hands-on work, their qualification melts, and yet they must know ever more — frontend, mobile development, the data layer. Alexander's answer: the wider your responsibility, the higher the abstraction you think at. You understand the direction, the functional and non-functional requirements and which teams take part, while concrete decisions are made locally by people more competent in their part; anyone trying to be the cleverest and dictate to everyone gets a rebellion and a mediocre result. The book's own proposal is the 20-minute rule: twenty minutes a day reading about technology to shrink the area of what you do not know that you do not know.

Zhenya Peshkov says the rule works well, though he lacks the daily persistence: he practises it in stretches, now digging into management, where his unknown unknowns outnumber the engineering ones. The hosts add that tempo beats sprinting: ten pages a day make some 3,500 pages a year, about five average books, and a weekly club makes regularity external. Alexander does not practise it, but after the book he subscribed to what it recommended: the DZone newsletters with Refcardz and InfoQ's monthly architecture newsletter, where he found the article by the authors of Team Topologies. Self-education takes a couple of hours a day, rarely fits into working hours, and counts for him as a way of life, not work. For the truly current he suggests white papers from large companies: you get a design document plus the cloud price, which shows why a geo-distributed database with transactions costs that much. That is how he opened the Google Spanner paper after hearing the term NewSQL, though he thinks he read two pages.

The chapter's next step is a personal tech radar, and the talk starts with the ordinary one: a ThoughtWorks document, a target of sectors and rings. There are four sectors — tooling, languages, frameworks, techniques and approaches — and four rings: hold, assess, trial and adopt, from the outermost inwards. One host admits he never fully understood them: the book explains hold as "hold off for now", too new and untested, yet deprecated things land there too. Alexander confirms it: blocking peer review sits in hold right now, and he doubts it was ever in the inner rings — it may have been highlighted only so the industry would stop doing it. Then the movement: assess means the topic looks interesting but nobody dug deep; trial means trying it inside for real, because marketing-driven and starry-eyed reports cannot be trusted; adopt deserves your effort. Out of adopt a technology drifts back to hold once a better way appears, but nothing needs to pass all four rings: a novelty often blinks and vanishes — yet another JS framework that promised to solve it all.

The same applies to a personal portfolio: knowledge, practices and habits are a toolkit that diversifies your risks, and hold takes in not only technologies but habits that stopped paying off — a favourite portal that slid from technical material to entertainment. Alexander retells an image from someone else's talk at last year's Software Engineering Institute architecture award: architects used to design systems from scratch, whereas now they have a set of Lego bricks and must know which exist, what they guarantee and how they connect. In a large company it is unclear what the radar is a radar of: the apps for retail, business and investments live on different approaches, coroutines here, Rx there, so one common radar becomes a union of everything while five or so separate ones point nowhere. What works is attaching the radar of the relevant stack to a job posting, and Alexander values companies that publish theirs openly: a candidate can tell whether this is their approach or the neighbouring team's.

The last section is another target, about ties: strong ones at the centre (colleagues and family, people whose lunch this week you know about), then weak and potential ones — the new arrives through the weak. One host finds the diagram far-fetched: the point is the same as with newsletters — follow interesting people on Twitter or Telegram. Alexander adds a substantive point: the community is small, after a few years of conferences you know nearly everyone through one or two handshakes, and a hard problem sends you to an expert to talk it over with; the same network works for hiring and invitations. Publicity widens it: a speaker meets people more easily, and a recognised expert gets onto a programme committee — one host notes he was invited as an expert this autumn thanks to the podcast. The chapter's danger is the information bubble: narrow specialisation in a technology nobody needs a handful of years later. It closes with a quotation that a career offers about five chances to build a great architecture, and advice to train on katas, where you design without burying money in production.

Alexander has never taken part in a kata, but over the past year he ran several dozen — fewer than a hundred, by his count — design interviews on distributed systems and wrote part of the design-section tasks. A good task is built like a detective story: the requirements act as clues and leave one or two sensible options. From the internal architecture Slack channel, which also holds more than 400 people, he recruits interviewers who ride as second pilot, then run interviews themselves. He splits the roles in three: software architecture, ideally done by staff- and principal-level engineers who have not left the code; solution architecture, about the complexity of a solution stretched across several systems and teams; and enterprise architecture, semi-mythical to him, with TOGAF and the Zachman matrix — while unification at scale comes not from an all-knowing person but from shared platforms and engineering practices. The book's ideal architect he treats as a target state: directive management does not work, so decisions have to be sold — you bring an RFC with the problem and options, and record an ADR afterwards.