Я возглавляю стрим Компьют (Вычислительные Ресурсы, говоря проще) в быстрорастущем облачном провайдере с осени 2024 года. Мы (и стрим Сетей) отвечаем на облачные примитивы, на которых строятся буквально все другие облачные продукты. За это время стрим столкнулся с настоящими вызовами, некоторые процессы пришлось выстраивать.
Проходя интервью на управленческие позиции в IT (например, Team Lead), часто можно попасть на секцию по опыту менеджмента командой. Казалось бы, рассказываешь о своем опыте, о принятых решениях и в целом о том, как успешно твоя команда выпускает релизы...
Пока тебя не спросят «Ну а как ты понимаешь, что команда работает хорошо?».
Или ты вроде все делаешь «правильно» на проекте, но недовольство заказчика растет, и твои люди подают заявления, потому что выгорели.
И в голове щелкнет: что‑то я, видимо, упускаю.
Я расскажу вам о своем опыте тимлида командой разработки в крупном банке, где старые управленческие привычки иногда брали верх над здравым смыслом. Это субъективная точка зрения на реальную ситуацию, где я - Д’Артаньян, а все остальные - редиски.
Привет!
Внутренние продукты умирают чаще, чем живут. Причём гибнут не на проде, не из‑за кривого кода и не от того, что разработка пошла не по плану. Они разваливаются на самом старте — когда гипотеза ещё не успела обрести форму, но уже обросла Jira‑задачами. Где‑то я видел, что 9 из 10 новых инициатив не переживают первую встречу с пользователем. Почему? Потому что команды бегут в реализацию, не удостоверившись: а надо ли это вообще кому‑нибудь?
Я лид команды – и хочу идти дальше вверх! Точнее, не уверен, что хочу, но в айтишке надо ведь расти и развиваться, значит, следующая позиция для меня — менеджмент на уровень выше. Или нет?
Привет!
Если ваши 1:1 — это «ну, поболтали и разошлись», а менторство выматывает сильнее, чем два продакшн‑инцидента подряд, значит что‑то не так. В этой статье рассмотрим эту проблему.
Выглядит это так:
Вы ставите себе задачу: «Хочу быть ближе к команде. Хочу прокачивать ребят. Буду делать 1:1».
Проходит 3 недели — и вы уже ненавидите календарь. Каждая встреча — это:
Повторы («Ну как дела?» — «Норм»).
Груз («Опять проблемы, опять я должен решать»).
Ноль эффекта (люди не растут, просто ноют, или вообще не говорят).
Почему митинги, Jira и рабочие чаты делают хуже, чем дедлайны, и как тимлидам научиться управлять энергией команды (и своей).
Ты вроде уже не джун. И не просто мидл, который «хочет роста». Ты тот самый человек, у которого всё под контролем: ты ведёшь команду, пишешь сложный код, иногда — даже с удовольствием. У тебя есть архитектура, ответственность и график в Google Calendar, в котором нет дыр. И всё же...
Недавно в кругу старых друзей мы обсуждали, что вообще значит быть senior-разработчиком. И в какой-то момент один из них задал резонный встречный вопрос:
«А как назвать разработчика, который технически силён, кодит быстро, но при этом не делится знаниями и работает строго в одиночку?»
После короткой паузы ответ прозвучал просто и жёстко — накопитель риска (Risk Accumulator).
В этой статье разберём, откуда берутся такие одиночки, почему это опасно и как с этим бороться.
Недавно в кругу старых друзей мы обсуждали, что вообще значит быть senior-разработчиком. И в какой-то момент один из них задал резонный встречный вопрос:
«А как назвать разработчика, который технически силён, кодит быстро, но при этом не делится знаниями и работает строго в одиночку?»
После короткой паузы ответ прозвучал просто и жёстко — накопитель риска (Risk Accumulator).
В этой короткой статье разберём, откуда берутся такие одиночки, почему это опасно и как с этим бороться.
Привет! Меня зовут Лера, я технический писатель в Авито. Очень люблю книги, которые помогают быть лучше в работе: эффективнее общаться с командой, принимать решения, развивать коллег и расти самой. Поэтому сегодня делюсь с вами разбором одной из таких книг — «Радикальная прямота» Ким Скотт.
