Skip to content

🙇🏻‍♂️‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎Manager README de Ibrahim Cesar, disponibilizado publicamente

Notifications You must be signed in to change notification settings

ibrahimcesar/Manager-README

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

17 Commits
 
 
 
 
 
 

Repository files navigation

Ibrahim Cesar

2022: Não estou mais na condição de gestor, mas manterei aqui o repositório.

As pessoas costumam me chamar apenas de "Ibra". Fique à vontade.

Profile no GitHub /ibrahimcesar
Twitter @ibrahimcesar
Site pessoal ibrahimcesar.cloud

Você não precisa me seguir em nenhuma plataforma, apenas uma referência para ver temas que eu abordo, se achar necessário.

Motivação deste documento

Este documento se aplica a mim e de nenhuma forma pode ser considerado como aplicável a qualquer pessoa de qualquer outro time ou do Nexo.

Este é o meu Manager README. Este documento é para você. Dediquei um tempo especial para escrevê-lo por que eu me importo com quem eu trabalho e gostaria que cada pessoa esteja o melhor contextualizada e equipada. Use este documento como uma introdução à forma como eu trabalho; meus frameworks mentais e operacionais e meu mapa mental. Este documento será bem sucedido se nos ajudar a ter um melhor relacionamento de trabalho.

Meu trabalho

Como Diretor de Tecnologia eu:

  • Sou responsável pela acessibilidade, disponibilidade e experiência das publicações e os sistemas que dão suporte aos modelos de negócio.
  • O principal fator de otimização de entrega de software é Segurança psicológica. Isto sempre vai estar na balança de qualquer decisão.
  • Sou responsável pela continuidade, melhoria, manutenção e acesso à todo o stack de tecnologias.
  • Permitir uma melhor eficiência e crescimento da empresa, sempre buscando atender as expectativas de negócio demonstrando claramente os trade-offs relevantes.
  • Criar o contexto ideal para que tenha sucesso, conectando o que precisamos como organização e o que cada indivíduo precisa.
  • Meu primeiro mandato é servir você, não o inverso. Estou sempre aqui para auxiliar. Me pergunte.
  • Alinhar o time na mesma direção.

Disponibilidade

Tendo a ser mais produtivo durante as manhãs. Meu período de trabalho costuma ser entre 8h00 e 19h00, com uma parada de 2 horas de almoço em que geralmente leio e faço uma descompressão para voltar ao trabalho.

Se você receber um email ou mensagem de mim à noite, ou fora de seu horário de trabalho o padrão sempre é "ele me mandou isso para não esquecer ou está trabalhando em um outro horário" e você pode completamente ignorar e responder apenas em seu período de trabalho. Eu nunca espero respostas imediatas a não ser (e se acontecer) tivermos alguma situação crítica de resposta imediata que está comprometendo nossa infra-estrutura, mas para isso mantemos um calendário rotativo on call e mantemos uma forma estruturada e definida para isso.

Eu recomendo que reservem blocos em suas agendas para períodos de trabalho que preferem não ter interrupção alguma. Isso dá visibilidade a todos e mantém sua produtividade, todos precisamos desse tempo reservado.

Personalidade

Por favor, não confunda minha timidez com frieza ou desinteresse. Eu levo um tempo para me acostumar com novas pessoas e aprecio muito e me engajo a ajudar em qualquer momento que eu possa, mas eu dificilmente fico chamando as pessoas para falar ou checar como as coisas estão a todo momento. Eu assumo que todas pessoas necessitem de autonomia e se desenvolvam assim. Não é seu perfil? Ok, me comunique e acompanho de perto. Por favor, me chame!

Filosofia de trabalho

Eu não costumo aderir a nenhuma Metodologia Ágil®. Mas eu sou extremente fã e aplico princípios ágeis a tudo o que faço. O primeiro princípio do manifesto ágil é "Indivíduos e interações mais que processos e ferramentas". Eu jogo SCRUM pela janela a qualquer momento se for o melhor para as pessoas do time. Também acredito que SAFe® faz Waterfall parecer uma boa ideia.

Eu encorajo todos a sempre pesquisarem e trazerem novas formas de trabalho e tecnologia. Para isso, sempre acho que a melhor forma é por escrito. Criando um documento, uma espécie de RFC, simplificada, ajuda a estruturar melhor os pensamentos, a forma prática de implementar e é claro, os trade-offs.

A maioria de nosso trabalho é organizado ao redor do GitHub. Parte do mesmo princípio que tenho para testes, documentação e outros: o mais próximo do código possível, um "único repositório da verdade" – single source of truth.

Para uma melhor descrição de todos rituais, ferramentas e processos, cheque o nosso guia no repositório.

Prefiro ser ágil antes e sobretudo do que Ágil®

O próprio SCRUM® Guide define que "Scrum's roles, events, artifacts and rules are immutable and although implementatting only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirely". Vários outros frameworks ágeis possuem o mesmo tipo de declaração.

Preferimos uma tática se algo funcionar, ótimo. Se não, continuamos a experimentar e a otimizar. Sermos ágeis antes de qualquer classificação Ágil®. Entendendo ágil, como um espectro:

Espectro Ágil

Fonte da ilustração: Sooner, Safer, Happier

1:1s

Compartilhamos novidades, atualizações uns com os outros. E então avaliamos baseado nas necessidades e particularidades de cada pessoa em como se desenvolver, sempre mantendo um histórico de cada conversa para termos uma evolução de cada um.

Primeira semana

O que eu espero da primeira semana de cada pessoa ao entrar no time: conhecer um pouco mais e construir confiança. Nada mais. Não espero que coloque nada em produção, apenas tome seu tempo explorando nossa base de código.

Primeiros noventa dias

Ao final dos primeiros novento dias espero que sinta-se parte do time no sentido em que está colaborando, tem segurança psicólogica e está crescendo e se desenvolvendo. E isto é um diálogo. Ao longo do tempo vamos conversando e ajustando.

Demitindo

Palavra forte. Eu, honestamente, nunca gostaria de passar por essa situação. E acredite, é de quebrar o coração para ambos os lados. Eu nunca comemorei nenhuma demissão. Mas resolvi compartilhar o contexto em que elas ocorrem. Basicamente: em um primeiro momento, a esfera do time e em um segundo, a esfera organizacional.

  • Esfera do time: Eu sigo a "The No Asshole Rule". Que traduzo como a "Regra da Civilidade". Insultos, deixar alguém incomodado, interrupções frequentes de outras pessoas, sarcasmo exacerbado, humilhação, discriminação por qualquer motivo: raça, filiação partidária, religiosa ou de linguagem de programação preferida. Ausências sem explicação – não está se sentindo bem? Mande um "Não trabalhei hoje". E tudo bem, sério. Não reconhecer ideias de outras pessoas e tratar do tema como novidade, se "apropriando". É uma lista resumida mas não exaustiva de atitudes quando regulares, frequentes, minam o time, de tão tóxicas podem levar as pessoas a evitarem reuniões e quebrar o time - viramos apenas um grupo de pessoas trabalhando juntos. Nesse caso eu sempre escolho o time, não importa a proeficiência técnica da pessoa.
  • Esfera organizacional: Já tive no passado que realizar cortes por conta de reestruturação da empresa. Esta não tenho muito o que comentar. Qualquer decisão nesse contexto sempre deixa as pessoas desligadas da empresa na posição mais frágil, que eu nunca gostaria de ter que fazer, mas faz parte do trabalho.

About

🙇🏻‍♂️‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎Manager README de Ibrahim Cesar, disponibilizado publicamente

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Sponsor this project