1 pontos por GN⁺ 2023-07-16 | 1 comentários | Compartilhar no WhatsApp
  • A primeira VP of Engineering da Honeycomb foi promovida em fevereiro de 2020 a partir do cargo de Director of Engineering, e esse caminho foi mais parecido com assumir lacunas que surgiram conforme a empresa crescia do que com uma carreira executiva planejada
  • No início da Honeycomb, a cofundadora Charity Majors gerenciava quase todo mundo, e duas pessoas com filosofias semelhantes, mas históricos e estilos diferentes, passaram a dividir as responsabilidades de gestão de P&D
  • A promoção não foi uma grande transição única, mas o acúmulo de pequenas expansões de escopo, e criar novos processos e responsabilidades em uma startup se tornou o caminho principal
  • Preparar-se para o papel exigiu pensamento voltado para a empresa como um todo, perfil generalista, capacidade de transitar por vários níveis de abstração, senso de responsabilidade, pensamento sistêmico, apoio ao crescimento dos membros da equipe e relacionamentos amplos
  • O que define uma boa VP of Engineering varia conforme os problemas atuais da empresa, a composição da liderança e dos ICs existentes, os desafios técnicos e a fase de crescimento, mais do que por um modelo padrão

Um ponto de partida que não era uma carreira executiva planejada

  • A primeira VP of Engineering da Honeycomb foi promovida em fevereiro de 2020 a partir do cargo de Director of Engineering
  • O objetivo inicial ao entrar na Honeycomb era trabalhar como engenheira, com o entendimento de que poderia voltar a uma função de gestão se fosse necessário
  • Na época da entrada, era aproximadamente a 12ª funcionária, e sabia que, em uma startup em estágio inicial, quanto mais a empresa tivesse sucesso, mais assumiria trabalhos variados em diferentes fases
  • Via o apego forte a uma função específica como algo que poderia atrapalhar, em vez de ajudar, tanto a pessoa quanto a empresa
  • Escolheu a Honeycomb porque a equipe parecia inteligente e gentil, parecia haver muito a aprender, e o produto parecia algo que ela queria, mas não havia encontrado, no emprego anterior
  • Para crescer rapidamente em uma função específica, entrar em uma startup depois da Series B poderia ser mais eficiente, mas ela entrou na Honeycomb na fase Series A

Como as responsabilidades de gestão se deslocaram

  • No início, a cofundadora e então CEO Charity Majors gerenciava quase todos, de executivos a engenheiros individuais
  • As duas estavam em geral bem alinhadas na filosofia de gestão, mas tinham históricos e pontos fortes diferentes
    • Charity Majors tinha profunda experiência em infraestrutura, operações, bancos de dados e engenharia de backend
    • A pessoa promovida começou em design, frontend e engenharia de produto, e gostava de colaborar com product management e design de UX
  • Ambas tinham experiência com métricas e tecnologias de monitoramento, mas suas atitudes eram diferentes
    • Charity Majors tendia a não gostar disso
    • A pessoa promovida tinha um forte apreço por isso
  • As diferenças de estilo de trabalho também eram grandes
    • A pessoa promovida valorizava regras e processos, e fazia bastante planejamento e gestão de riscos tanto no trabalho cotidiano quanto em hobbies
    • Charity Majors tinha um estilo intuitivo e improvisado, brilhava especialmente em situações de crise, não gostava de checklists e percebia rapidamente quando regras ou processos não ajudavam
  • À medida que a Honeycomb crescia, o trabalho de gestão de P&D aumentou, e elas passaram gradualmente a dividir responsabilidades em torno das áreas que melhor combinavam com o histórico de cada uma

A promoção foi o acúmulo de pequenas expansões de escopo

  • O caminho até VP teve muito mais inúmeros pequenos passos do que um marco único e claro
  • Mudanças intermediárias de cargo eram úteis, em retrospecto, como sinais de progresso, mas em geral não indicavam uma grande mudança de escopo além da adição de novas reuniões
  • Em uma startup em crescimento, lacunas em processos e responsabilidades continuam aparecendo, e problemas que pareciam pequenos vazamentos podem se transformar em questões que consomem muito tempo e atenção
  • Sempre há oportunidades de subir de nível assumindo novos problemas, mas é outra questão se a empresa reconhece isso com um novo título e papel
  • As duas cofundadoras da Honeycomb apoiaram ativamente promoções internas e o reconhecimento de influência não só para ela, mas também para outras pessoas da empresa
  • Se fosse procurar outra startup no futuro, diz que buscaria uma equipe executiva ou fundadora que tivesse exemplos de desenvolver profissionais de alta performance por promoção interna e que reconhecesse e recompensasse rapidamente pessoas que já estivessem gerando impacto além do escopo do papel

A transição de gerenciar ICs para gerenciar gerentes

  • A transição mais interessante de toda a jornada foi o momento de passar de gerenciar apenas ICs para gerenciar também gerentes
  • Para quem deseja fazer essa transição, considera melhor tentar em uma empresa onde já conhece a equipe, a tecnologia e os problemas de negócio, em vez de em uma empresa nova
  • Muitas das habilidades existentes de gestão direta foram transferidas, mas levou tempo para aprender a “enxergar” a organização inteira de forma eficaz por meio de uma camada adicional de gestão
  • Foi especialmente difícil identificar os pontos de atrito na organização ou onde mais suporte era necessário
  • A experiência direta com as pessoas e os problemas da organização de engenharia permitiu sustentar esse período até criar, junto com os gerentes, práticas e habilidades para avaliar a situação das equipes

Busca por uma VP externa e promoção interna

  • Em um momento em que o rumo da empresa estava um pouco instável, também foi considerada a contratação externa de uma VP of Engineering
  • Charity Majors compartilhou isso de forma transparente e a envolveu no processo de encontrar e escolher a pessoa adequada
  • Elas conversaram com vários líderes de engenharia excelentes, mas alguns não se encaixavam na Honeycomb naquele momento, e outros não escolheram a Honeycomb como seu próximo passo
  • Depois disso, a empresa passou a ter novos problemas, e os problemas anteriores que pareciam insolúveis se tornaram mais administráveis
  • A promoção não aconteceu imediatamente naquele momento, mas a busca externa foi interrompida
  • Promoções de liderança acima de certo nível devem se basear não na pessoa, mas no que a empresa precisa, e foi útil imaginar em conjunto como seria a VP of Engineering adequada para a Honeycomb

Características que ajudaram a se tornar adequada ao papel

  • O pensamento holístico funcionou como uma característica importante
    • O foco naturalmente se voltava não apenas para a equipe, mas para o que tornaria a Honeycomb, como empresa, mais bem-sucedida
    • Trabalhava bem em um ambiente onde agir pelo interesse da empresa como um todo, acima de departamentos, equipes ou indivíduos, era recompensado
  • O perfil generalista também ajudou
    • Sentia interesse por quase todos os problemas de negócio e domínios dentro de uma empresa de software
    • Gostava de poder ver como todas as peças se encaixam em uma startup
    • Não tinha resistência a assumir, quando necessário, trabalhos pouco glamourosos e sem destaque
  • Conseguia trabalhar em vários níveis de abstração
    • Conseguia captar rapidamente conceitos de camadas superiores mesmo sem entender totalmente as camadas inferiores
    • Quando necessário, também gostava de entrar nos detalhes
  • Um forte senso de responsabilidade ajuda em startups, mas também precisa de limites
    • É útil em startups onde trabalhos importantes caem nas lacunas entre funções
    • Ainda assim, é necessário esforço contínuo para concluir ou repassar tarefas a outras pessoas, de modo que o trabalho não se acumule nem bloqueie o crescimento da equipe
  • O pensamento sistêmico, aplicado tanto a pessoas quanto a sistemas técnicos, também entrou na lista de aspectos importantes
  • A atitude de gostar genuinamente de ver membros da equipe crescerem também foi importante
    • Encontrava energia em conectar pessoas prontas para o próximo passo a problemas importantes que ficavam na borda de suas capacidades
  • Bons relacionamentos por toda a empresa também foram necessários
    • Pessoas dentro e fora da empresa precisavam sentir mais entusiasmo com ela assumindo o papel do que com a expectativa em torno de uma candidata externa

Experiências profissionais que ajudaram

  • A experiência em startups de vários estágios e tamanhos, especialmente startups B2B SaaS, ajudou
    • Startups B2C e B2B lidam com categorias relativamente diferentes de problemas e desenvolveram suas próprias técnicas de resolução
    • Ver os dois campos é bom, mas também é valioso construir especialização em B2B ou em B2C
    • Go-to-market, estrutura organizacional, problemas de engenharia e desafios de escala podem ser diferentes entre B2B e B2C
  • A experiência trabalhando em toda a stack também ajudou
    • A experiência mais profunda em engenharia era em tecnologias de frontend
    • Acumulou experiências iniciais em várias organizações que praticavam pair programming e aplicavam uma mentalidade DevOps
    • Aprendeu com engenheiros de backend, infraestrutura, plataforma e operações, entendendo como eles pensam e quais problemas consideram importantes
    • Não é necessário ser especialista em todas as áreas de engenharia, mas empatia por várias equipes e uma compreensão de alto nível do domínio ajudam muito
  • A experiência em ferramentas para desenvolvedores e monitoramento também se encaixava no papel
    • Trabalhou em três empresas consecutivas de ferramentas para desenvolvedores
    • Gostava genuinamente do produto da Honeycomb e também tinha apreço por vários produtos nas áreas de observability, monitoramento e ferramentas para desenvolvedores
    • Conhecimento de domínio e entusiasmo pelas ferramentas ajudam colegas e podem servir como fonte de energia em situações desanimadoras

A adequação criada pela sorte e pela composição da equipe

  • A sorte também teve um papel importante em se tornar a pessoa adequada para o papel
  • Não bastava ter habilidades e experiências complementares às de Charity Majors; também foi importante que os ICs seniores iniciais estivessem lidando bem com os principais desafios de engenharia
  • Uma VP of Engineering com histórico de frontend é relativamente rara, porque os desafios técnicos mais urgentes de uma startup normalmente estão em escala, confiabilidade e arquitetura de backend
  • Se houvesse incidentes contínuos, problemas de escala e grandes questões arquiteturais no mecanismo de consultas e armazenamento, seria muito provável que alguém com experiência mais profunda em backend e operações fosse escolhido
  • Graças a Ben Hartshorne, Ian Wilkes, outros ICs excelentes e às decisões sólidas de design da equipe fundadora, havia folga técnica, e a principal prioridade da liderança naquele momento era executar a estratégia de produto e melhorar a experiência do usuário
  • A equipe executiva já contava com executivos externos experientes em funções de go-to-market
  • Christine e Charity, que podiam ser vistas como líderes que cresceram dentro da empresa, também tinham experiência como fundadoras ou em liderança em empresas anteriores, e Charity já era conhecida como uma excelente gerente antes de fundar a Honeycomb
  • Se a equipe executiva estivesse mais inclinada a novos executivos ou a promovidos internos, talvez não houvesse margem para desenvolver mais uma executiva

VP of Engineering depende do contexto da empresa

  • O aprendizado mais importante é que o perfil de uma boa VP of Engineering depende do contexto
  • Antes, ela achava que seria possível listar características padrão que fazem uma ótima VP of Engineering, mas a ideia de que quase todas as empresas compartilham um mesmo modelo básico acabou parecendo menos correta
  • O trabalho fundamental a ser feito é parecido na maioria das empresas de software, mas o tipo de executiva que deve liderá-lo varia muito conforme os problemas atuais da organização e a composição de executivos, gerentes e ICs já existentes
  • Mesmo depois de entrar no papel, os requisitos não permanecem fixos
  • Em uma empresa em crescimento, assim como outros papéis em startups, o papel de VP of Engineering também pode mudar de forma com o tempo

1 comentários

 
GN⁺ 2023-07-16
Opiniões do Hacker News
  • Achei esta parte interessante: “Charity tem um estilo mais intuitivo e espontâneo, brilha mais em crises e odeia checklists” parece quase uma admissão feita sem pensar
    Em outras palavras, significa que a fundadora não tem as qualificações ou características que seus subordinados consideram necessárias para posições de liderança
    Quando você funda uma empresa, automaticamente vira CEO, CTO etc.; o mesmo vale para fundadores de empresas que hoje se tornaram grandes corporações
    Fundadores não precisam de qualificações específicas para justificar seus cargos; eles se tornam líderes por conta própria e depois escolhem amigos como os primeiros funcionários
    A contratação só se formaliza muito depois e, por mais que se queira acreditar que a hierarquia é meritocrática, o começo dessa hierarquia foi claramente caótico
    O pensamento hierárquico e submisso sempre me pareceu estranho, e nunca achei que meus chefes anteriores fossem “melhores” do que eu
    Subir a escada corporativa é, em essência, algo mais próximo de política, e textos intermináveis como “o que é um engenheiro sênior” também parecem vir de um pensamento corporativizado que tenta justificar a hierarquia

    • Ao participar da criação de uma empresa, no começo você acaba recebendo cargos como CEO e CTO de forma essencialmente arbitrária
      Mas, com o tempo, precisa justificar esse cargo fazendo a empresa ter sucesso sem quebrá-la
      Muitas vezes, isso é uma forma de medir capacidade muito mais honesta e dura do que qualquer avaliação
      Uma grande empresa como o Google não vai falir por causa de um VP incompetente e preguiçoso, então precisa de um sistema de avaliação
      Vale comparar com https://gwern.net/backstop
    • No topo de uma empresa, são necessários tanto líderes não convencionais quanto líderes voltados à execução
      Eu sou totalmente do tipo executor, mas aprendi cedo que as características ideais em um cofundador são o oposto das minhas, e é essa diferença que aparece aqui
      A pessoa descrita é uma líder não convencional típica: improvisadora, pulando de uma coisa para outra e possivelmente dispersa, mas ao mesmo tempo uma inovadora brilhante e alguém que motiva as pessoas
      Uma startup bem-sucedida precisa tanto de pessoas visionárias/não convencionais quanto de pessoas executoras
      Recomendo Rocket Fuel: https://www.amazon.com/Rocket-Fuel-Essential-Combination-Bus...
    • Não li essa frase como um comentário sobre a qualificação de alguém
      Parece uma admissão franca e amistosa de que existem dois estilos diferentes, e reconhecer essas diferenças é algo saudável, não um apelo implícito à hierarquia
      Pelo contrário, ao usar expressões como “subordinados” e “chefes” e equiparar a fundação de uma empresa à criação de uma hierarquia, o comentário inteiro reforça a hierarquia, apesar de dizer que desconfia dela
      Na indústria do conhecimento, gestores não são líderes, e sim pessoal de apoio
      Os melhores gestores e executivos de software sabem que seu papel é ajudar os verdadeiros líderes e especialistas — os contribuidores individuais que fazem o trabalho — a trabalhar com mais facilidade
      Uma das funções de apoio da liderança executiva é estabelecer essa expectativa por meio do próprio comportamento
    • Especialmente em empresas gigantes, isso é muito verdadeiro
      Quando uma startup é vendida para uma grande empresa, fica bem interessante quando se descobre que ninguém da startup teria sido contratado pelos critérios de RH daquela empresa
      E então, de repente, membros daquela equipe da startup acabam sendo promovidos antes dos funcionários da grande empresa, com diplomas bons e aprovados pelo RH
    • Concordo plenamente
      Muita gente está doutrinada na cadeia de comando corporativa americana, e é comum demais presumirem que, se alguém tem determinado cargo, de fato possui as qualificações correspondentes a ele
      A inflação de títulos está em toda parte e, pela minha percepção, muitas vezes os cargos são usados como ferramenta para aumento salarial e reconhecimento de tempo de casa, não como reconhecimento de competência
      Eu não pretendia dizer que isso se limitava apenas aos EUA
  • Pela minha experiência, é muito raro ver o critério de procurar casos de promoção interna
    Na maioria das startups, quando se torna necessário um novo nível na hierarquia ou quando alguém sai e abre uma vaga, o padrão é contratar de fora
    A lógica parece ser que, se todos estão fazendo bem o trabalho necessário, é melhor não mexer, mas, sinceramente, isso desmotiva muito
    Isso é muito mais desanimador do que ser preterido porque um colega foi promovido, pois, se há uma cultura de promoção e crescimento, dá para acreditar que haverá uma oportunidade justa na próxima vez
    Mas, se sempre contratam de fora, minha carreira nesta empresa fica exatamente no mesmo cargo em que entrei

    • Isso não é um problema só de startups, e não é à toa que existe o velho conselho de sempre se preparar para trocar de emprego se quiser aumento salarial ou promoção
      A lógica parece ser mais a de reter, pelo menor custo possível, pessoas inteligentes capazes de entregar resultados acima do seu cargo
      Trocar de emprego tem custos reais para o funcionário, e eles ficam maiores quanto pior está o mercado
      Ainda assim, há quem vá embora, há quem desista silenciosamente e há quem simplesmente aguente
    • Já vi inúmeras vezes funcionários iniciais reclamarem que “não é mais como antes” quando a empresa cresce até certo ponto
      Pela minha experiência, eles muitas vezes se recusam a se adaptar e acabam saindo ou sendo demitidos
    • Startups crescem mais rápido do que sua capacidade de gestão
      Conseguir gerenciar uma equipe de 10 pessoas não significa conseguir gerenciar uma organização de 100, muito menos de 1000
      Não estou dizendo que este caso seja necessariamente assim, mas, em alguns casos, é uma razão legítima para evitar o Princípio de Peter
    • Quando há promoções internas demais, muitas vezes as falhas dos fundadores não são corrigidas
      Isso acontece porque são promovidas pessoas que toleraram essas falhas ou nem chegaram a percebê-las
      Um dos poucos contratados de fora com experiência suficiente para reconhecer essas falhas provavelmente terá uma fase bem difícil
    • Trabalho em uma grande startup, ou scale-up, que está indo muito bem
      A maior parte da liderança de topo subiu por promoção interna, às vezes até de contribuidor individual a VP, e dá para ver o efeito disso
      Acho que seria claramente benéfico para a organização trazer alguém que já tenha vivido esse porte em várias organizações
  • Era difícil entender o que a pessoa realmente fez e o que faz agora no papel de VP
    Há muitas frases bonitas, mas não fica claro com o que ela passa a maior parte do dia hoje
    Dizer que veio de “design, front-end e engenharia de produto” também não traz muita informação
    Eu também sou exatamente esse tipo de pessoa, que vai desde esboços até layouts no Figma, front-end e camada intermediária com SvelteKit, e construção de APIs com FastAPI, mas não sei o que ela fez bem para virar VP, do que se afastou no trabalho de campo, o que faz agora e do que mais sente falta
    O texto é enorme, mas não sei muito bem o que ele quer dizer

    • Do trabalho de campo até VP de engenharia há várias etapas de distância
      Para entender o papel esperado hoje em empresas menores que as FAANG e o caminho de um engenheiro ao subir para a trilha de gestão, vale consultar “The Manager's Path”
    • Tive uma impressão parecida
      Eu achava que, quanto mais se avança para liderança executiva, mais o trabalho se torna estratégico e mais raramente envolve execução direta, mas o texto lista muitas experiências e qualidades táticas que a pessoa diz que a tornam uma boa VP
    • Parece um texto que a equipe de RP de RH mandou alguma pobre pessoa escrever
      Como alguém pobre na periferia da tecnologia, já vi muitos casos de empresas obrigando pessoas a escrever alguma coisa, e era sempre assim
      Na época de recrutamento em campus, as pessoas da empresa acabam escrevendo um ou dois textos desse tipo para que apareçam resultados recentes nas buscas
      Isso cumpre ao mesmo tempo os objetivos de bajulação adequada e de enaltecer possíveis candidatos
    • On Becoming a VP of Engineering, Part 2: Doing the Job
      https://www.honeycomb.io/blog/becoming-vp-of-engineering-pt2
    • Bem-vindo à gestão
  • Este texto é basicamente um exemplo de viés de sobrevivência e de sua racionalização
    O que falta é uma perspectiva estatística entre mobilidade interna para uma vaga de VP e contratação externa
    Vejo como extremamente difícil chegar internamente a VP, seja em uma startup ou em uma grande empresa
    A startup precisa dar certo, e na grande empresa é preciso aguentar anos e construir boas relações políticas
    O caminho mais fácil é não pensar em começar de baixo, mas mirar em cargos altos cedo na vida e continuar fazendo isso
    Se você não consegue subir até o topo na empresa atual, pode criar a sua própria
    Se começar de baixo, vai continuar lá, porque essa habilidade não tem valor em cargos de liderança máxima

    • Não acho que o texto tenha tratado de contratação interna versus externa
      Eles tentaram, mas no fim não foi assim, e não houve juízo de valor
      Parece que não conseguiram encontrar um bom candidato e, no fim, a autora foi promovida
      Na minha startup anterior também procuraram um VP e acabaram fazendo uma promoção interna; estatisticamente, isso claramente acontece às vezes
      Acho que a autora não concordaria com a última frase, de que “se começar de baixo, vai continuar lá”
      Ela diz que a infraestrutura da empresa se manteve estável mesmo durante a expansão porque “as pessoas de baixo” fizeram um bom trabalho, e por isso ela teve espaço para pensar mais em estratégia
      Não parece ser uma questão de cima ou baixo, mas sim de que tipo de problema a pessoa resolve bem
      Se você gosta de planejamento, gestão e estratégia, é bom mirar em funções em que possa usar essas competências, seja no topo, no meio ou na base
    • Infelizmente é verdade, e esse modo de pensar deve ser aplicado a tudo
      Por exemplo, se quiser se destacar, não se acomode em vagas de JavaScript: force-se a entrar em espaços competitivos e, para se tornar um programador realmente bom, escreva código amaldiçoado em OCaml
  • Como CTO de uma startup que recebeu investimento de venture capital, eu diria que as pessoas em cargos altos em geral são inteligentes, e incluo astúcia na mesma categoria
    Mas há muitas pessoas igualmente inteligentes que não estão em cargos altos porque não tiveram oportunidade
    Começar o próprio negócio melhora suas oportunidades e, embora ninguém funde uma empresa para conseguir um cargo de VP em outra, isso se torna uma boa rota alternativa
    Ou é preciso fazer networking e conhecer as pessoas certas, o que normalmente anda junto com o caminho anterior de empreender
    Também dá para trabalhar em uma empresa famosa como o Google e depois ir para uma menor, tornando-se um peixe grande em um lago pequeno
    Ou é preciso cair nas graças do seu chefe e do chefe dele, para ser a próxima pessoa nomeada quando seu superior direto pedir demissão

    • O ponto importante é a percepção de que as pessoas em cargos altos são inteligentes, mas pessoas igualmente inteligentes que não estão em cargos altos não tiveram oportunidade
    • Todos são bons pontos
      Uma coisa que aprendi é que, quando você vê uma empresa promovendo e contratando executivos por motivos que não sejam competência, é hora de começar a procurar outro emprego
      Eu não sabia disso nas entrevistas, mas na minha empresa anterior os cargos de VP para cima eram quase monopolizados por pessoas ligadas ao CEO, independentemente de qualificação
      Havia algumas pessoas que tinham sido promovidas por mérito ou que subiram naturalmente no processo de aquisição, mas, com o tempo, elas foram sendo substituídas ou rebaixadas de forma constante para abrir espaço para amigos e até familiares dos executivos de nível C
      Um executivo de nível C com quem era ótimo trabalhar foi rebaixado a VP, e um amigo de longa data do CEO assumiu aquele cargo de nível C
      O executivo rebaixado tinha anos de experiência nas melhores empresas do setor e até havia se mudado com a família para o outro lado do país por causa desse cargo, mas o sucessor não tinha nenhuma experiência naquele setor
      Pediram àquele VP que ficasse para que o velho amigo do CEO pudesse aprender o trabalho e assumir, e ele foi “autorizado” a manter suas opções de ações
      Isso abriu meus olhos para como nepotismo e lealdade funcionam em algumas empresas
  • Esta citação chamou especialmente minha atenção
    É a parte que diz que o motivo de VPs de engenharia vindos de frontend serem relativamente raros é que os problemas técnicos mais urgentes das startups normalmente estão em escalabilidade, confiabilidade e arquitetura de backend
    Já trabalhei em empresas em que, no passado, todos os líderes eram de backend/infra e o frontend era subestimado, e vi casos em que a qualidade do código desses desenvolvedores backend era bem terrível
    Fico me perguntando se existe uma correlação inversa entre representatividade na liderança e talento em engenharia

    • Quando se diz que “a qualidade do código dos desenvolvedores backend é terrível”, se você não sabe por quais critérios está medindo qualidade de código, há uma grande chance de estar focando na coisa errada
      Eu sou alguém que saiu de engenharia frontend e virou tech lead, e acho que desenvolvedores escolhem seu foco de acordo com suas inclinações pessoais e os valores que consideram importantes
      Pessoas que escolhem frontend e desenvolvedores backend geralmente têm perfis diferentes
      O que é código terrível?
      A formatação é inconsistente ou feia, os nomes de variáveis não são descritivos, o código não está bem dividido ou estruturado de forma agradável?
      Sinto que desenvolvedores frontend tendem a julgar código por valores superficiais
      Especialmente em organizações centradas em engenharia, você é reconhecido por resolver problemas
      Muitas equipes funcionam bem o suficiente sem uma pessoa central de frontend, mas muitas ficam instáveis sem um engenheiro forte de infra ou backend — ou, melhor ainda, vários deles
      Essa é a realidade
    • Há vários fatores aqui, mas um deles certamente é gênero
      O desenvolvimento frontend é frequentemente codificado como feminino e visto como menos importante
      Ex.: https://thoughtbot.com/blog/tailwind-and-the-femininity-of-c...
      Na indústria de tecnologia, também há uma tendência de associar liderança a características codificadas como masculinas
      Então não é nada surpreendente que liderança e um histórico em frontend sejam vistos como algo que não combina muito
      A mesma dinâmica de gênero também se aplica ao código
      Para mim, parte de um bom código é ser bom para outras pessoas e bom para colaboração
      Mas, se você quiser agir como um techbro machão, alfa nerd, pode fazer cowboy coding sozinho e exibir sua genialidade
      Nesse caso, o objetivo não é colaborar de perto com a equipe e construir junto, mas ser um contribuidor individual incrível que salta aos olhos da gestão
    • Acho que alguém que olha para uma área que não conhece bem e pensa “não vejo problemas ali, então deve ser fácil” muito provavelmente também é ruim na área que acredita conhecer
  • VP de Engenharia não é um cargo que possa ser padronizado e comparado entre empresas
    Na minha empresa atual, diretores frequentemente comandam organizações de até 500 pessoas, e VPs normalmente comandam mais de 1000, às vezes 3000 a 5000
    Não faz sentido tratar o VP de uma startup com uma organização de 50 pessoas como equivalente a um VP de FAANG com uma organização de mais de 1000 pessoas
    Não é que um seja melhor que o outro; as habilidades necessárias são claramente diferentes
    Na prática, já vi pessoas que receberam o título de VP em empresas pequenas não entenderem essa diferença e ficarem chocadas ao se candidatar à FAANG e receberem oferta para cargos de gerente ou gerente sênior

    • Antigamente trabalhei em uma empresa pequena de 40 pessoas, e havia um VP e um diretor em um departamento de 2 pessoas
      Era completamente sem sentido
      Pela minha experiência, aquele VP tinha, pelos padrões de uma grande organização, experiência de nível de estagiário, mas tinha entrado cedo
      O diretor era ainda pior, e as duas pessoas que reportavam a ele eram competentes
  • Eu gostaria que o pessoal da Honeycomb passasse um pouco de tempo melhorando visivelmente o produto em vez de escrever posts no blog
    Tive o azar de usar Honeycomb na empresa, e ele simplesmente não era utilizável em sistemas que interagem com mais do que alguns serviços
    Não entendo por que existe tanta expectativa exagerada em torno dessa empresa

  • Estou lendo este texto tendo em mente que um VP da Honeycomb é parecido com um gerente sênior em uma grande empresa de tecnologia

    • Essa pessoa está aprendendo formas eficazes de gerenciar gerentes
      Pelos padrões de uma grande empresa, isso corresponde a um diretor
  • Na minha experiência, contribuidores individuais constroem produtos, gerentes constroem pessoas, diretores constroem processos, e VPs criam políticas
    Todo mundo acima disso é etapa de aprovação de solicitações de orçamento

    • Gosto muito desse enquadramento, mas, nesse caso, parece faltar quem cria a estratégia
      Isto é, se você não considera política e estratégia a mesma coisa
      Se por acaso a ideia for uma piada sutil de que ninguém cria estratégia, é uma boa piada