Coaching on Mikhail Shogin

Совет умирает. Вопрос остаётся

Sat, 25 Apr 2026 00:00:00 +0000

Я 20 лет копил техническую экспертизу. За последние полтора года значительная её часть стала доступна любому, у кого есть подписка на нейросеть за 20 долларов.

Этот вопрос всплывает у меня периодически: насколько ценен мой опыт сегодня?

AI не “плохо отвечает”. AI поддерживает

Да, AI знает глубже, шире, точнее меня. И всё же есть особенность: AI поддерживает. Какое бы направление оператор ни выбрал - AI развивает именно выбранное.

Это даже не плохо. Молодой инженер с GPT движется в проблеме быстрее, чем я когда-то лопатил Stack Overflow и форумы по выходным.

Что мне даёт опыт - в какой-то момент сказать “стоп”. Развернуть. Потому что на эти грабли я уже наступал, и помню, как они выглядят.

Но смотрите дальше. Говорю AI: “Стоп. В моём прошлом проекте этот путь не сработал. Давай развернёмся”. Он отвечает: “Точно, отличная идея”. И теперь поддерживает развёрнутый вариант.

AI равно поддерживает любую мою сторону. И прежнюю, и развёрнутую.

И вот это - мой настоящий вопрос. На что опираться, если AI быстрее меня в ответах и подыгрывает любому моему выбору?

Поворот, которого я не ожидал

Ответ пришёл с неожиданной стороны: в этом году я учусь на коуча. Скоро экзамен ICF Level 1.

И эта учёба меня прижала.

Я всю жизнь работал в том же режиме, что AI. Только медленнее.

Подходит коллега с проблемой - страх, сомнение, выбор. Я уже знаю, что ему сказать. Кому позвонить. Как сформулировать. Что почитать. Раздаю советы быстро, точно, по делу.

Человек кивает. Уходит.

Через неделю приходит снова. С тем же вопросом. В новой обёртке.

И я не понимал почему так.

Сейчас понимаю. Я отвечал на его слова. А не на его настоящий вопрос - который под словами: страх, сомнение, что-то очень его, во что мой совет даже не пытался попасть.

Что меняется

Учусь делать другое.

Не выдавать ответ. Задавать вопросы, от которых человек сам видит свой блок. Что для него важно. Что он уже пробовал. Что его держит. Что станет первым шагом.

Это медленнее. Менее эффектно. И сложнее, чем выдать ответ за тридцать секунд.

Но самое интересное и самое сложное - дальше.

Когда у человека загорается лампочка - “Ага! Я понял!” - это не финиш. Это эмоциональный всплеск. Через два дня он рассасывается, и человек остаётся с тем же вопросом, что в начале.

Профессионализм коуча, как я его сейчас вижу, - не отпустить на инсайте. Дойти с человеком до конкретного следующего шага. Проверенного на его собственные грабли. Чтобы у него остался не пик эмоции, а план, который работает без меня.

Где мой компас

И вот тут связалось.

AI даёт ответы за секунды. Я давал ответы за минуты. Это - то, что заменяется.

Что не заменяется - умение задать вопрос, от которого человек видит свой реальный блок. И не отпустить, пока у него не сложился рабочий шаг.

И вот это - точка, на которую можно опираться. Не на знания. Не на ответы. На умение задать вопрос и довести человека до его собственного шага.

И это, пожалуй, главное, что я унесу из учёбы на коуча в свою работу архитектора. Архитектура систем и архитектура мышления - это один навык, только субстрат разный.

Когда вам в последний раз помог не совет, а правильно поставленный вопрос?

Three blockers that prevent technical leaders from growing

Mon, 16 Mar 2026 00:00:00 +0000

AI is changing IT faster than we can adapt. Roles are transforming. Skills that paid well yesterday are losing value today.

To maintain your standard of living, you need to grow. But growth doesn’t stall because of technology. Not because of your stack. Not because of certifications.

It stalls because of how you think.

Strong professionals get stuck. Not because they lack knowledge. But because there are internal blockers that are hard to see on your own.

I’ve been working with system architecture for over fifteen years. And in recent years I’ve noticed: the most serious bugs aren’t in code. They’re in the heads of people who write that code and manage those who write it.

Here are three patterns I see most often. In others. And in myself.

Blocker 1: Territory defense

Every leader has a zone of responsibility. And any entry into it feels like an attack. It’s instinct - like a predator patrolling its boundaries.

What it looks like

Imagine this. You’re an architect. A system analyst on your team starts making architectural decisions independently. Doing a decent job, but without checking with you. You see the result - the decisions work, but you feel an irritation inside that’s hard to explain rationally.

In a meeting, you start pushing back. Not because the decision was bad - but because it was made without you. Officially you’re talking about quality and process. In reality, you’re defending territory.

Another example. A team lead notices that a senior on the team is starting to take on architectural questions. Instead of giving space and helping them grow, the lead tightens control. More reviews. More approvals. More questions like “did you think about…”. Officially - concern for quality. In reality - fear of becoming unnecessary.

Why this is a blocker

The problem isn’t defense. Protecting boundaries is normal.

The problem is HOW you defend them. From confidence in your abilities - or from fear that something will be taken away? The first is leadership. The second is aggression that people feel. And they leave.

If we draw an analogy with systems: it’s like a microservice that instead of providing an API for interaction, closes all ports and returns 403 to every request. Technically it works. But the system around it degrades.

The skill

Distinguish real threats from phantom ones. One question to yourself: “am I protecting quality right now - or protecting my ego?”

Blocker 2: Craving recognition

This is really about feedback.

What it looks like

You did excellent work. Designed a system that handles the load. Ran a review process that raised code quality across the team. Solved a problem that nobody could crack for six months.

And silence. Nobody came over and said “great work.” Your manager is quiet. The team took the result for granted.

In that silence, your brain starts filling in the gaps: “I must be doing a bad job.” Or worse: “they don’t value what I do.”

A familiar story: an architect built an API review process for system analysts. Specification quality went up. Integration-phase bugs went down. But the manager never once said “good work.” At some point the architect started wondering - was it even worth spending time on this.

Another example. A senior developer spent a month refactoring a critical module. Code got cleaner, tests more reliable, deploy time cut in half. At the retro, nobody even mentioned it. The senior started losing motivation - not because the work was meaningless, but because nobody noticed.

Why this is a blocker

In adult life, nobody will come and say “well done.” Parents did that. At work - silence. And in that silence, your brain starts making things up.

Looking at it as a system: you have no observability for your own value. No metrics, no dashboard, no alerts. You’re working blind and relying on a single indicator - external praise. And that indicator is unreliable. It depends on your manager’s mood, on company culture, on a thousand factors you don’t control.

The skill

Either learn to ask for feedback - that’s not weakness, it’s maturity. Or build an internal foundation that doesn’t depend on other people’s words.

Practically: keep your own achievement log. Once a week, write down what you did and what effect it had. In six months you’ll have an objective picture - regardless of whether your manager noticed.

Blocker 3: The experience trap

Deep experience creates an illusion: “I know more, therefore I’m owed something.”

What it looks like

A meeting. You’re the most experienced person in the room. A junior proposes a solution. You see problems in it. And instead of asking a question - “what happens at 10x load?” - you say: “no, that’s not how it’s done, I’ve been doing this for ten years and I know.”

Technically you’re right. The solution might not handle the load. But you killed two things: the junior’s initiative and the team’s ability to learn to think independently.

Another example. An experienced team lead joins a new team. They have three successful projects behind them using a specific stack. The team uses a different approach. Instead of understanding why that approach was chosen, the lead starts pushing their own. Not because it’s better - but because it’s familiar. And because accepting someone else’s approach means accepting that your experience isn’t universal.

I catch myself doing this. Sometimes I push with experience instead of listening. And every time I catch myself, I ask: am I teaching right now - or proving?

Why this is a blocker

The world is transforming. Old patterns are breaking down. In the age of AI, yesterday’s expert is learning from scratch today. Experience is valuable, but it’s not currency to exchange for submission.

As a system analogy: it’s a legacy service with hardcoded configuration. It used to work perfectly. But the world around it changed, and it still expects requests in the old format. And instead of adapting its API, it demands that everything else adapts to it.

The skill

Treat colleagues as equals. Regardless of the experience gap. This doesn’t mean ignoring your experience - it means sharing it through questions, not through pressure.

Three blockers. Three skills. None about technology

Territory defense, craving recognition, the experience trap. These patterns can’t be solved by reading books or taking courses. They’re embedded in your thinking architecture so deeply that they’re hard to see on your own.

Like in any project: to see architectural problems, you need an outside perspective. The one inside the system sees individual symptoms. The one outside sees the pattern.

Leadership starts not with the architecture of systems, but with the architecture of thinking. And if you feel stuck - maybe it’s not that you don’t know enough. Maybe it’s time to look at your thinking as a system and run an honest audit on it.