Participating in Daily Standups

Purpose of Daily Standups

You should leave a daily standup:

  1. More energized than you entered it.
  2. Aligned to be in contact after the daily with anyone if your or their main task needs discussion.
  3. Remembering everyone’s update.

Things outside of Daily Standups that can ruin Daily Standups

  1. If team communicates 1-to-1 a lot and not on shared channels.
  2. If people are tackling too many things at the same time.
  3. All basic management deficiencies.

How to prepare for a Daily Standup

Half an hour before the Daily Standup, stop for 5 minutes and:

  1. Decide what is the one initiative you will mention.
  2. Write it down in your own words.
  3. Edit that down to 280 characters.
  4. Include expected time to finish task at the end.
  5. Say it aloud.
  6. Improve the wording or delivery until you have a clear and memorable update.

How to decide what to mention in a Daily Standup

By decreasing order:

  1. Task you are doing that is most problematic.
  2. Task you are doing that you know someone can help you with.
  3. Task that is going well.

How to listen well in Daily Standups

  1. Keep a log of Daily Standups and make notes of every update.
  2. Come back to that log half an hour after the daily and read it again.

Trusting the Scrum Master in Daily Standups

If each team member delivers their update clearly, nicely and concisely, the Scrum Master will have time to:

  1. Ask about important items that were not selected by the team.
  2. Raise questions.
  3. Ask about extraordinary additions to people’s update.
  4. Align people for pairing on issues raised.
  5. Use the extra time for having a bit of fun and enjoying the team before it gets back to work.

My Year in: Software Development

The year of 2018 has been a wild ride for me. It started at, the startup I described a year ago. We were in the process of putting out a successful MVP, engaging clients, becoming accelerated by Harvard University and closing out an excellent seed round with important investors. All this in just a few months.

Very quickly my job morphed from do-it-all (think product and CTO duties, plus co-founder responsibilities) to team-building. This was a highlight as I was lucky to bring in great people like Gabriela Seabra, Nathan Queija and Rodrigo Nonose, each respectively owning mobile, web frontend and backend. On the design side, did great work.

For the first time I felt fully ready to create a digital company in style. The Elixir-React stack worked beautifully, we rolled out features fast and the development team became a cohesive unit very quickly.

Towards the middle of the year, as the company reached 14 people, it had become clear to me that there wasn’t a good cultural fit among the founders. It was one of those very painful decisions but ultimately not difficult to make when visions don’t intersect well enough: we parted ways amicably at the end of July and I went looking for a new job.

That month was tense for me. I knew I had a deadline to basically stop getting paid, my wife was 6 months pregnant with twins and I had nothing lined up as far as work.

I am part of Toptal’s network of freelancers and that was one of the main ways I tried to find the next thing. I found something that really interested me: they had posted an opening to join their Core Team. I applied, passed, and joined the team as a freelancer in August. 

The first few weeks were hard in a sense: I and two other developers coming from Toptal’s talent network had a kind of secondary status, without access to many tools. Luckily our teammates were extremely helpful and welcoming. In a few weeks we became official team members and got access to what the other engineers see.

My team works on Toptal’s public pages, from home to skill pages, basically everything a logged out user can access in the website. 

It’s been a tremendous experience for me so far, as it’s the largest organization I’ve been a part of in technology. Toptal is in fact the largest fully distributed company in the world today. As such, I work with people from all over the world, and that’s the part I like best. To do it from home is the cherry on the cake as my children are very young and being close to the family is priceless at this moment.

At my team I’ve experienced the most well-developed set of processes I’ve ever come across. The firm has reached a level of maturity that allows for very well written task tickets, a proper retrospective at the end of each sprint, interesting strategic discussions among executives, and work that has large-scale, immediate impact. On the other hand, I am very far from top strategic decisions and information, and this feels weird to me having run my own company for so many years.

To a very large extent, this was the year when, for me, technical concerns became secondary to human concerns. Sure, if you’re starting a product alongside just one other person, what tech stack exactly to choose is of paramount importance. In a team of 200 that’s much less important, as each person can focus on a narrower part of the work, and the human interactions can catalyze or hinder progress.

Thus, I gave myself the chance of observing all the teams in the organization: dialogs, processes and rituals. Whatever was visible to me, I tried to learn from. It wasn’t long before I got the opportunity to onboard newcomers, help interview candidates, conduct daily standups and interface with other companies. That’s not to say I didn’t study programming this year: I continued my deep-dive into the Elixir codebase, studied GraphQL, some more Elm, algorithms, some Python and a little bit of Natural Language Processing.

It’s much easier to paste some code or links to a framework and illustrate what goes on as a programmer. Human interactions seem to me much harder to communicate. A book that does a great job of explaining management applied to software is The Manager’s Path, by Camille Fournier. I read it this year and it very neatly sums up many things we learn the hard way, plus many others I simply did not know.

So this year was one in which I started out as CTO and ended-up as an individual contributor. But each experience has taught me a lot about management and leadership, which will be my way forward in technology.


A Personal Review of Task Trackers

tl;dr: My favorite is Pivotal Tracker.

Last night a friend of mine asked me about task trackers. This text is my response.

Trackers I know off the top of my head:

  • Pivotal
  • Asana
  • Jira
  • Trello
  • YouTrack
  • Github Projects

Trackers I’ve used for at least a couple of months:

  • Pivotal
  • Jira
  • Trello

Trello has very low support for any kind of “point system”.

The “point system”, which consists of assigning “points” to estimate task complexity or time to finish, is a little contentious. It’s difficult to agree upon the criteria for one “point”. I learned from the folks at CodeMiner 42 to give one point to each task estimated to take from 1 minute to one morning (half a day). Simple as that. The idea is just to try and have all tasks simplified into one point. After a while the results start to show the overall performance, with almost no time wasted estimating tasks.

About 2 years ago I used Trello with a kind of plugin for points. It was very rudimentary and did not generate reports later, so it was not very useful. I am not aware of improvements to this in Trello.

Jira is very complete, and can even be installed in your server. The version I used the longest was installed that way. Consequently, it was and looked very out-of-date. You can choose many variations of Kanban and others, but the interface is bloated and visually confusing. I was unhappy with Jira.

Pivotal Tracker, as I said, is the one I like the most. I really like the fact that it’s just two lanes: Backlog, for tasks that are estimated and prioritized, and Icebox, where you throw ideas to be thought about later. The app is very powerful, and with Epics and Tags you can really organize and grow a board without going crazy.

It’s very easy to change the status of a task. Instead of dragging-and-dropping to lanes, you click Start-Finish-Deliver-Accept or Reject. It’s a simple improvement but on the aggregate it’s significant.

I’ve heard good things about, apparently a newcomer to this competitive problem space, but I haven’t tried it yet.

I’ve played with Github Project, but at least at the time it missed many basic project management tools.

For the last couple of weeks I’ve been using YouTrack. It resembles Jira but seems more well finished, and I haven’t seen the analytics part in detail yet.

So this is a summed up version of my feelings for task trackers.

Even if you work alone, a task tracker is an amazing stress reducer. As the team grows, it becomes more and more fundamental. If you don’t use one, I encourage you to try as many of the above as you can and see which you prefer.

Carta da Parceria de Investimentos – 2017

Caros parceiros,

o retorno do nosso fundo (ainda sem nome: note nosso baixo nível de gastos, inclusive em marketing) em 2017 foi de 29,44%. A cota encerrou o ano a R$0,97086.

Lembrando que as primeiras cotas, estabelecidas a R$1,00, foram lançadas em 25 de julho, fica claro que tivemos um ano em que o primeiro semestre foi muito bom e o segundo semestre foi ruim. Movimentos assim não são de surpreender a quem está com um portfolio muito concentrado. Terminamos o ano com 4 empresas no portfolio: Hering, Tarpon, Metisa e uma participação nova e relativamente menor na Cyrela.

Nosso fundo superou o índice Bovespa, que subiu 26,86% no ano, em 2,58% pontos percentuais.

Em 2017, descontando leituras de livros e artigos sobre o assunto, dediquei 113 horas à análise de empresas — mais que o dobro do tempo dedicado em 2016, que tinha sido de 53 horas. Este ano que passou foi o primeiro em que trabalhei ao longo dos 12 meses nas análises.

Entramos em 2018 sabendo que a grande liquidação de 2015 e 16, em que encontrávamos um número relativamente alto de empresas saudáveis à venda por menos de 10 anos de seus lucros, acabou. Podemos ver uma dispersão grande de preços relativos, porém em sua quase totalidade as empresas ficaram mais caras nos últimos dois anos em que o Ibovespa subiu mais de 73%. Meu trabalho é justamente identificar e comprar as raras exceções onde podemos adquirir um real por cinquenta centavos. Os melhores investidores da história demonstram que basta uma dessas situações por ano – ou menos – para termos ótimos resultados. Isso não torna o trabalho menos difícil, portanto chegamos a um bom momento para revermos os principais erros de 2017.

Nosso maior erro de 2017 começou no meio de 2016: a Eternit. A Eternit vinha dando dividendos excelentes para seus donos alguns anos atrás, e depois suas ações despencaram quando sua principal fonte de receita, os derivados de fibrocimento, ficaram próximos de ser proibidos por evidências sérias de efeitos nocivos à saúde de seus mineradores. Me tornei sócio quando tudo isso já estava claro, faltando apenas a decisão do STF sobre a proibição. Minha hipótese era a de que a Eternit sairia do fibrocimento, hipótese essa reforçada pelos comunicados da empresa enfatizando linhas de louças e metais para banheiros. Meu erro foi muito simples e doloroso de admitir: eu não estudei os percentuais de receitas de cada linha de produto, atraído pela valoração realmente incrível considerando apenas o histórico da empresa. Comprei ações a pouco mais de duas vezes o lucro médio recente (10 anos) da empresa, que praticamente não tem dívidas. Quando o STF sinalizou a proibição da manipulação da cresotila, apenas então fiquei curioso o suficiente para ver a evolução das linhas alternativas de produtos e ficou imediatamente claro, como teria ficado antes mesmo de eu comprar se eu tivesse tido esse cuidado básico, que os produtos novos compunham um percentual baixo demais da empresa, e que tudo leva a crer que ela precisará passar por um processo muito profundo de reinvenção para voltar à proeminência do passado. A perda de 10% que tivemos com a Eternit não reflete o tamanho do erro, que poderia ter sido até mais doloroso já que a ação caiu outros 21% desde o momento da venda.

Nosso segundo maior erro de 2017 foi temperado por uma enorme dose de sorte: Guararapes. A Guararapes, conhecida por ser dona das Lojas Riachuelo, esteve à venda por múltiplos muito atraentes – múltiplos dos seus lucros, que fique claro. Foi o que considerei suficiente para comprar. Apenas alguns meses mais tarde estudei o fluxo de caixa da empresa nos últimos 10 anos, e a história era bastante diferente, com uma média negativa em 10 anos. Pelo visto não fui o único a cometer esse lapso, porque quando finalmente dediquei cerca de 10 minutos a analisar o fluxo de caixa, a ação da empresa já tinha subido mais de 80%. Vendi com um lucro médio de quase 90%, o que não impediu a empresa de subir outros 40% logo após a venda.

É claro que um ano acima da média não pode ter sido feito só de erros, e os principais acertos, ao menos à luz do escopo limitado de apenas um ano, foram a Hering e a Metisa. Dois casos claros de reversão à média, o arroz-com-feijão do que alguns costumam chamar de investimento em valor. Partindo do que podemos enxergar hoje, os fundamentos de longo prazo de todas as empresas que compõem nosso portfolio levam a crer que continuaremos sócios pelos próximos anos.

Venho me informando sobre a possibilidade de criar um “clube de investimento”, modalidade que vai ser um upgrade ao nosso arranjo hoje bem informal para algo mais formal e que permita que tenhamos valores mais significativos no portfolio, inclusive com a entrada de mais pessoas que manifestaram interesse. Volto a falar sobre isso com antecedência se e quando a migração para o clube estiver para acontecer.

Um ótimo ano para você, seus familiares e amigos!

Gustavo Saiani

My Year in: Software Development

2017 ends for me, at least in terms of software development, on a much higher note than it started.

From January till October I worked on a financial startup through Toptal. I was part of a team of between 5 and 15 people over the period, and my duties were far more restricted than what I’m used to: mostly markup and styling.

I did the work inside Ember but never warmed to the framework. I’m sure it was not because of technical matters per se, rather mostly because I perceived the framework as not picking up traction, therefore not deserving of much investment. It was hard to flow with it since auto-reloads were quite slow and the style of getting and setting values always felt strange to me.

There’s a lot I learned in this project in terms of organizing teams and the main lesson was: if you hire remote team members, embrace that fact full-heartedly. This is not to say that you either do it remotely or locally, but if you have even one team member that is working remotely, you should do everything as if the whole team was remote, otherwise the interactions will break down fast. I’d go further and say that dev teams should work as if remotely even if the team is local, persisting all relevant decisions in writing, avoiding one-to-one communication in favor of groups to save on recommunication and following the basic protocols of remote collaboration.

All the while, I kept spending some time on Elixir, and was always happy doing so even though the language has all but become hugely popular thus far.

Another significant change in my process was my move from Atom to Vim. Yes, the entry barrier is significant, and a bit more so since I use the Colemak keyboard layout, but I am very glad I did it. After a while you’re much more productive in Vim, and it’s a more direct connection between thought and writing. It took about 3 months for me to feel as productive in Vim as I had been in Atom.

Sometime in the middle of the year, a couple of fellows got in touch about starting a company in the real estate sector. After much talk we decided to join forces and we started

At I was free to choose the stack for a greenfield project, and so I chose Postgres, Elixir/Phoenix and React for the web client. Postgres is the dependable relational database, with (I trust) more native support for geolocation, so I didn’t hesitate there. Elixir and Phoenix wasn’t much more of a difficult decision either: I trusted the language entirely, felt the tools are at a very reasonable point, enjoy using it a lot, and thought we could attract good developers to use it. So far it’s worked out that way, and as I get ready to hand over most of the Elixir side to a new team member, we talked to a number of pretty great developers that are fond of the language and excellent at it.

Finally, the React decision was a bit more difficult, and even though I consider myself a frontend developer, has been more fraught with difficulties. It’s hard to say I’d choose React again. I probably would, but I really don’t know if we’d been doing better with Vue.js or maybe even Elm.

EmCasa needs a lot of good SEO, so it needs server-side-rendering and very controllable html headers. It took me a while to sift through a few of the available possibilities, that being the main con of polylyths. Finally I made progress using Next.js, which has been a pleasure to use. I ended up throwing out Redux and I haven’t regretted it. I think Next.js has a good path ahead of itself.

We have a long list of ideas to implement at EmCasa, our backlog is public, and so are our backend and our frontend. If you’re reading this and would like to chat with us about joining the team, check out or write me at gustavo.saiani [at]

3 Dias como Mentor no Navecamp

Semana passada, de 17 a 19/2 de 2016, participei do Navecamp como mentor, a convite da Lindalia Junqueira e da Renata Salvini, que coordenam o NAVE / Estácio de Sá.

Para quem ainda não conhece, o NAVE é o núcleo de empreendedorismo em tecnologia da Estácio. Em pouco tempo, eles estabeleceram uma das, senão a melhor reputação na área de aceleração de startups no Rio de Janeiro. O espaço, incrível, foi concebido com a participação do meu irmão e de seu escritório. Como amigo da Lindalia e da Renata há vários anos, e tendo considerado seriamente participar do NAVE como empreendedor com o Look in Tens, fiquei honrado e empolgado de participar.

Ao aceitar o convite, já intuí que iria aprender muito mais do que ensinar. Não deu outra.

O Navecamp é um processo análogo a um Startup Weekend, onde os empreendedores vivenciam em pouco tempo os processos de geração de ideias, validação, vendas e apresentação para potenciais stakeholders. Participaram as 20 startups da turma 4 do NAVE, cada uma tendo entre 1 e 5 membros na equipe. Fui um entre 10 ou 12 mentores.

Para mim a experiência foi uma série de aulas maravilhosas que ia recebendo, enquanto ajudava os empreendedores a pensar e articular suas ideias. Em comum, todos transmitiam uma vontade genuína de fazer muito bem o processo. Tivemos algumas startups já com produtos praticamente prontos, enquanto a maioria está na etapa da lapidação da ideia.

Ao mesmo tempo em que busquei, especialmente no primeiro dia, ser uma espécie de espelho das startups, para ajudá-las a entender como estavam articulando suas ideias, acabei naturalmente fazendo esse exercício a respeito de mim mesmo. Como explicar sua ideia em 5 palavras? Como explicar o espírito por trás do produto de modo muito sucinto? E por que isso é tão importante?

No segundo dia, o foco foi na validação da ideia: confirmar ou desconfirmar as hipóteses. Essa parte me impressionou, porque entram em cena vários mecanismos psicológicos. Para começar, quem estava ali havia apresentado e foi aprovado em cima de uma ideia de startup — ou ao menos assim lhes parecia. Talvez o ato de buscar furos nas hipóteses parecesse errado para todos no contexto do Navecamp. É uma parte realmente difícil, em que precisamos de uma auto-crítica implacável e ao mesmo tempo manter a mente positiva quanto ao todo.

Conforme foi ficando mais claro que o importante era uma validação que trouxesse respostas úteis, as pessoas foram aderindo um pouco mais a uma validação bem franca. No final, poucos invalidaram categoricamente suas ideias, e os que fizeram saíram mais, e não menos, entusiasmados com o processo. Às vezes um giro de 1° no timão faz toda a diferença — o superutilizado termo “pivotar” nem sempre ilustra que os ajustes das ideias podem ser muito simples e muito eficazes.

No terceiro dia, os empreendedores montaram e apresentaram um pitch de 3 minutos cada. A evolução em apenas 3 dias foi gigantesca— em enorme parte por mérito dos orientadores do NAVE. Eu mesmo pouco participei de eventos de startups, provavelmente pela minha resistência a um formato mais industrial envolvendo pitches curtos. O Navecamp abriu minha cabeça também quanto a isso. Entrar em contato com 20 equipes em tão pouco tempo foi muito interessante. Quem conseguiu usar bem esses 3 minutos passou uma mensagem forte para quase 100 pessoas do nosso universo, e mais importante, abriu portas para continuar conversas depois.

Os papos com os mentores foram excelentes. Foi bem marcante também ver a atuação da equipe da NAVE conduzindo o Camp: Lindalia com um jeito carinhoso e ao mesmo tempo muito estratégico, esbanjando sensibilidade nas conversas com os empreendedores. Uma mentora consumada. Renata, que de outros carnavais eu já sabia que é muito fera, com uma atuação super executiva, de fazer acontecer, organizando a cabeça das pessoas e fazendo fluir um processo bem desafiador, sem perder a ternura. E o Bernard de Luna, um cara já bem conhecido no meio das startups e que ensinou muita coisa para mim e para todos ali: fundamentos e sacações de pitch, como submeter suas ideias a validações, como estruturar tanta coisa de um jeito bacana e coerente. Nos pitches, Bernard conduziu tudo com grande sagacidade e sabedoria, fazendo perguntas certeiras que conseguiam ajudar a pensar e ao mesmo tempo dar energia para todos seguirem em frente.

Saí de lá bastante grato por ter participado e muito bem impressionado com a iniciativa da Estácio.

3 dicas para novos empreendedores digitais

Ao longo dos últimos 8 anos, conversei com muitos novos empreendedores digitais que procuram meus serviços, ou mesmo um bate-papo, para ajudá-los a dar o start em suas startups.

Acima de tudo, considero esse movimento muito saudável, e há mais de duas décadas essas pessoas vêm trazendo muitas novidades positivas para o mundo e para nosso país.

Nessas conversas noto 3 erros comuns e fáceis de explicar. Corrigi-los não é tão difícil, e vai dar mais eficiência ao trabalho de começar uma empresa digital.

1. Não revelar a ideia do negócio

É compreensível a relutância em contar para um quase desconhecido a sua ideia de startup. Eu mesmo assino diversos NDA (non-disclosure agreement) todos os anos, para que o empreendedor se sinta confortável em falar sobre seus planos.

Na prática, entretanto, essa proteção é contraproducente: a ameaça de alguém roubar sua ideia é praticamente nula. Todos nós temos diversas ideias, que por nascerem de experiências próprias, quase sempre são as que nos mobilizariam de verdade a começar um negócio. E, seja qual for a ideia, ela vai demandar um esforço enorme para ser implementada, sem contar prováveis mudanças de curso ao longo do processo.

Ao não falar abertamente para um grande número de pessoas sobre sua ideia, o empreendedor perde a chance de receber feedback de quem provavelmente conhece muitas ideias semelhantes, e às vezes idênticas. Já aconteceu comigo, por exemplo, de estar em uma reunião após ter assinado o NDA, ouvir a ideia, e perguntar para a empreendedora se ela conhecia as empresas X e Y, que me pareciam ser bem semelhantes à ideia que ela apresentava. A empreendedora não conhecia, e ao entender o que faziam aquelas empresas que já existiam, acabou encerrando a reunião, entendendo que precisaria aprofundar seu benchmarking.

2. Já tenho designer, marketing, e agora só falta programador

Por diversos motivos, a relação de oferta e demanda para encontrar designers e pessoas de marketing é muito mais favorável do que para encontrar bons programadores.

Todos esses papéis têm importância fundamental numa startup, mas o número de horas necessário para se programar um MVP típico é normalmente muitas vezes maior do que as horas necessárias para se desenhar um bom produto, ou para levar ao público um esforço de divulgação. Mais tarde no ciclo de vida de uma startup, com um produto lançado e funcionando, essa relação pode mudar bastante — no início, entretanto, é assim que tipicamente funciona. É bem mais difícil para um programador entrar apenas pelo equity se ele vai precisar se dedicar integralmente ao produto durante vários meses até que ele seja lançado.

3. Vou pegar um programador melhor, que já tem emprego, mas como freelancer à noite e fins-de-semana

A não ser que sua startup tenha um produto incrivelmente simples, o que nunca é o caso, a pessoa que for programar seu produto precisa estar nas melhores condições para trabalhar. Após passar 8 horas programando em um dia, mesmo o mais extraordinário developer vai ter seu rendimento reduzido a uma fração do normal. No fim-de-semana, após 5 dias trabalhando 8 horas, a mesma coisa acontece. Em termos de incentivo, esse arranjo também não ajuda muito a startup a sair do papel, porque o alinhamento de objetivos é, na melhor das hipóteses, apenas parcial.

Como fazer melhor

Considere a possibilidade de falar sobre sua ideia de startup com o máximo de pessoas interessadas, sem se preocupar tanto com possíveis consequências negativas.

Aceite que a energia dispendida para ter bons programadores, em tempo e dinheiro, vai ser considerável. Procure bastante, busque referências, veja projetos que os programadores já lançaram, pergunte em detalhes sobre o que fizeram nos projetos.

Ao encontrar alguém bom, faça um período de teste (uma semana, por exemplo, mesmo que seja part-time). Dando certo, garanta que ela vai trabalhar nas suas melhores horas e remunere-a para isso.