В IT чудес не бывает

Как из тимлида стать хорошим мидл менеджером (RnD), что помогает?

"Сделаем шаг назад" (с) 🫣
Вспомните, что вас драйвило, когда вы были лидом.
Решенная собственными руками сложная проблема/бага? Развернутые комментарии к код-ревью? Проведенный мега-рефакторинг?

Или собранная заряженная вовлеченная команда? Решение проблем на стыке команд?

Вот если первые пункты, то подумайте еще раз, надо ли вам это все?
Чем выше, тем меньше кода. Меньше решенных за осязаемое время задач с финальным результатом. Больше желания плюнуть и порешать проблему самому.
Это не ваш трек для роста. И да, шансов и пространства для роста и карьерного маневра по технике обычно больше, чем в менеджерском треке.

А если вы про людей, процессы, взаимодействие, то welcome on board, как говориться.

И все же, что же поможет?
Хорошо, если тимлид смотрит вокруг, за пределами своей команды.
Плотно общается с другими лидами, подмечает полезные моменты или моменты, которые не стоит у себя делать.
Переход выше, это, скорее всего, быть руководителем руководителей. Поэтому нужно уметь в их обучение.

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

Потом туда-сюда, бац, и у вас уже сотрудники возраста ваших детей, а вы, как моя любимая сосна на болоте.

PS ну и да, смотрите ожидания от менеджеров у Гугла, там все по делу

#management #развитие

Проект Oxygen (Google) или как Гугль от менеджеров пытался отказаться и что такое хороший менеджер по их мнению:

1. Is a good coach
2. Empowers team and does not micromanage
3. Creates an inclusive team environment, showing concern for success and well-being
4. Is productive and results-oriented
5. Is a good communicator — listens and shares information
6. Supports career development and discusses performance
7. Has a clear vision/strategy for the team
8. Has key technical skills to help advise the team
9. Collaborates across Google
10. Is a strong decision maker

#management

Психологическая безопасность и ее влияние на производительность команды по результатам проекта Аристотель (Google).

Understand team effectiveness - подробнее про исследование и что еще влияет на эффективность команды.
• Психологическая безопасность (обстановка, в которой сотрудники не боятся брать на себя риски, выражая собственную точку зрения, делятся опасениями, задают вопросы и генерируют идеи)
• Надежность (взаимосвязь членов команды друг с другом)
• Структура и четкость (члены команды имеют четко установленные функции, планы и задачи)
• Осмысленность (каждый знает ответ на вопрос, почему он здесь работает)
• Воздействие (каждый сотрудник понимает свой вклад в общее дело)

#management #процессы

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

А вообще я консерватор:
2019(c)

Мне тут недавно "прилетело", что я "склонен использовать консервативные подходы в работе с ожидаемым результатом в итоге."
Да, чего уж там, похоже на правду. Именно потому, что мне нравится "ожидаемый результат".

Ну а раз консерватор, то можно и побрюзжать...

"Новшества и инновации" - это, чаще всего, то что благополучно забыли или даже не пытались узнать, и переизобрели заново. Мой брошенный английский блог так и назывался "Все новое - это хорошо забытое старое".

PS Скрин вот с этого сообщения (если захочется поставить лайк или наоборот поспорить).
PS2 ха, а забытому блогу на английском уже 15 лет (исполнилось бы)

#развитие

Главное не перегибать палку и не быть излишне пессимистичным (это я себе, снова и снова).

Be Productively Pessimistic

Don't just be needlessly negative about things, but don't let yourself be blindsided by problems you could get ahead of with a little pessimism.

#процессы

Сегодня пророческий твит 10-летней давности вместо #it_memes ...
Сходил вчера на митап "От бирюзовых грез к бережливой реальности".
Уже забыл, когда был в последний раз.
Понял, что социофубушек за это время прочно поселился в моих мозгах. Просто подойти к кому-то незнакомому и начать беседу уже сложно 🙃
Мне уже комфортнее пребывать в режиме "старца", к которому подходят с вопросами 🤣 (но хорошо, что не подходят).

Но, зато визуализировался с Женей Антоновым.
Доклад Жени был лайтовый, я бы сказал ламповый, для олдов, с примерами прям из моей жизни. А про бирюзу, и не только, недавно тут в комментах "на кухне" обсуждали.

У Оли Елисеевой было интересно. Лайк. Особенно триггернуло совпадение текущих мыслей в голове с ее советами.

На круглый стол я не остался, надо глянуть запись.

ЗЫ немного крафто-фоток в комментах. В селектеле все так же и паспортами на входе тоже ))

#байки

У меня тут уже были неплохие недельные рассуждения про юнит-тесты.
Сложно придумать что-то еще, просто выбирайте тот уровень написания тестов, который вам удобнее и быстрее закрывает ваши проблемы/потребности.

#test_automation #unit_testing

1е следствие закона Конвея:

Лучший способ запустить реархитектуризацию продукта - поменять оргструктуру/подчинение команд, которые его разрабатывают.

#it_философия

Я бы не сказал, что это именно "стадии" (для меня это слово определяет возможность перехода из одного в другое).
Очень часто все застревает в одном состоянии определяемом именно руководителем в соответствии со своим типом руководства и, частично, уровнем осознанности сотрудника.

Но, если у руководителя получается превратить это именно в стадии перехода - это круто.

1. Стадия "Инструкция"
Подчинённый: “Скажи, что делать”
Начальник: “Я всё проконтролирую”
Тотальное недоверие, замаскированное под "структурность". Начальник боится провалов, подчинённый — ответственности. Микроменеджмент встречает инфантилизм. Все несчастны, но чувствуют себя в безопасности.
2. Стадия "Цель"
Подчинённый: “Обозначь результат, остальное я сделаю сам”
Начальник: “Я ставлю понятные задачи”
Начинается игра в менеджмент: цели, KPI, дедлайны. Начальник учится отпускать контроль, подчинённый — брать инициативу. Пока они синхронизированы, всё работает. Пока.
3. Стадия "Проблема"
Подчинённый: “Расскажи, в чём суть затыка — решение найду сам”
Начальник: “Я создаю условия, где люди сами решают”
Рождается мышление. Причем у обоих. Начальник учится формулировать проблемы, подчинённый — разбираться в сути, а не ждать команды. Появляется новый невроз: а вдруг всё развалится?
4. Стадия "Смысл"
Подчинённый: “Зачем я вообще всё это делаю?”
Начальник: “Я помогаю думать”
Это уже не про задачи, не про цели и даже не про проблемы. Это про картину мира. Руководитель больше не раздаёт указания и даже не формулирует затыки — он очерчивает контекст, рамку, в которой мысли вообще обретают форму. Он предлагает систему координат, где "успех", "важное", "ценное" — это не KPI, а культурный код. А подчинённый — уже не исполнитель и не соло-решатель, а соавтор. Он сам ищет, формулирует и решает проблемы, потому что понимает, где он и зачем.

Ну и конфликты в этом всем - это скорее не конфликты, а расхождение ожиданий.

ЗЫ или это стадии роста менеджера.

#management

Что делает код обычно понятно и без комментариев рядом (ну или точно разберетесь спустя какое-то время).
А вот для ответа на “зачем он это делает” и “почему именно это” как раз и нужна документация. И без нее, спустя буквально полгода, никто уже ничего не помнит.

#мысли_вслух

Не бывает серебряных пуль, но бывают неправильно выбранные для конкретных ситуаций решения, которые могли бы сработать в других условиях.
Талант состоит в балансе между:
• "мы так раньше делали - не работает, отбрасываем"
• "мы так раньше делали - не работает, но давайте попробуем ещё раз"
• "я так всегда делал - значит и тут сработает"
• "все так делают - значит и нам надо"

Вся магия в контексте: люди, процессы, ожидания, сроки, бюджет.

Прямо как "каша из топора", моя любимая аллегория последнее время. Вроде все просто, но есть нюансы.

#мысли_вслух

Благодаря вчерашнему доброму слову Жени канал резко прирос подписчиками.
Люди добрые, прозрачности ради и опережая #ваши_вопросы, тут конечно есть немного пользы

"Какой бы совет №1 вы дали менеджеру-новичку?"
Как я ответил на этот вопрос: "Будь готов к тому, что теперь твоя работа - это делать работу мозгами и руками других людей без наблюдения ощутимого результата своего труда в моменте здесь и сейчас".

сарказм-философии

“Кто-то застревает в мидл-менеджменте и, как сосна на болоте, не растет в высоту и только уплотняет годовые кольца. Кстати, фан-факт, такие сосны плохо гниют, но зато отлично горят.”

но больше всего нудящего сурового реализма

Софт-скилы под давлением временем только твердеют и замещают собой старые хард-скилы, которые превращаются в песок - путь менеджера

Поэтому без иллюзий, плиз. Чудес не будет 😉

Зато есть #it_memes (самая популярная рубрика)

Советы от офисного буддиста:

— Тебя перебивают на встрече? Молчи. Будда тоже молчал. Его в итоге слушали.
— Не позвали на важный звонок? Это не обида. Это освобождение от 40 минут боли и новой задачи.
— Всё сделал, а заслуги достались другому? Радуйся. Теперь он отвечает.
— Пишут в 18:01 “чекни”? Не реагируй. Даже перерождения идут по графику.
— Задача без контекста? Задай три вопроса. Если не ответят — это не задача. Это шум.
— “Зачем аналитика, у нас же есть ChatGPT”? Улыбнись. У нас есть микроволновка. Но мы зовём повара.
— “Сделай за 5 минут” обсуждают неделю? Просто спроси: “А зачем мы это делаем?” Иногда спасает проект. Иногда людей.
— Все говорят “эффективность”, “гибкость”, “ценность”?
Трава не растёт быстрее, если за неё дёргать. Иногда лучший вклад — уйти пораньше.
— Задач больше, чем мыслей? Сделай себе чай. Смотри в окно.
Ничего не изменится. Но ты — изменишься.
— Всё кажется бессмысленным? Это не выгорание. Это ты увидел систему как она есть.
— Никто не понимает, чем ты занимаешься?
Поздравляю. Это и есть просветление.
— Устал, но хочешь доделать «последнюю таску»? Закрой ноут.
Если станет плохо — это не усталость. Это зависимость.

Всем хорошей недели, благо для многих она по умолчанию хорошая, потому что всего 3 рабочих дня.

#it_философия #байки

As software developers, we often think our job is to develop software, but, really, that is just the means to an end, and the end is to empower business to reach their goals. Your code may be elegant, but if it doesn't meet the objectives (be they time or business) it doesn't f***ing work.

Your Code May Be Elegant (2012)

#it_философия

Каждый раз читая (даже не в первый раз) статьи "X vs Y" ловлю себя на мысли "хмм, а я по-другому думал".
И потом, спустя N-лет, снова тот же эффект.
Вот и в этот раз, "о, как...".
"Smoke test VS Sanity test"
Понапридумывают терминов, а потом все путаются 🙂

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

#testing #мысли_вслух

И еще про удаленки, гибриды и то, влияет ли это на эффективность работы

По мотивам недавнего (весеннего?) обострения по тестам.
Все тесты, любые тесты, даже руками, прости меня святой Байт, важны.
Если одни прошли - это мало что значит.
Пятнично-задумчивые #it_memes

Возможно я, как это часто бывает, снова прочитал, то что хочется прочитать. Но очень похоже на мои мысли:

Или "мы не продумали архитектуру". Да не можете вы продумать архитектуру навека, у вас требования к продукту меняются каждые полгода. Все что можно и нужно попытаться "продумать" - это то, как быстро менять реализацию. А быстро - это только с тестами получится, но на них часто забивают (времени много ведь занимают)...

Lean Architecture It is high time to ‘kill’ Clean Architecture, the Hex, the Onion and the VSA and come up with something better

3 important points in creating a maintainable solution:
Step 1: Analysis of the problem and the stakeholders.
Step 2: Analysis of the current use case.
Step 3: Modelling
Step 4: Implementing the different pieces and their tests
Step 5: Dependency management

At all times, we keep our goal in mind. Because the process itself does not account for Lean Architecture. With every decision we try to evaluate if it brings us closer to our goal of maintainability or not. We fix the design problems we have now. We don’t try to fix possible changes that have yet to come. This is the hard part, deciding when to add more design. This becomes easier when you truly understand the design problems that certain techniques and principles solve.

И небольшое продолжение в виде скрина в комментах.

#tech_read #holywar

Your Strengths Are Your Weaknesses

The goal isn’t to create “balanced” engineers with no pronounced strengths or weaknesses. That’s just impossible. We want self-aware engineers who understand their natural tendencies and can adjust them based on what each situation demands.

#management

Банальная категоричность.
Думать “как будем реализовывать фичу” всегда должно быть равно “как будем делать” + “как будем проверять”.
Да, вот так вместе.
Да, не по отдельности разработчики и QA (aqa-люди, как же я вас не люблю, терпения мне).
Да, если реализация (еще раз = новые продакшен код + тесты) не соответствует DoD, значит мы непонятно, что релизим.

И значит, если разработчики написали код, но его никто (включая их) не проверил - значит мы написали бесполезный код, который работает стохастическим образом.
Внимание вопрос - зачем нам нужен такой код?

Не хотите писать автотесты - проверяйте руками. И да, автотесты - это не только юниты.
Не хотите проверять свой код, думая, что для этого есть тестировщики - подумайте, действительно ли вы хороший специалист.
ЗЫ Да, можно релизить без автотестов, чего уж там. Только не надо переводить стрелки на автоматизаторов.

#мысли_вслух #test_automation #testing #holywar