Согласен полностью с вашим выводом — если выбрать карьерой управление и, соответственно, не иметь достаточно времени на программирование, неизбежно квалификация техническая будет теряться. Мне в такой ситуации кажется логичным наращивать квалификацию и знания в управлении и расти именно в этой области.
В любом случае, это выбор другой профессии, отличной от разработки.
Считаете ли вы допустимым для тимлида не иметь практики программирования?
Допустимо, как мне кажется, вообще что угодно, посредственный художник может захватить значительную часть мира, например. Без навыков и опыта программирования тимлиду будет значительно сложнее, придется выстраивать процессы так, чтобы этот недостаток нивелировать.
Должен ли тимлид являться Tech Lead, т.е. искать и внедрять новые технологии?
Я бы тут отталкивался от требований бизнеса, сложно ответить на такой вопрос абстрактно. Может, Ваша система написана на COBOL'е и поддерживается и дорабатывается пятью семидесятилетними программистами? Вряд ли будет уместно тимлиду в такой ситуации искать и внедрять что-то новое :)
А мне кажется, что лидерские качества просто помогают легче выстраивать правильную атмосферу в команде, и, соответственно, полезны, наверное, любому управленцу.
Как думаете кто больше подойдет для тимлида: великолепный разработчик с посредственными коммуникациями или посредственный разработчик душа компании
Мне сложно ответить «абстрактно» — как лидерские качества, так и технические знания можно наработать, а вот требуемые на это инвестиции ресурсов будут очень различаться в зависимости от требований бизнеса к этой роли и от личностей кандидатов.
При этом, на мой взгляд, очевидно, что наращивание всяческого EQ/эмпатии и проч будет сильно более трудным процессом, чем наращивание технических навыков.
Может ли тимлидом быть чел. с немаксимальными техническими знаниями, как он будет принимать решения?
Принимать решения он может, например, основываясь на максимальных технических знаниях кого-то из подчинённых. Безусловно, это может вырасти в проблему, но можно стараться находить всякие обходные пути. В любом случае, лучше иметь хороший баланс — и большой общий технический опыт, и хорошие знания в предметной области, и лидерские качества.
Vearutop, не совсем понимаю про «перекладывание бумажек в jira» :)
Перспективы роста разработчика очень сильно зависят от компании. Навскидку: расти в сторону технического лидерства, можно брать большие проекты и вести их, брать на себя целые направления межкомандные (скажем, становясь спецом по безопасности).
Это очень по-разному везде, даже внутри нашей компании есть тимлиды, активно участвующие и в продуктовой разработке, а бывают и такие, которые код в руках не держали достаточно долго.
Думаю, мой начальник не выдержал бы нагрузки, если бы приходилось контролировать такие мелочи. Не понимаю, почему мотивация на challenge у Вас вызывает какой-то сарказм, честно. У всех разная мотивация же.
Про время — сейчас я работаю с 9 до 7, иногда и раньше ухожу. Переработки случаются тогда, когда ну уж очень интересное что-то делаю и не могу оторваться :)
С кодом последние полгода не работаю вообще, но планирую в этом квартале уже начать выделять время.
Я перешел в тимлидство потому, что мне нравится и хочется этим заниматься :) Да и после определённого уровня зарплата перестаёт становиться основным мотивирующим фактором, важнее становится уже другие вещи — challenge и рост, например. По крайней мере, для меня так.
Ну а правильный рост оценивается и материально тоже.
Во многих компаниях зарплаты даже внутри команды разработки могут сильно различаться по множеству причин, что уж говорить о разнице в оплате так сильно различающихся должностей тимлида и разработчика. Иногда может быть вполне нормальным, что тимлид получает меньше одного разработчиков, и сам будет требовать ещё большего повышения зарплаты этого разработчика :)
На мой взгляд, нужно просто понимать, что должность тимлид — это старт карьерной лестницы в управлении, а там и другие метрики оценки, и совсем другое развитие.
повезло, в основном работает принцип «кто везет на том и едут»
Если я правильно понял, Вы о ситуации, когда ответственностей «накидывают» больше и больше, но не дают обратной связи по результатам. В таком случае, это вопрос не везения, а сознательного выбора компании.
Мой классический ответ на предложение занять подобную должность: у меня нет управленческого образования — оплачивайте и ждите. Пока, максимум, курсы предлагали на пару месяцев без отрыва от производства.
Два месяца — это же прекрасно :) Хорошие курсы, да за два месяца, да при постоянной практике, дать могут ого-го сколько!
Главная причина такого завуалированного отказа — понимание того, что я не смогу в плане технического развития достаточно быстро бежать чтобы хотя бы на месте оставаться.
Я вижу, что при хорошо построенных процессах и атмосфере в команде, ну и до определённого размера команды, конечно же, все же остается вариант «hands-on» работы, где остается достаточно времени на сохранение технической квалификации. Однако, конечно, есть вероятность и того, что погрузиться в управление придется полностью, и тут уже нужно выбирать :)
Ну и, как правило, предложения были связаны с полной ответственностью за результат команды, но без права как-то заметно решать вопросы материальной и административной мотивации.
Согласен полностью, без мотивационных инструментов работать намного труднее.
правильно ли я понимаю, никакой синхронизации состояния залогиненности между opera turbo и opera mini нет? Переключил режим — перелогинивайся на всех сайтах?
Когда выбирал плейер себе для бега, смотрел на ipod shuffle 2g и 3g, но когда увидел Philips SA018102K — сразу купил — размером он меньше, чем iPod Shuffle 3g, твёрдая и крепкая клипса, цена — около 1500 рублей, аккумулятор держит 8 часов стабильно, iTunes не нужен — подключается как флешка, заряжается тоже только от USB. В общем, грамотный дешёвый клон iPod shuffle. Всем советую :)
В любом случае, это выбор другой профессии, отличной от разработки.
Допустимо, как мне кажется, вообще что угодно, посредственный художник может захватить значительную часть мира, например. Без навыков и опыта программирования тимлиду будет значительно сложнее, придется выстраивать процессы так, чтобы этот недостаток нивелировать.
Я бы тут отталкивался от требований бизнеса, сложно ответить на такой вопрос абстрактно. Может, Ваша система написана на COBOL'е и поддерживается и дорабатывается пятью семидесятилетними программистами? Вряд ли будет уместно тимлиду в такой ситуации искать и внедрять что-то новое :)
Мне сложно ответить «абстрактно» — как лидерские качества, так и технические знания можно наработать, а вот требуемые на это инвестиции ресурсов будут очень различаться в зависимости от требований бизнеса к этой роли и от личностей кандидатов.
При этом, на мой взгляд, очевидно, что наращивание всяческого EQ/эмпатии и проч будет сильно более трудным процессом, чем наращивание технических навыков.
Принимать решения он может, например, основываясь на максимальных технических знаниях кого-то из подчинённых. Безусловно, это может вырасти в проблему, но можно стараться находить всякие обходные пути. В любом случае, лучше иметь хороший баланс — и большой общий технический опыт, и хорошие знания в предметной области, и лидерские качества.
Перспективы роста разработчика очень сильно зависят от компании. Навскидку: расти в сторону технического лидерства, можно брать большие проекты и вести их, брать на себя целые направления межкомандные (скажем, становясь спецом по безопасности).
Это очень по-разному везде, даже внутри нашей компании есть тимлиды, активно участвующие и в продуктовой разработке, а бывают и такие, которые код в руках не держали достаточно долго.
Про время — сейчас я работаю с 9 до 7, иногда и раньше ухожу. Переработки случаются тогда, когда ну уж очень интересное что-то делаю и не могу оторваться :)
С кодом последние полгода не работаю вообще, но планирую в этом квартале уже начать выделять время.
Вот Наталью как тренера очень сильно рекомендую, программу она подберет сообразно бизнес-требованиям и запросам идеально.
Ну а правильный рост оценивается и материально тоже.
Во многих компаниях зарплаты даже внутри команды разработки могут сильно различаться по множеству причин, что уж говорить о разнице в оплате так сильно различающихся должностей тимлида и разработчика. Иногда может быть вполне нормальным, что тимлид получает меньше одного разработчиков, и сам будет требовать ещё большего повышения зарплаты этого разработчика :)
На мой взгляд, нужно просто понимать, что должность тимлид — это старт карьерной лестницы в управлении, а там и другие метрики оценки, и совсем другое развитие.
Если я правильно понял, Вы о ситуации, когда ответственностей «накидывают» больше и больше, но не дают обратной связи по результатам. В таком случае, это вопрос не везения, а сознательного выбора компании.
Два месяца — это же прекрасно :) Хорошие курсы, да за два месяца, да при постоянной практике, дать могут ого-го сколько!
Я вижу, что при хорошо построенных процессах и атмосфере в команде, ну и до определённого размера команды, конечно же, все же остается вариант «hands-on» работы, где остается достаточно времени на сохранение технической квалификации. Однако, конечно, есть вероятность и того, что погрузиться в управление придется полностью, и тут уже нужно выбирать :)
Согласен полностью, без мотивационных инструментов работать намного труднее.