Experiência em enterprise
(churchofturing.github.io)- Trabalhar por 1 ano em uma grande empresa deixou evidente a diferença em relação aos ambientes de startup e SME
- À medida que a definição de responsabilidades e os processos internos ficam mais complexos, pontos que não eram problema em organizações pequenas se transformam em desafios sem solução
- Desperdício de recursos e desequilíbrio nos critérios de contratação geram problemas de eficiência organizacional e motivação
- Conceitos importantes dentro da organização, como urgência do trabalho e gestão de segurança, acabam se transformando em práticas formais e procedimentais, distantes de seu significado real
- Mesmo em meio a vários problemas, há experiências positivas, como desenvolvimento de capacidades e crescimento de carreira
Retrospectiva de 1 ano da experiência em enterprise
Diferenças entre grande empresa e startup
- Ao passar o primeiro ano na $ENTERPRISE, vivi na prática as diferenças em relação a startups e SMEs (pequenas e médias empresas).
- Mais tarde percebi que a falta de experiência prévia com desenvolvimento de software interno não era uma crítica, mas sim um sinal positivo.
- Organizo aqui algumas observações para apresentar a realidade do ambiente de trabalho em grandes empresas.
O que não era problema em empresas pequenas vira um grande problema em grandes empresas
- Ao resolver erros relacionados a ferramentas, leva-se muito tempo para identificar o responsável ou a pessoa encarregada.
- A falta de compartilhamento de informações dentro da organização e a troca de responsáveis geram ineficiência e desperdício de custos.
- Uma solução temporária é o override de configuração local, mas, no fundo, trata-se de uma limitação estrutural da organização.
Irracionalidade na alocação de recursos
- Diferentemente da experiência de trabalhar em empresas pequenas sem orçamento suficiente, em grandes empresas o desperdício excessivo de recursos é frequente.
- Fracassos de projetos de curto prazo e uso desnecessário de cloud levam a desperdício financeiro.
- A gestão de orçamento e recursos desconectada das necessidades reais acaba reduzindo a motivação no trabalho.
Colegas e estrutura de contratação sem consistência
- Em startups, a contratação baseada em competência mantém, relativamente, um padrão.
- Em grandes empresas, contratação e reestruturação sem relação com a competência são comuns.
- Acontecem situações em que determinados cargos não têm relação com a capacidade real de trabalho, ou em que a organização se mantém independentemente da qualidade dos relatórios.
Interpretação da urgência no trabalho
- Em startups, havia um critério de urgência claramente definido, mas em grandes empresas é necessário interpretar os múltiplos significados da urgência.
- Além de situações realmente urgentes (por exemplo, indisponibilidade de serviço), também surge com frequência uma urgência formal.
- Dentro desses processos, é necessária a capacidade de identificar as verdadeiras prioridades de trabalho.
Gestão de segurança formalizada
- Os processos de segurança têm um papel importante na organização, mas, na prática, o foco recai em relatórios formais em vez do risco real.
- Em nome do cumprimento de metas numéricas ou indicadores, tarefas de segurança esvaziadas de sentido tornam-se parte do cotidiano.
- Também existe ineficiência na comunicação entre engenheiros e responsáveis por segurança.
- O texto enfatiza o risco de uma cultura em que todos valorizam apenas os números.
A falta de significado dos cargos
- Cargos duplicados como "Head of Architecture" são comuns, e seus papéis não são claros.
Cultura organizacional que trata a incerteza como fraqueza
- Em meio a grandes reorganizações e reestruturações frequentes, líderes tratam a frase "não sei" como algo proibido.
- Apesar da complexidade do domínio, na liderança apenas imediatismo e confiança acabam sendo priorizados.
- Com isso, consolida-se uma estrutura em que erros do passado se repetem.
Times de engenharia em silos
- Cada time de engenharia (ou 'império') tem seus próprios padrões e sua própria cultura.
- As barreiras entre departamentos aumentam, e fica difícil padronizar ou disseminar boas práticas.
- A autonomia de cada área passa a limitar a colaboração entre equipes.
Experiências positivas
- Participar da comunidade de engenheiros ampliou minha perspectiva sobre desenvolvimento de software.
- Há novas formas de satisfação, como crescimento de carreira, oportunidades de mentoria e experiência com uso em larga escala.
- Aprofundamento da especialização, colaboração com colegas diversos e educação e desenvolvimento de capacidades são ativamente incentivados.
- A estabilidade, como pagamento regular de salário e segurança no emprego, também funciona como vantagem.
Conclusão
- Apesar do olhar crítico, o valor positivo das grandes empresas é claro.
- Há disposição para revisar essa visão novamente no futuro, após muito mais tempo ter passado.
1 comentários
Comentários no Hacker News
É sempre bom lembrar da Remy's Law of Enterprise Software (link relacionado: https://thedailywtf.com/articles/graceful-depredations). Se um software é chamado de "enterprise", normalmente não é muito bom. Brincadeiras à parte, achei interessantes os pontos positivos mencionados no fim do texto. Entendi alguns, mas também havia itens que, na prática, pareciam só criar ainda mais problemas. Por exemplo, há a ideia de que "existem oportunidades reais de desenvolvimento de carreira"; se desenvolvimento de carreira significa apenas ganhar mais dinheiro, então seria melhor dizer simplesmente "você pode ganhar mais dinheiro", sem rodeios. Se não for isso, fico curioso sobre o que seria desenvolvimento de carreira além de se enterrar ainda mais fundo nas ineficiências e problemas organizacionais mencionados. E quanto a "é gratificante criar software usado por milhões de pessoas", fico me perguntando se isso continua sendo gratificante quando o software é ruim ou prejudica os usuários
Sobre a pergunta de se desenvolvimento de carreira é simplesmente ganhar mais dinheiro: quando você pensa bastante sobre a vida, acaba encarando a realidade de que todos nós temos papéis pequenos dentro de sistemas muito maiores. Ao refletir sobre isso, surgem perguntas mais profundas, como "consigo ser justo em uma sociedade injusta?" e "como posso causar um impacto positivo na comunidade ocupando um papel pequeno?". Cada pessoa responde de um jeito. Algumas se movem ativamente em busca de oportunidades de mudança; outras sentem impotência dentro do sistema e simplesmente desviam o olhar. No meu caso, eu acredito no que fazemos, e desenvolvimento de carreira na empresa não é só dinheiro, mas mais responsabilidade e maior capacidade de provocar mudanças. Em uma organização ineficiente, minhas opções são sair da empresa, permanecer onde estou, ou me aprofundar na organização e tentar produzir mudanças positivas. Sobre a pergunta "continua sendo gratificante se o software for ruim ou causar danos?", algumas pessoas responderiam que sim, mas eu pelo menos não sou esse tipo de pessoa, e acredito que o que faço tem uma função social positiva. Ou seja, "é gratificante criar software positivo para a sociedade e usado por milhões de pessoas"
Em empresas grandes, desenvolvimento de carreira significa mais do que dinheiro. Por exemplo, muitas vezes surgem oportunidades de liderar projetos maiores ou desenvolver internamente um produto que antes seria algo que uma startup inteira faria. Também é relativamente mais fácil adquirir experiência participando de vários projetos ao longo de alguns anos ou liderando equipes maiores. E se o software for ruim ou prejudicial? Startups e empresas pequenas não são automaticamente melhores; depende do caso
Se você sonha com cargos como cientista de dados pesquisador ou developer evangelist, precisa de uma organização que possa sustentar esse tipo de trabalho. Funções como arquiteto de microsserviços também não combinam com organizações pequenas, mas são bem-vindas em grandes empresas com mais de 3000 pessoas. Assim como a trilha para engineering manager só faz sentido quando há um pool de pessoas suficiente, existem oportunidades de desenvolvimento de carreira que vêm da escala. E há, sim, software ruim ou prejudicial, mas o que fazemos não precisa necessariamente ser software enterprise — e eu até espero que não seja
Não acho que software enterprise seja inerentemente ruim. Claro que é totalmente possível fazer um bom software enterprise, e conseguir isso ao mesmo tempo em que se atende a requisitos complexos já é, por si só, uma grande demonstração de habilidade. Mas, na prática, raramente se avalia dentro da organização o quanto se está prestando atenção à experiência do usuário. Eu mesmo, mesmo estando há mais de 7 anos no $ENTERPRISE, só encontrei usuários diretamente uma única vez
Sobre se ainda é gratificante quando o software é ruim ou nocivo: muitos engenheiros podem se sentir satisfeitos apenas por estarem trabalhando em grande escala, ou então sentir tanta impotência que passam a encarar isso como algo sem relação com eles. Mas, para realmente ter essa escala, você acaba precisando pertencer a uma gigante, e aí inevitavelmente entra no ciclo de dark patterns algorítmicos, maximização do interesse dos acionistas e outras estruturas do capitalismo
Há um ponto que faltou: quando entra uma nova liderança, ela expulsa os membros antigos e preenche tudo com suas próprias pessoas. E todo ano o nome do time muda, embora o trabalho de fato não mude; só ficam acrescentando palavras como "Innovation", "Discovery" e "Leadership" ao nome da equipe
Se o nome do time vai mudar com tanta frequência, eu preferiria que deixassem algo fixo como "Pikachu" e pronto. Se todo mundo sabe que o nome não importa, então deveriam parar de trocá-lo; cada mudança exige atualização de documentos e comunicação geral, o que consome muito tempo e esforço desnecessariamente
Na nossa organização temos uma biblioteca interna de código de infraestrutura feita com Terraform CDK. Ela cria automaticamente recursos de monitoramento no Datadog e no Pagerduty. Um dia, o parâmetro obrigatório
teammudava tanto — praticamente a cada 7 meses — que simplesmente removiMeu rival, toda vez que entra em uma empresa nova, vai aos poucos levando junto a antiga equipe inteira de help desk e desenvolvimento. O motivo é lealdade. Mesmo que os resultados sejam ruins, ninguém reclama nem aponta problemas para a liderança. Quando você ouve ex-funcionários que trabalharam com essa pessoa, a história é sempre a mesma:
Quando palavras como "Excellence" aparecem no nome de um projeto, em geral eu já desconfio
A maior parte do texto também se aplica a órgãos públicos. Tirando o fato de que não há trabalho de fim de semana, de que existem oportunidades de desenvolvimento de carreira (técnica), e de que há incentivo ao aprimoramento de habilidades e ao treinamento, o resto é parecido
Foi um texto muito divertido e interessante. Estou há uns 3 anos em enterprise. Estou crescendo tecnicamente, mas sinto que na prática estou aprendendo mais sobre pessoas, comunicação e burocracia. Também me identifiquei com os comentários sobre orçamento e mouse. Mas, graças à estabilidade financeira do $ENTERPRISE, eu simplesmente compro meu próprio mouse. Alguém pode até levantar problema sobre um mouse não aprovado... mas é só ignorar, ou tratar essa falsa urgência de aprovação de mouse como algo sem importância
Eu simplesmente não conseguiria suportar uma organização dessas. Mesmo que me pagassem o triplo, eu desmoronaria completamente em poucos meses
A compensação é, na prática, inversamente proporcional à quantidade de trabalho realmente necessária
Só daria para aguentar tomando uma dose bem pesada de remédio psiquiátrico (Zoloft)
Às vezes penso em priorizar o dinheiro, pegar um salário alto no $ENTERPRISE, juntar o suficiente e depois entrar em um longo sabático. Mas o processo de entrevista parece tão exaustivo que só de pensar nisso eu já perco a vontade. Hoje estou no $MIDSIZENOLONGERSTARTUP, que também tem várias bizarrices próprias que me desgastam do seu jeito
Também trabalho em um ambiente parecido, e senti que este texto era dolorosamente preciso. Eu achava que meu trabalho era resolver problemas e colocar software em produção, mas, na realidade, as "verdadeiras prioridades" da organização (
revealed preferences, link relacionado: https://en.wikipedia.org/wiki/Revealed_preference) estão bem longe disso. Assim como o autor contou que foi de uma empresa pequena para uma grande, fiquei curioso se alguém aqui fez o caminho inverso, de uma grande para uma pequena. Também queria ouvir como vale apresentar experiência enterprise em entrevistas para equipes menoresPela minha experiência, isso é como um conto de duas cidades. Eu também me cansei do desperdício de tempo sem sentido no $ENTERPRISE e, hoje, aceitaria abrir mão de 20% do salário para poder produzir algo de verdade em um lugar menor e bem estruturado. Só que, mesmo tentando explicar sem negatividade o que aprendi nos últimos 3 anos, fundadores de startup tendem a ver meu histórico como algo meio pesado demais. As habilidades de sobrevivência necessárias na selva e no zoológico são tão diferentes que a reação costuma ser: será que você não ficou tempo demais no zoológico? Por outro lado, empresas grandes também querem contratar gente que entenda os processos e a hierarquia internos, então para alguém vindo de startup também não é fácil entrevistar para esse tipo de lugar
Já fui de empresa grande para pequena, e quanto maior a empresa, maiores tendem a ser os problemas de pessoas e política interna em comparação com os problemas técnicos a resolver. Em grandes empresas, é comum reter gente importante com compensações no estilo golden handcuffs (link relacionado: https://en.wikipedia.org/wiki/Golden_handcuffs), e isso faz com que as pessoas tolerem mais bobagens da organização até o ponto em que estejam dispostas a abrir mão desse pacote. Se você contar a história como "saí de uma grande empresa porque queria causar mudanças reais", equipes pequenas geralmente entendem bem
Grandes empresas se preocupam apenas em entregar de forma consistente os resultados que elas mesmas definiram. A definição de metas também acontece por muitos motivos diferentes: bater números, cumprir procedimentos regulatórios, executar decisões de executivos etc. É um universo bem diferente da racionalidade humana como costumamos imaginar
Sobre o texto original dizer que "existem outros impérios", alguém brincou que, além da Grã-Bretanha (QA manual) e do Egito (pirâmides de software), também há a Mongólia (aparece do nada com uma enxurrada de requisitos e depois some), a Espanha (tenta fazer todas as regras perfeitamente e acaba gerando só mais atrito), o Japão (leva bronca de executivos e embarca em aventuras que sabotam a própria carreira), e a China (um labirinto de reuniões e comunicação extremamente sigilosa)
Texto com ótimos insights, e que transmitiu muito bem a importância da política de escritório e do papel da gestão
Estou há 18 meses no $ENTERPRISE. A identificação com a realidade chega a doer