- O cotidiano e a trajetória de carreira de engenheiros dependem muito de qual orçamento paga seu salário: vendas/marketing, pesquisa e desenvolvimento ou manutenção
- Engenharia no orçamento de vendas/marketing fica perto do dinheiro e é fácil de medir, mas pode levar a stack ranking e a uma cultura de competição interna
- O orçamento de pesquisa e desenvolvimento emprega a maior parte dos engenheiros dentro da organização de produto e valoriza valor de longo prazo, de trimestres ou mais, e a transformação do trabalho em ativos, mais do que experimentos de curto prazo
- O orçamento de manutenção é tratado como alvo de otimização de custos, e sysadmins, operação de sistemas legados, parte da engenharia de plataforma e trabalhos em ferramentas internas podem cair nessa categoria
- Saber a qual orçamento seu trabalho pertence ajuda a incorporar às decisões de carreira as mudanças frequentes em funções de crescimento, o investimento de longo prazo em P&D e a baixa prioridade da manutenção
Três orçamentos dividem o trabalho de engenharia
- Salários em engenharia de software saem, em linhas gerais, de um de três orçamentos
- Vendas/marketing
- Pesquisa e desenvolvimento
- Manutenção
- A natureza do orçamento afeta o modo de trabalho no dia a dia e a direção da carreira do engenheiro
- Essa distinção pode ser útil ao pensar em visão de carreira ou posicionamento
Orçamento de vendas/marketing: resultados imediatos mensuráveis
- A engenharia que faz parte de organizações de crescimento tem resultados fáceis de quantificar
- A estrutura em que fazer determinado trabalho aumenta os números é relativamente clara
- Esta categoria inclui funções como growth engineer, sales engineer e devrel
- Fazer produtos existentes venderem melhor
- Fazer as pessoas conhecerem funcionalidades
- Ajudar compradores a adotarem ferramentas em seus fluxos de trabalho
- O que a empresa espera é impacto imediato
- A vantagem é que fica fácil entender o retorno sobre o investimento, e o trabalho se conecta diretamente à receita
- Como a medição é fácil, a comparação entre pessoas também fica mais fácil
- Pode surgir stack ranking entre funcionários
- A cultura de competição interna pode se tornar mais forte do que uma cultura de resolver problemas em conjunto
- O ritmo de trabalho geralmente é focado no curto prazo
- O próximo experimento
- O próximo cliente
- A próxima tendência de marketing
- A empresa avalia o valor com base no múltiplo gerado pelo dinheiro colocado nesse orçamento e, no processo de buscar otimização, pode surgir um efeito de porta giratória
Orçamento de pesquisa e desenvolvimento: ativos que se acumulam com o tempo
- Pesquisa e desenvolvimento, ou P&D, é a área que emprega o maior número de engenheiros
- Normalmente fica abaixo da organização de produto
- Empresas maiores podem ter organizações reais de pesquisa ou ciência
- Esta categoria inclui funções como product engineer, researcher e architect
- Criar aquilo que a empresa vende
- Ou explorar algo que a empresa poderia vender se funcionasse bem
- O que a empresa espera é crescimento ao longo do tempo
- O ambiente é relativamente mais calmo
- Busca um equilíbrio entre reter usuários existentes e funcionalidades que atraem novos usuários
- Pode se inclinar para crescimento ao criar funcionalidades que aumentam a ativação, levando usuários do cadastro ao uso real
- Também pode se inclinar para pesquisa ao explorar novas linhas de produto
- Em empresas com um departamento de pesquisa de verdade, há pessoas trabalhando em ideias que talvez não virem produto por vários anos
- P&D é, na prática, uma categoria que agrupa dois orçamentos diferentes
- Desenvolvimento e pesquisa são diferentes
- Mas o ponto em comum é o foco em resultados de longo prazo
- O menor período de interesse é trimestral
- O trabalho dos engenheiros é projetado para se tornar um ativo e entregar valor por vários anos no futuro
- Experimentos mais curtos são degraus nesse processo
- Medir resultados é difícil, mas a empresa vê esse trabalho como investimento
- A premissa é que, quanto melhor o produto fica, melhores ficam as vendas e a retenção
Orçamento de manutenção: custo que se quer reduzir
- A manutenção, em geral, foi absorvida dentro do trabalho de desenvolvimento
- O que esse orçamento deseja é otimização de custos
- Sysadmins, pessoas que mantêm sistemas antigos rodando e, às vezes, platform engineers entram nessa categoria
- A empresa vê esse trabalho como custo puro e tenta minimizá-lo
- Em muitas empresas, funções de manutenção se espalham dentro do desenvolvimento de produto
- É um trabalho que não é muito valorizado
- Mas, quando alguém fica incomodado o suficiente, acaba sendo resolvido
- A empresa às vezes apresenta como um benefício especial dar tempo aos engenheiros para lidar com NFRs, ou requisitos não funcionais
- Situações como receber 2 dias por sprint para cuidar de tarefas incômodas entram aqui
- A construção de ferramentas internas também pode entrar nesta categoria
- Há painéis administrativos que permitem operar a empresa
- Mas que nem sempre recebem prioridade suficiente
O que a posição no orçamento sinaliza para decisões de carreira
- O orçamento ao qual um trabalho pertence determina a experiência cotidiana do engenheiro
- Trabalhos de crescimento são mensuráveis e mudam com frequência
- Trabalhos de pesquisa são mais calmos, mas têm resultados nebulosos
- Trabalhos de desenvolvimento são considerados valiosos e se acumulam com o tempo
- Trabalhos de manutenção são tratados como algo que pode ser cortado a qualquer momento
1 comentários
Comentários do Hacker News
Além de saber de qual rubrica do orçamento vem o salário, também é preciso entender como a organização avalia o desenvolvimento de software, porque isso tem grande impacto na carreira
Se a empresa for uma consultoria que vende tempo de desenvolvimento, serão valorizadas a habilidade de lidar com clientes e a capacidade de criar um software razoável rapidamente; se for uma empresa de produto que vende software, será valorizada a capacidade de criar e operar software
Se for outro negócio que inclui software em parte ou é viabilizado por software, será valorizada a capacidade de entregar dentro do orçamento, mas é difícil virar o protagonista no palco
Curiosamente, essa divisão combina bem com as três categorias mencionadas pelo autor: consultoria corresponde a vendas/marketing, produto a P&D e o restante a manutenção
Quando fui engenheiro sênior em uma startup de software, fui tratado como estrela, com stock options e a cultura de escritório que se esperaria; e quando fui consultor sênior em uma empresa de consultoria de TI, eu precisava ser mais parecido com um vendedor que faz bons PowerPoints
Eu precisava maximizar as horas faturáveis, e não podia terminar o projeto rápido nem com o mínimo de código possível
Dá para imaginar mais ou menos onde estou agora
Isso não é algo que se compra como produto de prateleira; normalmente é uma gambiarra forçada de vários sistemas altamente customizados, que muitas vezes nem foram projetados para funcionar juntos
Cada empresa também faz de um jeito diferente
Eu gosto desse trabalho e sou bom em pensar no sistema como um todo, atravessando vários departamentos
Para abrir caminho pelos problemas, também é preciso conhecer a política interna, e é exatamente aí que está o meu valor
Como programador eu também sou razoável, mas não chego no nível de especialização de quem fez da programação a carreira principal
Nos outros dois casos, você vira um custo que deve ser minimizado ou eliminado
Só quando você está construindo o produto principal da empresa é que se torna um ativo que traz receita
Eu também cometi esse erro, fui chamado para uma reunião e ouvi a pergunta “como está indo?”, seguida imediatamente de “não entre em detalhes”
Trabalhar no tipo 3 significa criar soluções tediosas e esquecíveis, e você pode acabar criando soluções tecnicamente corretas, mas que são suicídio político
Por exemplo, se você trabalha em um fabricante de hardware, é difícil não só ser protagonista, mas até mesmo ser respeitado
As pessoas de software são custo, tratado como um custo que, se possível, ninguém quer pagar
Mesmo que você entregue no prazo e abaixo do orçamento, isso não vira destaque; você simplesmente desaparece do radar
É difícil entender quando dizem que, na cultura tecnológica moderna, manutenção fica sempre no fim da lista, sofre cortes e nunca recebe orçamento adequado
Ao longo de 20 anos, passando por várias empresas, ouvi isso repetidamente, mas quase nunca concordei
A empresa quer novos recursos para lançar no mercado, mas ao mesmo tempo também quer que o serviço funcione direito
Mesmo em demissões em massa ou congelamentos de contratação, já vi organizações com perfil de SRE resistirem melhor do que organizações de P&D
Dito isso, em uma empresa houve uma mudança para uma cultura de continuar criando coisas novas e não recompensar a manutenção do que já existia, o que levou a migrações contínuas de ferramentas internas, descartes sucessivos e migrações pela metade
Quando as pessoas que criaram o produto eram promovidas e partiam para o próximo trabalho de portfólio, o que antes era novo e brilhante logo ficava abandonado, e uma nova equipe criava mais um substituto
Em 6 anos, uma ferramenta interna foi substituída quatro vezes por novas ferramentas internas, e os usuários ficaram espalhados entre as quatro
Dá para chamar isso simplesmente de falha de execução, mas uma cultura que diz que o negócio não valoriza manutenção é muito nociva e leva à autodestruição
Suponha que, cada vez que um desenvolvedor adiciona um novo recurso, ele consuma US$ 1.000 em espaço em disco e gere US$ 10.000 em nova receita
Suponha que o administrador de sistemas compre um grande servidor de arquivos, e que cada novo servidor custe US$ 500.000
Em uma organização burocrática, o administrador de sistemas repassa internamente o custo do espaço em disco ao desenvolvedor, e quando um novo servidor de arquivos é necessário, o dinheiro já está reservado
Em uma organização bem administrada e menos burocrática, a liderança entende que a fatura de US$ 500.000 viabiliza um projeto que vai retornar US$ 5 milhões, e paga com gosto
Em uma organização mal administrada, a liderança fica horrorizada porque US$ 500.000 parece caro e não está vinculado a um projeto específico; então o administrador de sistemas diz que a próxima pessoa que precisar de US$ 1.000 em espaço em disco terá de pagar US$ 500.000, e a pessoa recusa
No fim, o administrador de sistemas passa a negar solicitações e a convencer desenvolvedores a reduzir a retenção de logs de 7 dias para 3 dias, e logo a liderança começa a ouvir feedback negativo sobre ele
O ambiente descrito parece mais um caso em que o negócio de fato não valorizava manutenção
A frase “manutenção fica no fim da lista” parece menos uma prescrição do que um retrato do que realmente acontece
O autor não chegou a analisar por que isso ocorre ou se outra abordagem seria melhor para o negócio, mas se você valoriza algo que funcione direito e tenha alta qualidade, naturalmente esperaria outro resultado
Se, porém, pouquíssimas empresas agem assim, provavelmente existe alguma razão relacionada ao alinhamento de incentivos
Porque você não consegue vender manutenção para o cliente; o que dá para vender são recursos
Do ponto de vista do desenvolvedor, manutenção também é um trabalho que muita gente prefere evitar
É difícil colocar manutenção como um item brilhante no currículo, e todo mundo quer ver resultados, projetos lançados e tecnologias modernas
Manter o serviço funcionando no nível exigido pelos clientes é prioridade alta para todos
Nenhuma empresa quer reduzir SRE a ponto de perder clientes por causa de falhas
Mas SRE está mais para operações em empresas tradicionais, isto é, uma função inevitável para entregar o serviço, e não o mesmo tipo de manutenção que se tenta adiar o máximo possível
Nesse sentido, manutenção seria algo como reduzir dívida técnica, melhorar ferramentas internas e encurtar o tempo de iteração de experimentos, e esse tipo de trabalho muitas vezes é subestimado em relação ao impacto no produto
O texto fala da segunda, e diz que ir para a categoria 3 é suicídio de carreira
A menos que você seja do tipo “promoção ou rua”, talvez valha pensar em passar um tempo no 3
Claro, software começa a envelhecer no momento em que é usado, então mesmo quem acha que está no 2 talvez passe, na prática, a maior parte do tempo no 3 e só uma fração muito pequena no 2
Ainda assim, o orçamento é alocado uma vez por ano, ou no máximo algumas vezes, então se nesse momento você estiver em algo classificado como 2, ainda estará em posição melhor
“Vendas/marketing” e “P&D” são categorias que você pode ver no relatório anual de uma empresa, mas manutenção não aparece desse jeito
Vale a pena ler as demonstrações financeiras da empresa
Você verá “custo das mercadorias vendidas” ou COGS, “despesas gerais e administrativas”, custos extraordinários como fusões e aquisições, e cada item tem dinâmicas diferentes, que também variam de empresa para empresa
Também é importante entender a estrutura de negócios do setor em que você atua
Mesmo nesta thread, muita gente conclui que certa empresa “não valoriza” engenharia de software, mas comparar uma empresa de mídia social com margem bruta de 70% com uma empresa automotiva ou aeroespacial na faixa de 15% a 20% é ingenuidade
É natural que um setor consiga contratar mais engenheiros, pagar mais e oferecer mais brindes e benefícios
Mesmo dentro da mesma empresa, algumas linhas de produto e funções recebem investimento de longo prazo, e certas linhas de produto têm margens maiores que outras
O dinheiro disponível para gastar em produtos de software varia muito conforme o orçamento
Engenheiros precisam olhar para as finanças da empresa ao pensar no próprio trabalho
Empresa não é caridade nem igreja; é um negócio que precisa equilibrar fluxo de caixa, receita, estratégia de longo prazo e custo de desenvolvimento de produto
Este texto também é bom, mas o texto do patio11 explica muito bem em termos de centros de custo e centros de lucro
Ele argumenta de forma convincente por que você deve estar ligado a um centro de lucro, e há muito conteúdo bom ali se você ainda não leu
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
A regra nº 2 é assumir, dentro desse centro de lucro, um papel com ligação contínua e confiável com a lucratividade
Não precisa necessariamente ser você quem gera dinheiro diretamente, mas deve ficar claro que, se você parar de trabalhar, haverá impacto direto no dinheiro
Mudando um pouco de assunto, achei o Serverless Handbook que o Swizec escreveu alguns anos atrás muito útil e, por muito tempo, acompanhei com prazer sua newsletter por e-mail, sempre ponderada e perspicaz
Ele está firmemente no campo do “aprender fazendo / aprender em público” e é muito bom em compartilhar o próprio processo de aprendizado
Recomendo fortemente seguir ou assinar
Historicamente, a engenharia de software fazia parte da função de TI, e TI surgiu a partir da contabilidade
Antes de as máquinas fazerem isso, “computador” era literalmente o cargo de uma pessoa
Ainda hoje, em muitos negócios, a contabilidade continua sendo o principal motor do software e a origem do orçamento
Na prática, existem quatro categorias de orçamento
A nº 1 é pesquisa e desenvolvimento, que normalmente recebe tratamento tributário especial e créditos fiscais
A nº 2 é vendas/marketing, que inclui engenheiros de pré-vendas e, às vezes, trabalho de implementação
A nº 3 é manutenção, com desenvolvedores que corrigem bugs e fazem trabalho de código não relacionado a P&D, geralmente sem tratamento tributário especial ou créditos
A nº 4 é operações em serviços de hospedagem, PaaS e SaaS, onde normalmente uma parte dos salários de engenheiros de software está incluída
Entender as implicações tributárias de onde vem o dinheiro no orçamento e de que tipo de trabalho está sendo feito é muito importante, e isso fica muito mais complexo à medida que a escala aumenta
Acho melhor o modelo de centro de lucro vs. centro de custo
Idealmente, todo departamento é responsável tanto por receita quanto por custo
Se não dá para medir, então é um problema de KPI
Os KPIs podem ser definidos de forma excessivamente orientada a custo e acabar desalinhados, mas isso não transforma o departamento em si em um centro de custo
Mas gostei do acréscimo da distinção de P&D
Acho que equipes focadas em manutenção também precisam fazer P&D para reduzir custos de manutenção, assim como uma boa equipe de vendas faz P&D para aumentar o lucro de vendas
Eles oferecem insights diferentes e podem se complementar
Em nenhuma das empresas por que passei o salário de engenharia de growth vinha do orçamento de marketing
Também nunca existiu um “orçamento de manutenção” separado; era tudo simplesmente P&D/engenharia
As expectativas podem variar muito dependendo da equipe ou da função, mas isso não é uma questão de orçamento, e sim de como a empresa acompanha seus objetivos
Ou você está ganhando dinheiro agora, ou está criando valor de longo prazo, ou está afundando lentamente com um produto existente