O maior equívoco da história da gestão foi acharem que não existe gerencia sem gerentes.

Eu comentei em um evento do Grupo de Métodos Ágeis do RS que na minha equipe não existem gerentes. Mas estava sendo injusto. Muito injusto.

O ponto é que eu acredito em algumas coisas como:

• Quanto mais tempo de empresa as pessoas possuem, mais liberdade elas terão.
• A responsabilidade de uma pessoa aumenta de forma diretamente proporcional a sua liberdade.
• Não acredito em gestão centralizada – acredito em pessoas diferentes liderando assuntos que fazem sentido para elas. Lidere suas causas! Assim seu trabalho vira diversão.
• Todos do time são responsáveis por todos do time. Ou não é trabalho em equipe?
• Auto organização – quem sabe a melhor forma de funcionar, de acertar uma tática, é o próprio time.
• Auto gerenciamento – quem sabe onde está doendo e definir ações, retomadas, ações em crise, também é a equipe.
• Não acredito em gerentes, mas sim em pessoas capazes de gerenciar. E através de vivência prática, trabalhando e vivendo problemas reais.
• As pessoas devem ser capazes de gerenciar seu próprio tempo. Assim podem gerenciar melhor o tempo do seu time e por consequência da empresa.
• … dá para fazer um livro disto, mas enfim, estes já mostram meu ponto.

O grande “problema” disto pode ser quando a equipe fica muito grande. Já passamos por situações assim e em breve vamos passar novamente. Grande para mim é uma equipe com mesmo foco, com mais de 20 pessoas ok?

Mas… medo não tenho. Porque eu tenho uma equipe que ao encontrar um desafio de comunicação, vai enfrentar este desafio. E aí vai para outro ponto que para mim é muito importante. Atitude! Que atitude você quer presente na sua equipe?

Joel Spolsky fala em se “falar menos“, e os problemas de comunicação quando temos “muitas pontas”.  Os problemas que acabamos tendo em grandes grupos. Acredito nisto, mas o bom senso aparece nestes casos. Vamos trabalhar em duplas ou trios para um determinado assunto. Não com a equipe toda. E vamos ter eventos onde todos serão envolvidos. E saber dosar isto. E saber dos prós e contras de ter um excesso de comunicação ocorrendo.

Se não controlarmos estes pontos, não será possível trabalhar no trabalho, porque vamos ficar apenas em reuniões e discutindo assuntos que podem ser discutidos em um grupo menor de pessoas. Por isto que devemos ter foco. E confiar no trabalho da equipe.

Minha resposta foi algo simples tipo, ah, 200 vai indicar que funcionou show de bola, 201 quando um objeto foi inserido, 400 quando a requisição for mal feita, 501 quando o usuário chamar um recurso que não temos. Note o uso correto da palavra recurso.

Fiquei falando um minuto mais ou menos, sobre alguns códigos de retorno HTTP. Eis que hoje olhando o Twitter do Daniel Barden encontro este tweet da @DanaDanger, que resume tudo isto:

HTTP response codes for dummies. 50x: we fucked up. 40x: you fucked up. 30x: ask that dude over there. 20x: cool.

— Dana Contreras (@DanaDanger) March 23, 2012

Em 1999 fiquei vermelho, e bem nervoso, quando fiz a apresentação do meu trabalho de conclusão. Depois outras lembranças que tenho são a partir de 2002, quando comecei a palestrar de forma mais constante. E não parei desde então. E a cada nova apresentação, uma nova lição, uma nova piada para fazer a platéia rir, e por aí vai.

Sempre me preocupei em passar a mensagem da forma mais objetiva possível, e prática. Isto vem me ajudando ao longo do tempo a fazer palestras menores. Normalmente minhas palestras funcionam no estilo “TED Talk“, focadas em no máximo 20 minutos e gerando alguma mudança. Nada de indiferença! Também gosto muito das palestras menores ainda, as Lightning Talks, com 5 minutos de duração. E eu ajudo a organizar um evento muito legal sobre elas, a #Desconf.

Mas voltando ao assunto de como melhorar suas apresentações… um dos pontos para eu melhorar era ter alguns modelos. Durante muito tempo eu trabalhei como instrutor oficial da Borland/CodeGear e hoje Embarcadeiro. E desde 1998 eu participava de eventos sobre Delphi, com apresentação de funcionalidades, sendo um “mero ouvinte”, e ali tive contato com um cara que sempre foi uma referência na arte de apresentar: Renato Quedas. Ele é um cara que eu respeito muito, e tive a oportunidade de conviver com ele alguns anos, ele na qualidade de Master Trainer, ajudando nós instrutores e consultores e se posicionar melhor em sala de aula, nas apresentações e por aí vai.

Depois estamos falando em 2006/2007, e uma das ações que me ajudaram a ver e buscar algo diferente foi quando tive contato com o material do Garr Reynolds e um livro muito legal chamado Presentation Zen. São dicas legais, mais focadas no design e formas de apresentar as informações para gerar um impacto mais positivo no público.

Outra ação foi o ToastMasters. Já ouviram falar deste programa? Em uma das empresas que trabalhei, existia um programa interno, e eu participava, conseguindo a cada semana ver pessoas apresentando e podendo colher técnicas diferentes. E aprender com o erro dos outros. Isto me fez buscar na internet também diferentes técnicas. Aí comecei a conhecer caras como Guy Kawasaki e Larry Lessig e o Lessig Method. Eles seguem sendo grandes referências para mim.

Claro… Steve Jobs por exemplo e seus keynotes milimétricos também são legais, sem dúvida! Mas o ponto é… que eu sempre gostei do improviso.

Muito.

Em uma situação, fui convidado para palestrar em uma semana acadêmica, e nesta oportunidade tinha decidido que iria falar sem ajuda do Keynote. Cheguei no evento faltando menos de 1h para minha palestra. Aí comecei a ter umas ideias e pronto, em menos de 30min selecionei algumas imagens e montei uma apresentação para me apoiar no evento. E foi show! Pode acontecer de dar errado? Claro. Mas aí é o estilo de cada um… alguns gostam de desarmar bombas. Eu gosto de palestrar improvisando.

O que eu procuro quando estou montando uma linha de palestra? Momentos para fazer rir/chorar/emocionar, momentos para fixar conhecimento (aprendizado), momentos para impactar (mudança). E isto vai em um ciclo dentro do tempo da palestra. Seja uma palestra de 5 minutos ou um curso de 80 horas.

Deixo o vídeo que apresentei no TTLabs Summit realizado em abril de 2011, falando sobre estas questões. Foi um vídeo de 5 minutos:

E a apresentação que está disponível no slideshare:

If you use GTalk embedded in a browser window as I like to use, here’s a tip to avoid enabling these desktop notifications.

I keep one of my browser windows on top of all others, so I can see it’s title bar, no matter what application I’m using besides the browser. When someone starts to chat with me, the title changes, and it kind of interrupt me, but gives me some seconds to finish up what I’m doing and then I can give the right attention to the chat window. Or defer the talk to the end of my working cycle.

Notifications for emails… no, you don’t want that. You drive your life, not emails. Build a way to make sure you are not every 5mins checking for new messages and cleaning up your inbox.

So, if I can give some tips, here they are:

• Avoid desktop notifications. Check every desktop notification you have and verify if that one is really important. If not, disable it! But hey, if you work on some mission critical support team… leave that notification active ok?!
• Make sure you have a routine to avoid checking emails every 5mins. If something is really important, teach people to call you. Or to ping you by instant messaging, SMS, os some other option that is really going to interrupt you, but for a good reason. If people call you and it’s not that urgent, also tell them they can use emails, and then you can answer back with more time. Actually, in your time.

Esta priorização muitas vezes funciona como um malabarismo, pelas diferentes áreas de negócio demandando projetos. Lá pelas tantas, se fala:

“Os modelos formais e mecanismos de priorização não funcionam mais”, diz David Cearley, vice-presidente do Gartner. “A priorização não pode ser feita de forma isolada do negócio. Precisa acontecer em estreita parceria com a empresa.”

Nesse cenário, a TI está sentindo a pressão para ser mais ágil em seus métodos de entrega, mais flexível na priorização de projetos, e mais experiente na avaliação de ROI – tudo para que possa trabalhar com, e não contra, as necessidades de negócio.

Um dos pontos é em evitar constantes “não” para os clientes. Mas o ponto não é este. O não é muito bom para testar reais necessidades. Quando um cliente requisita uma nova funcionalidade ou um novo projeto, perguntar “O que acontece se este projeto não for entregue? O que se perde?“, pode ser uma forma de buscar o real valor do projeto. Claro, você deve saber se tem um ambiente propício para isto. Senão a resposta pode ser… “Ah, o que se perde? Seu emprego.“

Quando escrevemos uma user story, queremos saber questões como o porque ela precisa ser implementada, o que de deve ser implementado, e quem se beneficia com isto. Para um pensamento mais “amplo”, em projetos, esta linha de pensamento serve igual. Isto me lembra a Project Story do Luiz Parzianello, que eu curto muito. Ela é um documento que consegue criar uma visão mais clara de um projeto a ser entregue. E é uma forma para empresas se organizarem e criarem governança na hora de escolher o que priorizar e porque priorizar. Temos outras formas de fazer isto, seja pensando em uma estrutura de Business Canvas e Lean Startup.

E neste sentido, é interessante como as grandes empresas dificilmente conseguem ver valor em estar mais próximas das áreas de negócio. E em trabalhar com ciclos mais curtos de entrega. Deixando as áreas de negócio realizarem testes, desenvolvendo produtos mais rapidamente e testando o seu resultado é pelo menos um exercício para minimizar risco. É muito importante para a equipe de desenvolvimento estar próxima dos clientes, pois assim poderão ajudar na priorização de funcionalidades em um lado mais técnico e entender mais dos processos de negócios envolvidos.

Depois no artigo, este assunto vem a tona:

O alto nível de envolvimento das partes interessadas também levou TI a repensar seu processo de desenvolvimento, passando a adotar uma abordagem mais ad hoc quando as equipes de TI passam a integrar o pessoal de marketing ou das áreas de negócios para o desenvolvimento mais rápido de um aplicativo móvel  – às vezes em questão de dias em vez de semanas ou mesmo meses.

O foco aqui não é entrega rápida de aplicativos de mobilidade. Quero focar em entrega de projetos em geral. E quando se fala em abordagem ad hoc… o que o pessoal deveria olhar são as metodologias ágeis puramente, porque muitas das preocupações citadas, são na verdade princípios e questões que as equipes ágeis valorizam.

Para que isto ocorra de forma efetiva, a formação de equipes menores para se trabalhar em projetos, dentro das áreas de negócio é uma boa solução, só que o problema é que normalmente as equipes “tradicionais” não são preparadas e estimuladas a assumirem mais de um papel. Isto deve ser trabalhado e permitido. E com o cliente presente para ajudar nas definições, os ganhos serão vistos de forma rápida.

O tempo de resposta das equipes é cada vez menor. E para que isto possa ocorrer desta forma, devemos estar leves e comprometidos com o essencial, permitindo sempre uma revisão de rumo e constante avaliação se algo pode ser melhorado no processo diário.

Vinicius Teles uma vez me disse que “o cliente só sabe o que quer depois que vê o que pediu“. Neste sentido o que queremos fazer é lançar logo software para que os clientes possam avaliar e prover feedbacks. Só que muitas empresas ainda não caíram na real e algumas só vão se ligar em certas práticas quando a água estiver chegando no nariz.

Vou relatar como tenho usado redes sociais. O objetivo de estar presente nas redes sociais, é poder manter e crescer networking. E acima de tudo, contribuir, colaborar, ensinar e aprender. Enfim, me divertir!

Networking + Currículo Vitae = LinkedIn, que me ajuda a manter contato com colegas de empresa e de pessoas que conheço em eventos de tecnologia.

Atualização de questões profissionais, exemplo palestras, artigos e coisas que acho interessante em tecnologia = Twitter (@dwildt). Tento focar muito para que tudo o que sai no @dwildt seja focado em tecnologia, grupos de usuários (exemplo o GUMA-RS ou DUG-RS ou RSJUG), metodologias ágeis (Pingos de Agilidade e aqui mesmo) ou divulgando algum site que mantenho, exemplo o Tresler (literatura / música) e o RS Basketball (Basquete)… e alguns blogs que vão virar produto (aguarde e confie) como o Compre Pouco. Ufa! Como dá para notar, busco a maior influência através de tweets.

Coisas mais pessoais ou “nada a ver”, TV (GetGlue), Nike+ (vai ter post em breve), e FourSquare = Facebook. Aqui é mais liberado, me permito lançar coisas mais pessoais do que no caso do Twitter, que sempre tem um foco no lado profissional. E para ajudar, tudo o que sai no Twitter é replicado no Facebook. Assim evito de ter que fazer posts duplicados, e ganho uns likes de vez em quando.

Fotos = Flickr e Instagram. E que nestes casos normalmente vão acabar indo para o Facebook. Se for de algum evento de tecnologia, acaba indo para o Twitter.

Apresentações = Slideshare. Tenho colocado por lá as apresentações que faço e não tenho mais enviado PDF para cá e para lá com as mesmas.

E Google+, We Heart It, FormSpring, MySpace, GoogleReader, Orkut? Eu até tenho um “login”, mas não dou atenção para elas como para as citadas acima.

Bom, vamos ao foco do post. O grande problema que eu vejo em ideias que surgem dentro de uma equipe é o processo de evolução ou morte destas.

Muitas empresas, dependendo da sua estrutura e/ou cultura, vão ter ideias que morrem por falta de ação da gerência, como já ouvi em um evento anos atrás. Quer dizer, devido a outras 1000 coisas que a gerência precisa fazer ou entregar, uma ideia positiva e legal nem terá a chance de evoluir. Nem de ser experimentada. E ninguém nem tem a chance de sentir peso na consciência, já que a ideia não está no plano de desempenho anual. :-/

Eu prefiro pensar que uma ideia perde seu valor porque a equipe como um todo deixou de acreditar nela. E que uma ideia mantém o seu valor em virtude de ações que a equipe realiza. É a chance de uma evolução mais democrática.

Ainda assim, isto não é garantia de nada.

Muitas vezes a equipe está lotada de trabalho e de tarefas que precisam ser realizadas, não restando tempo para a equipe trabalhar em novas visões ou simplesmente seguir uma ideia que é reconhecida pela equipe como boa. Muitas vezes as equipes voltam para os momentos de “loucura” e se esquecem que a melhor coisa que elas podem fazer é manter um ritmo saudável para evolução dos produtos, com qualidade constante.

Por isto, mesmo em uma equipe aberta a inovação é preciso ter algum tipo de método ou controle ou restrição para garantir que vai existir um balanceamento no que é feito em produtos existentes e novos produtos.

Este tipo de investimento pode ser medido, tanto o investimento como o retorno do que é feito.

O que se quer então?

a) Formas de testar as ideias para se ter visão pós feedback do mercado sobre a sua validade.
b) Restrições que ajudem as ideias a serem lançadas e mantidas. E que principalmente ajudem a equipe a não perder o foco.

Lembre-se. Ideias podem surgir como forma de ajudar um produto a ganhar consistência, como forma de se testar tecnicamente alguma tecnologia, ou simplesmente para testar um mercado que não se conhece.

Pode ajudar uma empresa a desenvolver seu nome pelo mercado de tecnologia.

E também pode prejudicar uma empresa. Parecia fácil né? Mas não é… qualquer tipo de lançamento deve ser feito com responsabilidade e sem perder foco na qualidade. Ela não é opcional. E portanto seus experimentos devem mostrar que o caminho está correto. Os experimentos devem ser responsáveis por mostrar o respeito e mostrar que uma ideia merece mais persistência e apoio.

How is technology evolving in your team nowadays?

What triggers new technology to be selected for a proof of concept, for some sort of research or even for an internal project?

Here are some options you can think about:

• Presentation events: build a morning or a night to get the team together and have lightning talks, 5-10 min talks about technology, management, out-of-box-thinking, things that can spark, trigger new directions to the team. Examples are TED talks or Desconf (in portuguese – this is an initiative I help).
• Coding Dojos: having a regular coding dojo agenda, can help the team to practice their programming skills, try different languages and frameworks. With this, new ideas will come up eventually and there you go, more options to use inside the team. You will also work on pairing skills, test automation skills and will find a better team integration.
• Hackatons: Think about initiatives like Rails Rumble or Random Hacks of Kindness (RHoK). Think about days where people get together to solve a problem, trying some engagement in the local community.
• Blogs: tell people what are you learning and share knowledge. Telling what your team is trying, without violating some internal rule with the company. Creative Commons content. You will probably show something that is already online, but making it easy for someone else to find and use the documentation.
• Yammer or other internal social network like Chatter: show what are you doing internally. Motivate others. Create some groups where people with same interest can share ideias and promote. Create a more online and active team sharing what’s happening. It’s a way between IM (sync) and e-mail (async) communication. And a form of communication where you want to be short and concise.

Ao comparar a mesa de trabalho dele com o jeito que eu trabalho, achei engraçado, e isto vem um pouco no quanto o profissional de hoje procura mobilidade. Senão vejamos:

1) Eu não tenho espaço para uma pequena biblioteca na minha mesa. Começa que eu não tenho uma mesa no trabalho. Então a minha solução para isto é o Kindle. Até uma boa notícia foi a chegada do livro do Eric Ries que tinha comprado em pré-venda.

2) Não tendo mesa, o porta retrato é o background do meu desktop. Na verdade um mosaico de fotos que montei usando o Picasa. Assim tenho sempre as pessoas que me motivam para lembrar durante o dia.

3) O painel motivacional não tenho, mas isto acho que é parte de se encontrar alguma coisa que possa ajudar no processo. Acho que o principal talvez seja encontrar algo que possa “quebrar” o que estiver ocorrendo e fazer você lembrar do que realmente é importante. Neste caso acho que ao invés de um quadro motivador, o legal é achar alguma coisa que possa gerar umas risadas.

4) Certamente notebook e smartphone se tornam itens importantes. Eles geram grande parte da mobilidade. Claro que para isto ser realmente útil, internet é um item mais que necessário. É essencial. Nesta lista adiciono o Kindle também. Consigo ler livros no próprio Kindle e também no smartphone e no tablet.

5) Eu tenho um bloco que uso para anotações rápidas. A folha em questão tem que ser transformada em tarefas em algum software de apoio e seguir o seu caminho para ser reciclada o quanto antes. Costumo guardar a folha na carteira ou no bolso da calça. Com esta técnica não se consegue guardar tanta coisa junta. E sobre as tarefas e planejamento do dia, tenho uma folha pequena com a lista de pendências que tenho mais um post-it para ajudar no que é prioritário no dia. Este item é post para outro dia.

6) Eu não tenho uma folhagem perto de onde eu estou, mas tipo… não tenho nenhuma impressora configurada no meu notebook. Acho que isto é um indicativo de ajudar a natureza no melhor estilo que mais ajuda quem não atrapalha certo? Impressão em PDF apenas.

E você, precisa ter um escritório inteiro para guardar suas coisas ou você consegue viver a vida profissional em uma mochila? O que você valoriza nesta história da mobilidade?

Alguns amigos tem lançado campanhas legais de contratação na internet. Vou citar dois casos.

Primeiro da galera da Intacto, de Brasilia. Legal a brincadeira do “Add New Member”.

O outro exemplo legal foi do pessoal do mailee.me, fazendo comparação da empresa com uma “acme”.

Recentemente fiz no ttlabs.cc um post sobre uma forma de contratação, usando  um gráfico para entender o perfil profissional que se busca, baseado em dica que vi no site do Steve Blank. Achei uma estratégia legal.

Ainda falando em contratações, para mostrar como trabalhar na Trevisan Tecnologia pode ser cool, a galera da Trevisan Tecnologia se reuniu e fez um podcast falando sobre contratações.

Então sim, contratar deve ser cool! Só um lembrete, importante… você deve retratar a sua real realidade. Melhor se as pessoas que trabalham com você forem as responsáveis por relatar e retratar isto para o mercado. E não uma ação do marketing. #ficadica