Por que é importante entender a filosofia do facebook?

Se eu disser que perfeccionismo é só disfarce para medo e pra não agir, como diz Gary V, é capaz de você ficar reativo e pensar em um comentário contrariando mas desistir no meio, por não conseguir escolher as melhores palavras para usar

Estou pintando um cenário no qual o perfeccionista é um procrastinador, mas muitas vezes é apenas alguém querendo garantir tudo funcionando bem, sem riscos. O ruim é fazer isso quando os riscos só moram na sua cabeça e não estão nem perto dos riscos do mundo real. Por isso, as pessoas abandonam seus projetos, pois nunca estarão bons o bastante para serem lançados

Mas, imagine o que faria se não tivesse medo. Essa frase estava em um poster no escritório do Facebook ao lado da famosa “Move Fast and Break Things”. Um conceito forte que incomoda muita gente, mas precisa ser olhado dentro do contexto de uma startup

Sou um cara que tirou várias startups do chão, do zero, a partir de nada além da ideia e mesmo eu, que nunca fui perfeccionista, tive dificuldade para fazer um produto “incompleto”, colocar na mão do cliente e ainda cobrar por isso. Dá uma vergonha, como se ele fosse pensar “é esse tipo de profissional que você é?”

Mas lançar uma startup é uma corrida contra o tempo. É como se você começasse a empresa tentando escapar de um carro submerso, você precisa encher os pulmões, quebrar a janela e tentar se debater com roupas, cinto de segurança e um arrasto enorme até conseguir emergir vários metros acima e respirar novamente. Isso significa que se você não fizer um bom trabalho rápido, você vai morrer. Sua startup vai. E para um fundador pouco importa se é a startup ou ele quem morre, pois são uma coisa só

Move fast and break things é a filosofia perfeita para uma nova startup. Você precisa estar disposto a quebrar o vidro e deixar suas roupas para trás pra subr rápido para a superfície. Você precisa aprender rapidamente. Lançar vai te fazer aprender e se reposicionar no caminho certo

Claro que ir rápido e quebrar coisas não é pra qualquer contexto. Depois de 10 anos, o FB mudou para “Move fast with stable infra”. Não tem o apelo da anterior, mas com bilhões de dólares de clientes em jogo, é bom garantir tudo funcionando

Polêmica: Salários de desenvolvedores de Software

Se juntar a capacidade de ganhar dinheiro em tech com a facilidade da profissão para exercer trabalho remoto, você tem o cenário ideal para ter uma boa receita e viver em lugares com custo de vida mais em conta.
Enquanto isso as empresas estão cada vez mais preocupadas pois é certo que vai faltar mão de obra qualificada em breve.
Não sei quanto vocês aqui acompanham o twitter, mas quando eu entro lá parece que é um mundo sombrio e paralelo.
Você concorda que tech paga os melhores salários do mercado hoje em dia? Deixe aí sua opinião

Foco naquilo que dá pra mudar. Sempre! Claro que bons líderes, te impulsionam, te mostram oportunidades e te ajudam a se desenvolver, mas o poder de chegar lá é sempre seu. Se você não tem alguém que te ajude hoje, procure um lugar que tenha.

A única reunião que você precisa ter

Se fosse pra você escolher uma reunião, qual seria e por quê? Todos estamos soterrados por reuniões, e se você estiver em uma empresa ruim, suas reuniões serão um porre e você sempre terá a impressão de que não deveria ter tantas mesmo que sempre anseie por mais uma para resolver o “alinhamento”.

A única reunião que precisa ser feita é a reunião de retrospectiva. Isso não tem a ver com ágil, tem a ver com olhar para o que foi feito e analisar criticamente o que deu certo e o que deu errado junto ao time para repetir os acertos e evitar os erros.

Se outras reuniões, ritos, cerimônias ou “alinhamentos” forem realmente importantes para a sua realidade, elas aparecerão nessa retrospectiva.

Sendo agnóstico de qualquer metodologia de trabalho, de área de atuação, setor, não importa. Tenho certeza que uma retrospectiva bem feita é capaz de identificar tudo aquilo que precisa existir para o time evoluir continuamente.

Originalmente, publicado no instagram. Me segue lá:

Expectativa irreal dos Tech Leads

Tech leads de primeira viagem costumam ter um pensamento que é paralisante. Líderes iniciando, no geral acabam enfrentando isso.

Imagine a seguinte situação: É seu primeiro dia como tech lead de um time e um dev jr empolgado diz que está muito feliz com a sua chegada pois estão com dificuldade no app que estão desenvolvendo. Imagine agora, que o app é em Android, mas você nunca sequer programou uma linha de código que tivesse a ver com um aplicativo porque foi desenvolvedor backend a vida toda. O dev veio cheio de expectativas e você não faz ideia de como ajudar, sem ser se debruçado sobre o problema e aprendendo para poder ensinar.

Lembro da primeira vez que precisei liderar um time de desenvolvimento mobile. Dois dias antes do início do novo dev Android, comecei a ler sobre o assunto e instalei o Android Studio pois não estava me sentindo confortável para estar a frente de um projeto que eu não sabia como programar. Obviamente eu jamais teria tempo de ter estudado tudo o que ele sabia e mais um pouco para servir como a “referência técnica” que eu achava que deveria ser.

Essa expectativa irreal de ter que saber tudo sobre toda a stack ou ser quem mais sabe de tecnologia no time é paralisante.

Nesta situação lembro de conversar com o CEO da empresa que me explicou o porquê não fazia o sentido que um líder tivesse que saber tudo para garantir que as outras pessoas estivessem fazendo um bom trabalho. O importante é transportar seu conhecimento de uma área para outra perguntando para entender como a outra pessoa está pensando nos casos que você pensaria.

Na situação tanto o TL como o Jr tem expectativas irreais. Para o jr em início de carreira é normal não saber o que esperar dos líderes próximos.

Já o TL precisa fazer as perguntas certas, ler código e ser curioso quanto a um know-how que ainda não tem para poder aprender mais e deve contar com aquela pessoa para tomar as melhores decisões possíveis, dentro das possibilidades discutidas. Tentar entender mais sobre o escopo, padrões utilizados e o que está sendo feito, ajuda a garantir boas decisões.

Publicado originalmente no Instagram, me segue lá:

Weekly Deploy #02

Weekly Deploy é uma publicação semanal de liderança, tecnologia e empreendedorismo com coisas que usei, vi e aprendi e que estou achando interessantes. Edição #02

Saindo com um dia de atraso por motivos de: “ih, esqueci!”

Serviço que estou adorando

QuintoAndar! É realmente sensacional. Como primeira experiência senti que foi muito prático e ainda por cima não precisei lidar com a burocracia e falta de educação das imobiliárias tradicionais. Inclusive, achei a parte de compra de imóveis interessante.

App para Mac que comecei a usar

Alttab – O CMD+TAB do Mac nativamente alterna entre programas e não entre janelas, por isso comecei a usar esse programa que tem um comportamento parecido com o do Windows. Ótimo para quem estiver usando um teclado não Apple no Mac.

Texto sobre liderança técnica que achei interessante

How to Overcome the Technical Strategy Spiral – Essencial para quem se pergunta por quê não tem sido incluído em discussões mais estratégicas. Spoiler: Quanto mais você ignora e não participa desse tipo de discussão, mais por fora você estará.

Vídeo aleatório super útil sobre negociações

É sobre a famosa técnica da Ancoragem, mas sobre como agir quando já ancoraram você

Weekly Deploy

Weekly Deploy é uma publicação semanal rápida de liderança, tecnologia e empreendedorismo com coisas que usei, vi e aprendi e que estou achando interessantes. Esta é a primeira! Edição #01

Texto que estou lendo:

Maximizing Developer Effectiveness. Um texto pra refletir em quais melhorias fazer para proporcionar um ambiente propício para altíssima produtividade.

Livro rápido que estou retomando

Anything you want do Derek Sivers. Ele é um músico que aprendeu a programar PHP + MySQL e montou um site apenas para vender seus álbuns independentes. 10 anos depois, vendeu sua empresa, a CD Baby por 22 milhões de dólares para a Apple

Entrevista que estou assistindo:

Conversa fantástica com a Dra Carla Sarni, dona das franquias Giolaser, Sorridents e outras com mais de 700 lojas no Brasil. A história dessa mulher é sensacional. Empreendedorismo na veia.

Audiobook que ouvi novamente

The Willpower Instinct – Kelly McGonigal. Citado várias vezes neste blog, este é um dos livros que eu mais gosto quando preciso encontrar maneiras de mudar alguns hábitos. Li o Livro na esteira da academia, então ele já cumpriu um pouco do papel que eu esperava dele. XD

SaaS que comecei a usar

Linktree. Te dá acesso a uma página para você colocar títulos e links. Bom para colocar no seu perfil em sites que te pedem apenas um link como o Instagram.

Vinho que estou tomando

Continuo apaixonado pelo Portada. É um vinho meio seco português, um pouco adocicado e que harmoniza muito bem com coisas que eu adoro como pizza, massas e alguma carnes.

Criar um projeto do zero ou utilizar algo pronto? Como decidir o Buy or Make

Como tomar a decisão de Buy or Make? Ou em bom português, como decidir se você compra ou faz alguma coisa? Ou ainda, se você faz ou usa pronto de alguma forma, seja utilizando Open Source, contratando um SaaS, terceirizando, etc.

Não importa seu cargo, sua empresa ou em qual área você está inserido, com certeza você já precisou e ainda vai precisar tomar esse tipo de decisão. Neste vídeo eu vou explicar como você decide o Buy or Make e porquê você já deveria pensar assim:

Esse tipo de decisão entre comprar ou fazer algum projeto é referido por aí como Buy or Make (fazer ou comprar) e todo mundo vai precisar tomar esse tipo de decisão, seja o estagiário ou o líder da empresa.

Sendo assim, quanto mais cedo você começar a pensar nos trade-offs entre criar a solução em casa (in house) versus comprar um sistema pronto,
mais estratégico você vai estará sendo e melhor para o seu futuro.

Por certo, se você estiver numa posição de liderança e não estiver frequentemente pensando em BUY or MAKE, você corre o risco de estar desperdiçando recursos e perdendo oportunidades para o seu negócio.

Por onde começar?

Se você é uma pessoa que resolve problemas vão aparecer problemas do seu cliente ou da sua empresa cuja solução já existe no mercado e para a grande maioria dos problemas você vai encontrar uma solução pronta, que você vai usar como base pra criar a sua.

Para os demais problemas você vai escolher fazer do zero.

Como tomar essa decisão no dia a dia? Você sempre vai começar a resolver qualquer problema procurando pelas soluções existente e vai comparar o que existe com o que você precisa fazer. Depois disso, você precisa estimar o esforço em customizar aquela solução para o seu cenário e comparar com a estimativa de esforço para você criar sua própria solução.

Contudo, como um guia geral sempre tenham em mente a frase:
NÃO REINVENTE A RODA.
Use o que está pronto, use o que o mercado já está usando

No entanto, o único cenário em que isso não é necessário é quando um estudante quer aprender algo do zero e quer implementar uma solução para aprender com ela.

Livre-se do seu Ego

Sobretudo, existe uma batalha de EGO muito grande e diversas vezes você vai querer implementar algo do zero porque por arrogância você pode acreditar que vai criar uma solução melhor. Mesmo que você realmente possa, não é só porque você pode criar algo melhor que você deveria, Peter Drucker já dizia que “nada é menos produtivo do que tornar eficiente algo que nem deveria ser feito”. Por quê? Porque alocação de recurso e alocação de tempo são importantes demais.


“Nada é menos produtivo do que tornar eficiente algo que nem deveria ser feito” – Peter Drucker

Quando você decide FAZER alguma coisa, você está tomando a decisão de NÃO FAZER um monte de outras coisas.

Inegavelmente, não será fácil decidir o Buy or Make, isto é se você precisa criar a solução ou usar uma pronta, mas o básico que você precisa fazer é se perguntar se deveria fazer um ou o outro. Contudo, quando a solução não for ESSENCIAL para o negócio ou como se diz, se não for o CORE BUSINESS existe uma grande chance de que você deveria estar usando uma solução pronta ou contratando um serviço e não desenvolvendo do zero.

Comente o que você acha! Se você gostou, compartilhe com aquele seu amigo que quer fazer tudo do zero.

Obs:
Neste post comento um pouco sobre a importância de se livrar do Ego e ser humilde: Hackeando o organograma e influenciando ativamente quem está acima de você.

Créditos da música:
Music: 月华
URL: https://enjoymusic.ai

Tech Leads deveriam gerenciar pessoas?

Tech Leads deveriam gerenciar pessoas? Alguns líderes técnicos tem um frio na espinha só de pensar nisso. Outros, que já estão fazendo isso no dia-a-dia se lamentam e acreditam que essa é a grande dificuldade do trabalho deles e que deveriam focar só na parte técnica. Porém, na minha opinião, a resposta para essa pergunta é um grande e sonoro SIM.

No entanto, para muitos Tech Leads, essa é uma dor. É como se essa fosse a parte do trabalho que mais cria ansiedade, como aquela palpitação antes de ter um 1-1, ou se perguntando “Por que não pensei em falar isso naquela hora?” E ainda as avaliações de performance ou demissões. Muitos pensam que seria mais fácil quebrar esse papel em dois entre pessoas e tecnologia. Algumas empresas até fazem isso, mas eu não acredito nessa separação.

Por certo, você evoluiu por várias etapas no seu desenvolvimento técnico, conseguiu negociar soluções, simplificar problemas, fazer escolhas difíceis, trade-offs e navegar pela sua carreira para alcançar essa posição de liderança. Você foi forjado nesses desafios e seria um desperdício ignorar isso e se reduzir ao conhecimento técnico de uma linguagem, sistema ou framework. Aproveitar o que você sabe facilitará o caminho daqueles que você lidera e eles vão crescer com chances de se tornarem líderes também.

Porém, só para deixar claro. Sempre que eu usar a palavra líder, eu estarei falando no sentido de um facilitador, de um mentor, de alguém que está ajudando alguém a superar os desafios. Não gosto de pensar em líder como “chefe”. Aliás, não gosto nem dessa palavra.

Imagem do Mentor do He-man. 
Tech Leads deveriam gerenciar pessoas?
Mentor.
Para quem lembra do He-man

Deixa eu me explicar.

Por fim, fiz esse vídeo, no qual explico um pouco sobre o porquê eu acredito tanto que tech Leads deveriam gerenciar pessoas.

Esse assunto começou sendo discutido lá no meu instagram, me sigam: https://www.instagram.com/ffreitasalves/