#chad fowler

O grau de formalidade num relacionamento de mentor não é importante. Ninguém precisa explicitamente pedir a alguém para ser seu mentor (embora não seja definitivamente uma coisa ruim se você o fizer). Na verdade, seu mentor pode nem saber que está fazendo esse papel para você. O que importa é que você tenha alguém de confiança e que admire, que possa proporcionar uma orientação à sua carreira e ajudar a afiar seu ofício.

O primeiro e mais importante propósito de um mentor é ser um modelo a seguir. É difícil saber o que é possível ser feito até que você veja alguém que possa ir além dos limites que você conhece. Um modelo estabelece o padrão do que ‘bom’ significa. Se você se imaginasse como um jogador de xadrez, por exemplo, só o fato de poder vencer as pessoas de sua família imediatamente pode ser muito bom. Contudo, se você jogasse contra um competidor de campeonatos, você descobriria que o xadrez é um jogo muito mais denso do que você jamais pensava. Se você fosse jogar contra um grande mestre, você teria outra revelação. Se você continuasse jogando e derrotando apenas os membros de sua família, você poderia ficar com a ideia de que você é realmente bom no xadrez. Sem um modelo a seguir, não há incentivo para melhorar.

No mundo profissional tradicional (e especificamente na área de TI), nós estamos menos propensos a pedir ajuda uns aos outros. Depender dos outros é frequentemente visto como um sinal de fraqueza. Temos medo de admitir que não somos perfeitos. Tudo é competição. Apenas os fortes sobrevivem, e isso é tudo. Infelizmente, isso leva a um sistema de mentoria extremamente subdesenvolvido. Se tivéssemos que perguntar a um grupo de músicos de jazz: ‘Quem é seu mentor?’, a maioria deles teria uma resposta. Agora faça a mesma questão para programadores. Nos Estados Unidos, eles provavelmente responderiam: ‘O quê?’

Alternatives to Crunch-Mode Miss the deadline. Ya, that’s right. Let your customers down this time. Make less money. Incur opportunity cost. Just fail. You already failed to manage your team and your time. Maybe you should let that have more visible consequences? Set smaller goals. When you set a massive goal, way off in the future, it’s impossible to estimate whether it’s actually realistic. However, if you set a goal for this afternoon, you’re probably going to be pretty accurate with your estimates. Measure progress concretely and in small steps. Never trust a status report, even from yourself. In software, the only deliverable that matters is one that you can execute. Set more realistic goals for the team and problems you face. If you’re continually having to slip into Crunch Mode, you clearly don’t understand your capabilities. Admit that you’re going to go slower than you expected and adjust for it.

A Compelling Reason for Change: The Harujuku Moment

Add Empathy to Your Skill Set