Categoria: Carreira

Como você lida com conflitos (entre pessoas)?

geekandpoke

O que me deixa preocupado sempre que vou escrever sobre um desses temas é que o leitor deve achar que eu não faço ou nunca fiz besteira na vida. Sim, eu fiz, e bastante. O que me deixa ligeiramente confortável em escrever um post desses é que talvez eu tenha aprendido um pouco sobre elas e ao menos percebo as falhas que antigamente nem sabia que estava cometendo.

A algum tempo, principalmente depois de observar melhor um “time” trabalhando junto motivado pela integração que as metodologias ágeis promovem, comecei a levar muito mais a sério o tema de soft skills, ou competências interpessoais ou habilidade de lidar com gente. Chame como quiser.

O fato é que desenvolvedores tem opiniões fortíssimas sobre muitas coisas e é muito freqüente ter discussões improdutivas simplesmente para saber quem está certo ou errado, sendo que muitas vezes os dois estão certos ou os dois estão errados. É bem desgastante para qualquer empresa, líder ou gerente administrar esses conflitos.

Quando estou entrevistando candidatos eu sempre gosto de puxar um pouco para esse lado. Tento colocar pessoas no time que não só possam trazer contribuições técnicas, mas também contribuições ao ambiente e à sintonia do time. E não é raro recusar candidatos muito bons tecnicamente porque eles não seriam bons para o time no aspecto pessoal. Escrevo esse post motivado por dois candidatos que recusei por causa dos soft skills.

Um dia eu li num desses posts sobre recrutamento uma ótima pergunta (eu não uso essa): “Conte-me sobre um conflito que você teve no ambiente de trabalho e como você fez para resolvê-lo”. Essa pergunta caiu que nem um raio na minha cabeça por duas razões: eu tinha dificuldade de reconhecer os conflitos que eu tinha e talvez nunca tivesse conseguido resolver um. Se me fizessem essa pergunta numa entrevista, eu seria recusado imediatamente.

Se você responde: eu nunca tive conflitos. Caramba… você é o mestre da convivência! Se você responde: já tive mas não consegui resolver, vc assume sua incompetência interpessoal. Se você não consegue citar um exemplo prático, você não consegue evidenciar que tem o skill e perde também. Bela pergunta, não?

Inspirado nesse tipo de pergunta, desenvolvi uma das minhas favoritas adaptadas a desenvolvedores: “Imagine que você está dando manutenção num sistema e recebe um código terrível. Como você lida com essa situação?”

Não, eu não vou dizer qual é a resposta que eu espero, porque meu objetivo é fazer você pensar (aquela pergunta do conflito me rendeu 6 meses de trabalho comigo mesmo), mas compartilho algumas respostas que recebi:

  • “Eu xingo ele (em tom de brincadeira)”. Mas não conseguiu responder a pergunta (interprete a resposta do jeito que achar mais conveniente)
  • “Eu sou adepto do ‘se não está quebrado, não conserte'”. Em outras palavras, eu não faço nada pra resolver o problema (nem técnico, nem interpessoal) e deixo ele lá.
  • “Eu provo pra ele que o código dele é uma porcaria”.
  • Uma longa pausa seguida de um “essa é uma pergunta complicada” e uma seqüência de respostas evasivas sempre levando a discussão mais para o problema técnico do que o pessoal.
  • Milhares de argumentos técnicos sobre o código ruim, sem nem considerar a hipótese de discutir o problema com o companheiro de equipe.

O interessante dessa pergunta e me motiva a escrever esse post é que são raras as respostas satisfatórias para essa pergunta. Quem nunca abriu um código e pensou “que p* é essa?” que atire a primeira pedra.

O fato é que desenvolvedores tem uma paciência enorme para ler um livro técnico de 1000 páginas mas não tem coragem de ler um livro pequeno sobre relações humanas, ou menos perceber a importância disso.

Quando estiver sendo gerenciado ou liderado por uma pessoa que não sabe programar, ou ganhando menos que um vendedor que não sabe o que vende e que vende o que você faz, sugiro que comece a pensar um pouco sobre essa pergunta. #ficaadica

Anúncios

Dicas para se tornar um desenvolvedor mais feliz

Introdução

Durante os anos que tenho trabalhado como desenvolvedor ou liderando equipes de desenvolvimento, venho observando determinados padrões de comportamento nos desenvolvedores ou mesmo nas equipes.

Confesso que já pratiquei bastante esses padrões e caí nessas armadilhas. Superei alguns, outros ainda me pego fazendo e sempre tenho minhas recaídas. Não é fácil para nenhum desenvolvedor esse negócio de habilidades com pessoas.

Resolvi escrever esse post, com o objetivo de ajudar meus companheiros de profissão a superarem determinadas barreiras, seja para o crescimento profissional, seja para ter uma vida mais saudável.

Por que há tanto conflito em desenvolvimento de software?

conflitosA resposta mais correta, verdadeira e sincera é: não faço a menor idéia. Meu melhor palpite, eu compartilho.

Fazer software exige dos desenvolvedores muito esforço lógico e racional. O tempo todo lidamos com coisas abstratas (criamos coisas que a maioria das vezes não são vistas) utilizando linguagens de programação que por definição são linguagens extremamente rigorosas. A máquina não aceita erros. Se tem uma vírgula errada, não compila. Se tem uma instrução errada, compila, mas muitas vezes não funciona. Se deixamos passar um detalhezinho sequer, coisas ruins acontecem.

Dentro desse rigor, existe ainda a necessidade de criatividade. Para resolver problemas é necessário pensar em formas diferentes, caminhos diferentes para chegar na solução. Caminhos estes que precisam ser provados pelo mesmo rigor de um compilador, que não aceita vírgulas erradas.

Para tornar ainda mais complexo esse ambiente que mistura raciocínio abstrato com rigor matemático entra o ingrediente fatal: pessoas. Criar é difícil. Criar coletivamente é uma tarefa árdua. Cada um tem uma experiência diferente e opiniões diferentes sobre uma série de coisas. E o pior, você precisa conseguir sair com acordos desse ambiente para fazer qualquer coisa se movimentar em qualquer direção.

Esse acho que é o papel que mais gosto de ter nas equipes hoje. O de líder técnico. Pra mim o que esse cara faz é: ter conhecimento técnico suficiente para ser respeitado por sua equipe (desenvolvedor não se subordina a quem não respeita) e poder servir como uma espécie de bússola para orientar o time no sentido da solução, facilitar os conflitos e as decisões técnicas e propor as melhorias necessárias no ambiente para que o trabalho tenha fluidez.

Depois de tanto tempo vivendo diariamente esses conflitos, sendo a causa de alguns e a solução de outros, resolvi compartilhar algumas dicas que me ajudaram a encontrar um pouco de paz de espírito.

Muitos profissionais se questionam porque tem dificuldade de ter evolução na carreira e as razões que o impedem de participar de decisões importantes na empresa, produto ou projeto. Pode ser que esse post lhe ajude.

Distinguir perguntas com respostas objetivas de perguntas com respostas baseadas em opiniões

Para muitas coisas em tecnologia, existem respostas do tipo “certo e errado”. A maioria delas os compiladores, documentos de referência tem a resposta. Outras coisas como qual é o algoritmo mais rápido, é bem simples responder usando técnicas como análise de “Big O” ou mesmo implementando o algoritmo. Não é aqui que moram os problemas.

O problema são nas perguntas: Qual solução é melhor, qual é a pior? Pronto. Imediatamente um acha que o banco de dados resolve tudo, o outro acha que tem que por na nuvem, o outro acha que tem que desenvolver tudo do zero e começam as brigas.

As principais coisas que temos que saber é separar respostas objetivas de respostas baseadas numa recomendação ou opinião. Provavelmente no segundo caso se você perguntar para 10 pessoas diferentes, vai ter 10 respostas diferentes e provavelmente mais de uma certa.

A melhor coisa nesses casos é traçar cenários com prós e contras. Não perca tempo tentando convencer o outro que a sua solução é a melhor. O outro pode ter uma opinião diferente. Nesse caso o melhor juiz são os requisitos, as restrições de prazo, custo e recursos.

Saiba reconhecer que por mais que a sua proposta seja a melhor na sua opinião ou a mais bonita do ponto de vista técnico ela pode não ser escolhida por não atender as principais restrições ou objetivos de negócio da empresa. Isso não faz dela uma solução ou uma idéia ruim.

Viver num mundo em que duas pessoas podem ter opiniões diferentes

Esse está relacionado com o anterior. Ter uma opinião diferente ou não convencer o outro que a sua solução é melhor não faz você pior ou melhor do que ele. Apenas são opiniões diferentes sobre o mesmo assunto. Não seria um tanto quanto pretensioso achar que você está certo o tempo todo?

É importantíssimo aceitar que o outro tem uma opinião diferente, por mais que ela pareça absurda para você. Por causa dessa razão muitas discussões do tipo linguagem A é melhor que a B ou linguagem funcional é melhor que orientada a objetos e vice-versa acontecem. Discussões completamente sem fundamento sem um contexto.

Tirar bom proveito de discussões e saber o momento certo de pular fora delas

Se aprendemos a aceitar que o outro pode ter uma opinião diferente da sua, discussões passam a ter um sabor diferente. Invés de parecerem um duelo infinito que só termina quando o oponente sangra até a morte (ou simplesmente a energia esgota após ofensas intermináveis, como nas listas de discussão), a discussão passa a ser um palco para troca de experiências e aprendizado.

Quando você discute com uma pessoa com ponto de vista diferente do seu, tem uma oportunidade enorme de aprender uma nova perspectiva sobre um mesmo assunto. Invés de ficar tentando provar que o que você faz é o melhor, você passa a entender as razões por trás das ferramentas, técnicas e tecnologias utilizadas pelo outro. Logo, mesmo que no final das contas não concorde com ele, com certeza não sairá da discussão no zero a zero.

Em arquitetura esse tipo de discussão é riquíssima, pois mesmo tendo duas soluções, frameworks ou técnicas de design diferentes aplicados, conseguimos entender as motivações que fazem a pessoa escolher um caminho diferente e potencialmente as conseqüências da decisão tomada.

O melhor momento para pular fora de qualquer discussão é quando acaba a exposição de argumentos. Não tem mais o que explorar nos argumentos e ninguém mudou de opinião, muito bem. Vamos esperar entrar algum novo insumo na discussão para progredir à partir dali. Se uma decisão precisa ser feita, alguém vai ter que ceder. Então o próximo tópico pode ajudar.

Comprometer-se com aquilo que não concorda

Qualquer profissional consegue se comprometer e se engajar com aquilo que concorda. Por isso não é incomum aquelas cansativas reuniões que as pessoas empurram um compromisso goela abaixo, compromissos que são mais aceitos pelo cansaço do que pelo mérito.

Difícil mesmo é seguir adiante com aquilo que você não concorda. Ninguém quer ceder.

Se as conseqüências daquela decisão são pequenas, reveja sua posição. Será que não vale a pena abrir pequenas concessões para não levar aquela fama de inflexível na hora que precisar tomar uma decisão com impactos realmente grandes?

Se você percebe que está num impasse e vai ser impossível construir um consenso, justifique as razões que o fazem discordar daquela decisão, por exemplo, mostrando as possíveis conseqüências e mesmo assim se comprometa com ela.

O que para mim torna essa opção interessante é que mesmo muitas vezes sabendo que as coisas não estão do jeito que você gostaria, você tem a chance dos fatos ajudarem as suas idéias a ganharem mais força, enquanto ficando no impasse você tem a certeza de não ir para lugar nenhum, ou pior ainda, ser simplesmente tirado do jogo e não participar mais da decisão.

Sim, se você não tem participado mais das decisões críticas do seu projeto, pode ser porque você foi tirado do jogo por sempre se posicionar de forma dura e inflexível.

Nada como o tempo para resgatar boas idéias ou enterrar as idéias ruins.

Nunca critique sem ter uma proposta de solução

Essa é a mais clássica de todas. Todo dia ouço várias dessas: a arquitetura é uma bagunça, o projeto é um lixo, o usuário não sabe o que quer, o controle de versão é uma porcaria, e por aí afora.

Pense consigo mesmo e invés de levar as reclamações dessa forma, tente levar da seguinte forma: por que não fazemos a mudança “x” na nossa arquitetura, porque assim podemos tornar o produto melhor e mais fácil de manter? Por que não usamos a técnica “X” de escrever estórias para ajudar o usuário a definir melhor seus requisitos? Por que não instalamos o Git?

Você vai perceber que sua vida pode mudar. Quando você perceber como é difícil propor melhorias e vender os benefícios de determinadas mudanças começará não só a ponderar suas críticas como também a encorajar e apoiar as melhorias propostas por seus companheiros de time.

Vender soluções

A pior forma de fazer alguém concordar com você é impondo sua opinião. Cansei de ver desenvolvedor se descabelando para convencer outro usando abordagens do tipo: porque é certo, porque é assim que aquela empresa bacana com produtos na nuvem faz ou porque o fulano, ciclano ou beltrano falou que é o certo.

Esquece. Se você faz isso de uma forma impositiva, a pessoa vai discordar só pelo prazer de discordar e te deixar numa posição desconfortável.

Quando você pega uma pessoa dura nesse tipo de discussão, a abordagem que geralmente dá resultados é construir a solução em conjunto. Invés de simplesmente jogar a solução resolvida para
ela, jogue o problema. Ela vai apresentar uma solução. Coloque mais elementos que façam com que ela chegue a uma conclusão de que aquilo é uma má idéia. Quando aquele momento de desespero bater e ela soltar um: tá bom, se desse jeito não funciona, como funciona? Aí você coloca um pedaço da sua idéia como uma sugestão: “o que você acha de tentarmos isso?”

As vezes o que acontece também numa situação dessa é que você sai com uma solução melhor do que a que você pensou sozinho. As vezes simplesmente a pessoa tem uma idéia melhor.

O ponto central dessa idéia é que muitas vezes nós pensamos em diversas situações diferentes para chegar numa dada conclusão e como aquilo se torna óbvio para nós, esquecemos de repassar todo o processo que nos levaram a essa conclusão com nosso time, o que faz com que pareça que estamos “atropelando” toda a contribuição do outro.

Conclusão

O interessante deste processo todo é que quando você aprende a observar os seus comportamentos que o tornam uma pessoa difícil de lidar no time (por mais que sua intenção final seja fazer a coisa “certa”, de acordo com seu ponto de vista) e aprende o quão difícil é fazer isso, torna-se também uma pessoa mais tolerante com a falha do seu companheiro de time e aprende a levar a discussão de uma forma mais suave.

O que posso dizer por experiência própria é que quando você começa a encarar esses conflitos de uma forma mais natural e positiva, isso ajudará a trazer mais satisfação e felicidade para seu dia-a-dia.

Era isso!

Ensaio sobre carreira

Introdução

Sempre tive uma certa resistência em tentar escrever algo aqui sobre carreira. Acho que minha dificuldade vem da minha concepção de liderança por exemplo. Acho que seria muito ruim escrever sobre, sei lá, sucesso ou tentar dar conselhos sobre por qual caminho seguir sem estar necessariamente seguro do próprio sucesso ou de qual caminho seguir.

Mesmo assim, resolvi compartilhar aqui um pouco da minha experiência com o objetivo de ajudar companheiros de profissão a encontrarem também seu caminho ou talvez evitar algumas frustrações e escapar de algumas armadilhas.

Se vc tiver paciência pra chegar até o final do post, peço a gentileza de me mandar suas impressões, por e-mail, twitter, comentário no blog. O que achar válido, mas já aviso que o post vai ser longo…. 😉

Motivação

Apesar de longo, e até um pouco antigo, esse vídeo do Dan Pink merece ser visto até o final. Ele mostra alguns estudos que mostram como o modelo de recompensa tradicional (oferecer dinheiro ou prêmio em cumprimento de uma meta) funciona muito bem para trabalhos repetitivos (algorítmicos) e como ele é ineficiente para trabalhos criativos ou heurísticos.

Vídeo: Dan Pink e a surpreendente ciência da motivação

A primeira vez que eu vi esse negócio, caiu que nem um meteoro na minha cabeça. Agora estou lendo o livro “Drive – The Surprising Thuth About What Motivates Us”. Impressionante como esse livro vem sendo citado por muitos caras de software e em eventos de agilidade. Não é à toa.

419tQKzU2jL._SY346_PJlook-inside-v2,TopRight,1,0_SH20_

No “Drive”, o autor traz a idéia que no século XX existia uma grande demanda por trabalho repetitivo. Não existia tanto desenvolvimento, tantas ferramentas e ainda era muito necessário o trabalho humano repetitivo e braçal. E rapidamente, o homem inventou um “sistema operacional” para este modelo. O modelo de recompensa, geralmente financeira para o batimento de uma meta.

Com o progresso, cada vez mais o trabalho criativo é necessário. Para o crescimento das empresas, não mais é necessário somente trabalhar muito, mas pensar em soluções, desenvolver novas formas de fazer negócios, criar novos produtos, e como mostrado no vídeo acima e no livro, o modelo de recompensa tradicional não funciona para estes casos.

O ponto é que, como bem exemplificado, os negócios ainda não fazem o que a ciência descobriu.

As diferentes tribos de desenvolvedores

É curioso como uma mesma profissão pode acomodar perfis completamente diferentes de profissionais. De um lado temos pessoas extremamente comprometidas, preocupadas em tornar o trabalho do desenvolvedor mais profissional, estudando pilhas de livros, cruzando o país várias vezes ao ano para participar de eventos, desenvolvendo projetos open source, participando de dojos e tantas outras coisas (grupo A), e do outro profissionais que trabalham com tecnologias defasadas, cada vez mais repetindo o mesmo estilo de programação, sem se preocupar em aprender nenhuma tecnologia nova ou conceito novo (grupo B).

Minha conjectura, após conhecer a teoria do Dan Pink, é que isso é facilmente explicado pelos “sistemas operacionais” que ele descreve.

Faz muito sentido para o desenvolvedor do grupo B, motivado por recompensa funcionar da forma que ele funciona. Quanto pior a qualidade do código que ele escrever, mais problema o sistema vai dar. E obviamente mais vão precisar dele para corrigir. Quanto mais rápido ele codificar e mais rápido entregar o projeto desde que passe nos subjetivos critérios de aceitação, melhor pra ele. E em muitas empresas ele será recompensado por isso! Em resumo, ele entrega com uma qualidade ruim, no prazo, ganha bônus e ainda garante o emprego para o resto da vida.

Na outra extremidade faz muito sentido para o desenvolvedor do grupo A, motivado por propósitos se inconformar com a postura do desenvolvedor B. Ele é motivado por ver o software funcionando, ver a empresa funcionando, ver a sociedade, o companheiro de equipe tendo algum benefício com isso. Para ele, a recompensa é o próprio resultado do trabalho. Pode ser que lendo, você não entenda que alguém pense assim, mas se ainda não viu, por favor, veja o vídeo acima.

De fato, já ouvi várias vezes a resposta “porque eu preciso do dinheiro” para a pergunta “qual sua motivação?”. Isso pra mim de certa forma me dá mais segurança na minha conjectura.

A pílula vermelha ou a pílula azul

É duro parafrasear o Matrix, mas você vai ter que escolher uma delas e cada escolha é exclusiva. O importante aqui é saber o preço de cada escolha. Você pode encarar a realidade, dura e pagar o preço por sua escolha ou viver pulando de empresa em empresa em busca do Nirvana.

Grupo A

Se sua cabeça funciona como o grupo A, você tem duas escolhas. Buscar empresas que trabalhem com desenvolvimento de um produto, startups com modelos de negócio fortemente apoiadas em TI ou empresas que tenham TI dentro de casa. Geralmente estas empresas, por sofrerem diretamente o prejuízo de má qualidade de software, tendem a ser mais sensíveis a este discurso. Como nem tudo são rosas, saiba que essas empresas geralmente são menores, pagarão salários menores e terão maior risco de passarem apertos em cenários de instabilidade econômica. Busque empresas que trabalhem com metodologia ágil e fuja do modelo de recompensa orientado a metas por entrega no prazo. Esse modelo gerará sempre o conflito qualidade x prazo.

Se você realmente for um cara cabeça-dura e insistir em não querer correr o risco citado no parágrafo anterior, ganhar grandes salários e trabalhar em empresas grandes, você pode procurar grandes instituições financeiras (fortemente orientadas a metas e com bônus) e prestadoras de serviço de software (que pagarão bem pela sua capacidade de recuperar projetos caóticos ao custo de sua saúde). Acostume-se a ser chamado de: perfeccionista, preciosista e profissional de baixa resiliência. Tome cuidado pois durante os vários conflitos de entrega de qualidade x entrega no prazo você poderá ser visto quem está jogando contra o time ou mesmo criando conflitos na equipe. Não ache que pular fora desta discussão o isentará das longas noites e finais de semana fazendo o sistema funcionar na força bruta ao custo de sua saúde.

Cuidado com a armadilha das pequenas empresas que promovem ambientes descontraídos, ausência de hierarquia, videogames no escritório, etc. Apesar de eu acreditar que existem empresas assim acredito também que existem muitas que possuem somente o discurso. Apesar de não concordar com a abordagem, compreendo a reação de alguns desenvolvedores dando respostas extremamente ríspidas a este discurso em listas de discussão.

Outra armadilha é a empresa de serviço escondida numa empresa de produto. Geralmente é uma empresa, que tem um produto em casa, mas que não possui nenhum tipo de gestão técnica sobre o produto. Vende uma coisa diferente para cada cliente diferente sendo que cada customização é um projeto (com recompensa por entrega no prazo).

Grupo B

Se sua cabeça se identifica mais com o grupo B, faça exatamente o inverso do grupo anterior. Procure empresas com modelo de recompensa baseado em metas por entrega no prazo e fuja de empresas inovadoras. Busque aprender linguagens extremamente defasadas que as pessoas do grupo A não tem estômago para trabalhar, geralmente linguagens procedurais como VB ou COBOL. Se você tiver paciência para aprender algo novo, motivado pelos altos salários que esse aprendizado lhe trará, busque linguagens proprietárias e raras como ABAP (do SAP) ou outros ERP’s. Paga-se muito caro por este nível de especialização e o pessoal do grupo A não vai se interessar muito por aprender essas linguagens/tecnologias pela própria característica dela. O preço da sua escolha será a falta de contato com coisas novas, viver corrigindo bugs em sistemas extremamente defasados e complexos, naquele estilo que você corrige um bug e ele reaparece em outro lugar e você fica tentando pegar o cachorro perseguindo o rabo dele.

Você poderá correr algum risco de perder o emprego quando alguns destes legados forem substituídos. E não imagine que você será poupado dos longos finais de semana e madrugadas de correções de bugs.

Gestor ou especialista?

Essa decisão é tão difícil quanto a anterior, e provavelmente o seu modelo de motivação também o ajudará na sua decisão.

Grupo A

Com o grande crescimento das metodologias ágeis, é bem possível que com o tempo Scrum Masters sejam visualizados como gestores nas empresas e esta seja uma boa opção pra quem vem de um background técnico, mas até lá, geralmente que quando se escolhe por uma carreira de gestão, sua distância do código vai aumenta. Em grandes empresas de tecnologia internacionais, é normal encontrarmos desenvolvedores com títulos de “Principal” (diretor) e que ainda atuam diretamente com mão no código, mas não é uma realidade para empresas atuando no mercado brasileiro.

Provavelmente se sua cabeça pensa como o grupo A, você vai viver um eterno conflito. Quando se aproximar da gestão, vai se distanciar do código e se frustrar, se sentir estagnado, como se não estivesse contribuindo com algo produtivo e distante do seu propósito. Pode ser que até se sinta um pouco enganador, liderando pessoas sem ser uma referência em conhecimento técnico para ela. Quando se aproximar do código, vai cada vez mais se visualizar distante da gestão e sentir que sua carreira (no sentido financeiro) está estagnada.

Caso escolha pelo caminho da gestão, seu raciocínio lógico e seu conhecimento técnico provavelmente irão lhe sabotar em situações de negociações em que fatores humanos e políticos predominem. O impulso para resolver diretamente os problemas do dia a dia pode se tornar uma dificuldade no desafio de todo grande gestor que é ajudar sua equipe a crescer. A vantagem de enfrentar tudo isso é ter uma possibilidade clara de crescimento na carreira, assim como a imediata desvantagem que é a diminuição de oportunidades. Quanto mais alto o cargo e o salário, menor a quantidade de oportunidades.

Por outro lado, se escolher a carreira de especialista estará mais próximo do código. Existem empresas que prometem uma carreira em Y, de forma que o especialista teria as mesmas oportunidades de um gestor. Recomendo procurar alguém que trabalha numa destas empresas para dar sua opinião se realmente isso funciona na prática, ou seja, se um especialista de fato tem poder de decisão (ao menos técnica) nas empresas, se a faixa salarial é a mesma, etc.

O preço dessa escolha é o risco de ser gerenciado por um gestor sem conhecimento técnico e ter que pagar o preço por decisões por vezes equivocadas no seu ponto de vista, ter um limite salarial e de crescimento de carreira que provavelmente chegará muito rápido, além de poder eventualmente sentir uma espécie de tom de deboche quando ouvir comentários do tipo “você poderia estar longe na carreira, mas preferiu ficar programando”. Por outro lado, existem vantagens como a facilidade de recolocação e a maior satisfação e alinhamento com a sua natureza, em outras palavras, fazer o que gosta.

Grupo B

Se escolheu ser um gestor, sua motivação pela recompensa direta (salário e bônus) será uma forte aliada para superar todos os desafios da gestão. Você sofrerá a mesma dificuldade de todo profissional técnico que é aprender a lidar com pessoas, aprender a desenvolver pessoas, habilidades de negociação, etc. No caso da gestão de uma equipe técnica, você poderá ter também bastante dificuldade em conseguir o respeito da equipe técnica devido ao histórico das tecnológias e métodos que praticou enquanto analista.

No caminho de especialista, pode ser difícil conseguir o skill necessário para virar um especialista pois enquanto as pessoas do Grupo A são auto-motivadas e buscam conhecimento por conta própria, você do grupo B precisará de um estímulo externo (Ex.: uma clara oportunidade de promoção do tipo “aprenda a tecnologia A e será promovido”) para conseguir a motivação necessária a adquirir um novo skill.

A mudança no cenário

Outro ponto a ser considerado na tomada de decisão é que cada vez mais inovação é um assunto na agenda das empresas. Muitas empresas estão precisando da criatividade e da inovação para melhorarem seus resultados ou mesmo para sobreviver. Se os negócios começarem a perceber que o caminho sugerido pela ciência faz sentido, cada vez mais pessoas do grupo A serão procuradas.

Será que essa mudança acontecerá? Ou seria a pergunta mais apropriada: quanto tempo levará para essa mudança acontecer?

Conclusão

Não existe almoço grátis. Toda escolha é exclusiva e quando lidamos com nossa carreira é importante conhecermos a nossa natureza e buscarmos aquilo que está mais alinhado com ela. A melhor forma de evitar as frustrações e não cair em armadilhas é desenvolvendo o auto-conhecimento e sabendo claramente qual a escolha que está sendo feita e o preço pago por ela.