I learned to spin up a business from scratch (still suck at it), to work on things I've not previously done, but most of all learning to interact with the venture capital market from a different perspective: being a founder. So far all my interactions with VCs were as an executive, in board meetings and so son.

I met a lot of different people and different styles. We collected our sea of nos and got also our yes. So wait a minute, why are we stopping?

I picked a thesis of an assistant by subscription, which can be scalable through the use of technology in the backoffice: you automate the work of the assistants, and give them powerful tools so the business can scale. Sounds great, doesn't it?

What I learned in practice though is that there's more process than technology to be built in that space. The operations with people would grow substantially and raise many issues: from handling/storage of sensistive information at scale, to creation of procedures for everything. A lot of the procedures I could not see how to automate in the short and mid-term, and the ones that could be automated were then removing the edge such a business would have in comparison to purely tech/AI based assistants.

I do believe that this can be a sucessful lifestyle business. Being realistic about it though I do not think I am the person to build that business. I am an engineer and I like building technology. Which started to lead me towards productivity more and more, and less and less towards assistance which is where we started.

For me, productivity made a lot of sense: you help people to organize and sort the information they need to handle in their day to day, and build the freaking task list that is in everyone's head but nobody has the time to write it down. Computers can probably resolve that problem a lot faster, and add real value to people who need to juggle WhatsApp, e-email, Calendaring, Slack and other tools everyday. Condensing all the information that comes from all these sources in a way that makes people more empowered sound like a great problem to resolve.

The issue though for me is that this isn't the business I set out to do. Growing the operations to have the business progress at venture capital speed was going to grow to be a distraction and a huge pain because it was not the problem we were trying to resolve to begin with. Not growing the existing business meant our runway would be short to start with because the money we would sucessfully manage to raise wouldn't be enough to build technology fast enough. We didn't even have the right team to build technology fast enough (our tech team was two people only, fantastic people, but only two).

The decision was hard, but it was crystal clear to me. I think there's potential for businesses doing assistance to succeed. But I know some of them are already struggling to scale as they need to be venture scale, and honestly I didn't want to get into that treadmill. Big people operations don't play to my strengths or interests.

At the start of the year we talked to our investors, our team and then our clients to inform everyone of our decision. Now it is just cleanup.

When I tell people this they all ask me what is next. I am not sure yet. I am thinking about the productivity question that unfolded while learning and working on the assistant thesis. I am taking some time off. I promised myself I would do that back in 2019 and never did it, so I think I am in debt with Fernanda. I am also thinking about what other experiences Fernanda as a child wanted and expected to have, and working to nurture the dreams of that little me. In that process I am sure the next chapter will become clearer and clearer.

The only solid plan I have at the moment is to run the Zürich Half Marathon! I am having a lot of fun with the training. You've always cheered for me, please do it again on this one.

One of the common mistakes I see while looking at this is to try to look at performance as an question with a single answer. I do not think there is one. When you look at your company and the team, performance must be looked at in different dimensions:

1. Company performance: one must have metrics that translate what they want to accomplish. Examples: a certain EBITDA, or revenue increase, or decreasing churn.

2. Team performance: how well this group of individuals are working together as a team.

3. Individual performance: how this one person is contributing to the team performance and perhaps (not always) to the company performance too.

The simplest one to measure is definitely the company performance. A lot of times what the CEO and CFO want to see is a clear number as an output. The question gets a bit more complex when you go down to the next items.

For team performance, I think DORA metrics do an excellent job at having an indication of performance. But there's no single number, there's no on or off switch. There are a few things to look at:

• Change Lead Time - Time to implement, test, and deliver code for a feature (measured from first commit to deployment).

• Deployment Frequency - Number of deployments in a given duration of time.

• Change Failure Rate - Percentage of failed changes over all changes (regardless of success).

• Mean Time to Recovery (MTTR) - Time it takes to restore service after production failure.

Translating those metrics to simple english: a high performance team is a team that is able to de facto deliver changes to production quickly and deliver such changes frequently, and when they deliver those changes to production, they rarely break production and when they do break production they recover from those failures very fast.

Having metrics about all this isn't that simple, so the first goal should be to be able to measure those things.

Last, but not least, individual performance. This one could be an article on its own. To simplify, I would split individual performance in three parts: (1) the work the person actually did, then (2) the commitment they've made to their team and manager and (3) the expectations written down at the company about what is expected of a person at that level and role.

Not all companies have (3). That said, (1) definitely happened as the person is working, and (2) as well because usually people do not go on a cave to decide what they should be doing. To make life easier, I would try to always write down (2). Humans have a heavy recency bias and tend to blur or forget things that fell behind in the timeline.

Over time, in particular when you're in a team with over 100 members, having job descriptions for each role, with expectations for each level is very useful, but doing it too soon might be an overkill. Never start from scratch. There are several companies who have done a good job at describing levels and roles and are generous enough to share those, Gitlab being one of those.

What to avoid when thinking and talking about performance?

Avoid making the process so heavy that becomes a burden on your team. The main reason why companies end up starting processes to review performance is because if they do not do it, managers avoid having hard conversations with their employees.

Don't be one of those managers. Have ongoing conversation about expectations, deliver and solicit feedback from your team members.

Avoid assuming you have enough context about things that happened outside of your team.

Never give someone feedback about themselves or their team at a performance discussion meeting for the first time. If you had feedback important enough to share, you should have done it timely beforehand so the other part could have done something to course correct.

When you're talking about performance of your team with other managers, the mindset should be “search for the truth” and not “how to convince everyone I am right”.

Besides that, if you're a manager of manager pay attention to the conversation within the conversation: you will likely learn more about your management team than about the individual contributors of your team in such conversations.

If you do not know how to have a hard conversation without dreading it, read Crucial Conversations. It is a great starting point.

A long time ago in my tenure at Facebook, I participated in a leadership training about biases and one exercise was called Privilege Walk. You have likely seen it somewhere online. All participants stand side by side on a line, the moderator starts to make some statements and ask everyone, based on their answer, to take a step forward or a step backwards.

The principle is very simple: it is to illustrate very visually the uneven distribution of privileges in a group even though if taking a snapshot of the day of the exercise, all the participants look very similar. In the case of this exercise at Facebook, we were all senior leaders at one of the top technical companies in the world.

This exercise touched me very deeply, and it was surprising to me how it did so. At each step I took back, I felt a sense of relief because for the very same time in my career, I would be seen for who I really was: someone who came from a place in Brazil where household income is 2.65 minimum wages (or about 653 dollars per month in today's exchange rate), who did not have access to much beyond basic education up to high school. Everything else I had to wrestle for. I learned English on my own, I learned my profession without finishing formal education. Somehow out of sweat and luck I made to that room but I wasn't the same as those people who studied in the best universities and attended all of the extra curriculum classes as they grew up.

I also felt a sense of acknowledgement for the very first time in my career because to me, sometimes it felt so so hard and it felt as if I would break and that I should give up, but I never did. In silence, listening to all these sentences coming out of this guy's mouth, I would replay memories of my life in my head. Memories of the toughest moments I had lived up to that point.

By the end of the exercise, I was by far the person further to the back of the room, by several steps (in fact I had to stop stepping back because I reached the wall). We regrouped, the moderator asked in a circle “How did this make you feel?". Some of the guys which were towards the back responded something like “It felt really great to see how far along I've came”. When it was my turn to say something, I bursted into tears and said “It has been so fucking hard”. I didn't mean the exercise, I meant my path, my career.

I felt so different to all these people. I always had, in fact. But now it was crystal clear that it wasn't about a feeling, I was different, because of who I was, because of how I grew up, and most importantly, not because of my choices, but because of things which were much beyond my control.

With time and self awareness, I started to find my own voice and feel more comfortable under my own skin in my role as a leader and in those rooms of people unlike me, but it is a continuous process and I doubt myself many times a day, most of the days.

The one thing this exercise taught me is that even in groups that seem homogeneous like this one: “all Facebook senior leaders”, there are many stories, many struggles, many paths that each person took to get to be there.

This diversity makes the group stronger, and we should look forward to it, but at the same time, we also need to be curious about each other to learn that this diversity in fact exists otherwise we might just be another one in the room to everyone else.

Being a woman makes me obviously different to most but the rest of my “baggage” isn't as obvious neither someone else's to me. I must remain curious.

Acho que o Google fez contribuições imensas para a cultura de gestão em empresas de tecnologia. Mas o Google, como qualquer empresa, também poderia ter feito algumas coisas melhor. Pelo menos essa foi a minha impressão do tempo que passei lá, e queria compartilhar alguns desses insights.

O Google foi o primeiro empregador que tive que dava grande importância aos benefícios não salariais oferecidos aos seus funcionários. Você pode imaginar: massagens no local, três refeições preparadas por chefs fornecidas gratuitamente, mesas de ping-pong e sinuca espalhadas pelo escritório. O Google também tinha lavanderias em alguns escritórios, academia gratuita, presentes de Natal e muitos outros benefícios. Em termos de emprego, era praticamente o paraíso.

Na minha opinião e experiência, o Google foi pioneiro em tratar seus funcionários em geral melhor do que jamais tinham sido tratados antes. Isso não só fazia as pessoas quererem trabalhar lá e permanecer lá, mas também falarem muito bem do Google como empregador. Era incrível para o branding do Google como empregador.

Tratar bem as pessoas ia além dos benefícios. Uma vez que você ingressava no Google, você também se sentia muito bem cuidado, o Google como empresa parecia realmente considerar seus funcionários como seu ativo mais importante. Eles tiravam todos os obstáculos do seu caminho para garantir que você (a pessoa super inteligente que – se fosse como eu – sentia que não merecia, mas ainda assim foi contratada pelo Google) pudesse se concentrar em fazer seu melhor trabalho.

Os Googlers tinham acesso ao melhor treinamento disponível no mercado para se desenvolverem: inteligência emocional, MBTI, liderança situacional, outros treinamentos de liderança adaptados à empresa. Liste aí, eu fiz todos. O Google foi, até 2012, a empresa e o trabalho onde mais cresci em minhas habilidades, tanto tecnicamente como SRE quanto nas chamadas habilidades interpessoais, ou “soft skills”. Também aprendi as melhores ferramentas de gestão para ajudar os membros da minha equipe a entregarem seu melhor trabalho. Sinto que no Google eu também cresci como ser humano.

O Google também tinha um conjunto super estruturado de ferramentas de gestão. Tinha feedback 360 a cada 6 meses, os engenheiros deveriam avaliar seus gerentes — isso foi novidade para mim! Fazíamos calibrações a cada 3 meses. Era muito trabalho adicional, mas esse era o custo de ser uma empresa tão grande com pessoas de alta performance, certo?

O Google foi definitivamente um pioneiro, mas a indústria continuou evoluindo para diferentes modelos, e alguns deles eram mais justos e mais de fato orientados para as pessoas do que o Google que eu experimentei.

Foi no Google, em 2008, que aprendi que poderia ser líder técnico de um projeto e ter um colega de equipe, liderado por mim em tal projeto, que ganhava 30% mais dinheiro do que eu. Assim é a vida. Isso foi corrigido no ciclo de avaliação de desempenho subsequente, quando fui promovida e recebi um aumento absurdo de mais de 40%.

Foi também no Google que aprendi que, como mulher na tecnologia, eu precisava aprender sobre o jogo que estava jogando porque mesmo o processo mais bem elaborado, criado com as melhores intenções, pode perpetuar discriminação. Os comitês de promoção, na época em que eu estava no Google, não serviam bem às mulheres e pessoas que não gabavam muito de seu próprio trabalho. O RH até ajudava a organizar workshops para mulheres em Zurique para ajudá-las a escrever autoavaliações com um tom mais enfático sobre suas próprias realizações, porque palavras como "ajudei" ou verbos no gerúndio não ajudavam as mulheres a obter reconhecimento nos comitês de promoção: é sobre o que você fez, não sobre o que está fazendo. Não só participei desses workshops, como ministrei alguns deles.

Os comitês de promoção foram projetados para serem mais justos por não terem contexto sobre as pessoas sendo discutidas. Eles não deveriam ter contexto, pelo menos. Mas o que acontecia de fato era que quem escrevesse as melhores histórias conseguia os melhores resultados, não necessariamente aqueles que faziam o melhor trabalho. Minorias conhecidas por não reivindicarem créditos pelo que faziam não tinham um defensor na sala onde as decisões estavam sendo tomadas.

O Google também me ensinou as consequências de insistir que grandes engenheiros se tornassem gerentes de pessoas. Tive um bom gerente e alguns terríveis durante meu tempo lá. Eu virei gestora para isolar meus colegas das maluquices gerenciais e então pudessem fazer seu melhor trabalho. Não é uma grande motivação, eu sei. Não me arrependo da escolha que fiz e ainda acho, muitos anos depois, que meu trabalho ainda tem um pouco disso na essência.

Nas calibrações, havia algumas regras arbitrárias que não faziam sentido para mim na época: se um engenheiro mudasse de equipe, ele caía um nível em sua avalição anterior de desempenho. Essa era a minha menos favorita.

Muitos engenheiros se voltaram para a gestão como carreira, pressionados por outros gerentes para que a empresa pudesse escalar. Muitos deles se tornaram gerentes terríveis sem muitas habilidades interpessoais.

Eu não gostava do “jeito do Google” de gerenciar as carreiras de pessoas. Acho que os gerentes desempenham um papel importante contextualizando o trabalho de uma pessoa engenheira quando ela não consegue fazer isso bem sozinha. Acho que meu papel como gerente é perguntar ao gerente ao meu lado por que diabos ele está classificando o desempenho de uma engenheira como “excede as expectativas” por dois anos e ainda assim não a está promovendo e responsabilizar o gerente (e o indivíduo, se for o caso) para que essa promoção aconteça.

Demorei muitos anos para perceber, mas o Google que experimentei tinha uma arrogância de engenharia que eu não apreciava nem um pouco e, como consequência, nunca senti que me encaixava lá.

Minha carreira gerencial no Google não estava indo a lugar nenhum. Tinha ótimos mentores entre meus pares, mas minha linha de gestão era terrível. Meu gerente direto perdeu todas exceto uma mulher de sua equipe dentro de 6 meses após minha saída, e ainda assim, não deve sequer ter sido questionado. Se questionaram, provavelmente julgaram não importante, já que ele foi promovido a Diretor logo em seguida da nossa saída da empreasa.

Um ciclo eu recebia feedback de que estava focando demais em gestão, não o suficiente em resultado técnico, no ciclo seguinte eu recebia o oposto: técnica demais, não o suficiente em gestão.

Reuniões de Revisão de Design eram como pedir autorização para gerentes e engenheiros seniores para fazer seu trabalho. Essas reuniões eram extremamente agressivas, e eu sentia que nunca gostaria de apresentar lá. Parecia que, se você não soubesse todas as respostas para todas as perguntas aleatórias que as pessoas fariam, voltaria à estaca zero e seu projeto não aconteceria. Pelo menos não agora, não até que você obtesse esse selo de aprovação.

Tudo isso foi acumulando e me frustrando, e junto com as desculpas eternas sobre me promover, foi a principal razão pela qual decidi começar a procurar um novo emprego.

Uma vez que consegui um emprego e decidi sair, me ofereceram muito dinheiro para ficar. Fiz as contas…Eu tinha certeza de que nenhum dinheiro no mundo me faria feliz continuando na mesma situação em que estava. Recebi duas ofertas de emprego e tive que escolher uma. Uma era na Canonical e a outra no Facebook. Aceitei o emprego no Facebook e foi, de longe, a melhor escolha de carreira e de vida que fiz.

Sinto que todas as oportunidades no Google estavam empacotadas para presente e tinham nomes de quem seria presenteado. Mas meu nome não estava em nenhum desses pacotes. Se eu tivesse que aprender coisas para merecer oportunidades, meu gerente não ajudava em nada, nem meu diretor.

Voltando ao título que escolhi, quando as pessoas me dizem que querem construir o Google do Brasil, eu pauso. Eu não quero. Aprendi coisas no Google, mas de uma perspectiva puramente gerencial, tenho certeza de que há muitas maneiras de fazer as coisas muito melhor do que eram lá. Quero criar formas novas e melhores de fazer engenharia em ambientes de alta performance, e não copiar um sistema do qual conheço bem os defeitos.

Crédito da foto: Anthony Quintano from Mount Laurel, United States, CC BY 2.0, via Wikimedia Commons

A few weeks ago I made a post on Linkedin which summarizes an issue but I would like to take the chance to dive deeper into some of the things I mentioned there, and perhaps format this as a call for action.

As some of the readers know, a few years back I got myself surprised to hear there were over 200 women applying for Software Engineering positions I had opened at unico as part of a program called “Moms in Engineering”.

That was a moment of distinction in my mind with regards to focus on fixing gender issues in the workplace, in particular for women that are part of the technical workforce in the companies.

I am now convinced that the number of women leaving technical positions and companies to work elsewhere won't stop going down until the industry does something substantially different. Our value proposition needs to be attractive to the women if we want to keep them.

In order to keep the agenda positive here, I will focus on what I believe are things leaders can focus on to increase women participation in their technical teams.

1. Ensure you have a gender balanced leadership team in the company and in the technical team. This will require you to be able to convince some pretty senior women they want to work with you and for you. It isn't going to be easy.

2. Work to close the gender pay gap in your company. This is a very sensitive topic, and one that directly influences women's take home pay across the industry. Start by having an analyst in your company run a detailed analysis of your current situation and then you will know what needs to be done. If you think you do not have a gender pay gap issue, you're wrong.

3. Allow women to ramp up to full time slowly after maternity leave. This will allow women to find the balance they need between the early days of motherhood and their job. Trust me, this is no indication of women not caring for their jobs. Becoming a mother is such a huge change and the adaptation can be very hard. I can totally see why some women just decide to leave after being overwhelmed trying to do both at full speed.

4. Consider offering job share positions. Women want this option. Some people argue that offering this is getting women stuck in the position of being the main caregiver for children instead of forcing a change in the balance for chilcare in couples. I respectfully disagree. We need to adapt the work conditions to the reality of the world we live in and accepting this reality will make it easier for women to keep their jobs.

5. Offer paternity leave so fathers also leave their job temporarily when they become parents. This will lift off the stigma on women in their reproductive years for being “at risk of going on extended leave”. There's an organized group in Brazil lobbying for this with legislative politicians.

In Brazil, a study from Fundação Getúlio Vargas revealed that 50% of women are fired from their jobs up to two years after they return from maternity leave. Changing this will require the whole society to change and adapt to the reality of moms being more and more career active.

Companies who want to be inclusive need to go beyond happy hours and pink swag on March 8th in order to attract and keep their women employees.

Diverse teams leads to better team performance. Wake up, and please do something to ensure you follow suit.

I read a book a while back which had nothing to do with calendar management, but it taught me a lesson for life: your time is your most precious resource. There's nothing else as clear as the currency of time, and it is in fact the only real currency that exists.

We trade time for money and then money for things all the time, and even then most people seem not to treat their time with the preciosity that they should. I am likely one of these people, but over time I tried to be more conscious of it and try to stay as organized with my time as possible and as a result I can spend my time on things that make me happy at work and in my personal life.

My calendar is likely the first and last thing I look at on my phone every day. I absolutely have no brain cycles to keep my appointments in my head. This is a statement and a confession, as I was writing this just as I pinged my German teacher telling him that the next day I could not make my lesson: I had a work trip but didn't realize this was coming so soon, and I forgot to organize my agenda (ironic, I know given the title of this post).

As someone who has a very busy calendar and very little time to waste around, thinking about ways to optimize the use of time was always a hot topic in my mind. Over time, I learned to make sure my calendar matches how my brain functions. Here are some lessons and things I've learned:

1. Align your calendar with your style and with how your brain functions

Here are mine for reference, figure out what works for yours.

Larger recurring meetings in the mornings

That's how I like starting my work days. Those meetings are usually anchors in my schedule, and they ensure my days start very predictably. I spread those through the week in my mornings.

When working in a more organized team, it can also help to keep meetings with smaller more senior groups at the start of the week, and widen your audience later in the week. This is of huge help when you need to work waterfall communications for a given project/theme. It is also hard to achieve if you're not in a high level position at the company and because of that you're not in charge of most of your meetings as you're not the organizer, but worth coordinating with your colleagues if possible. If you decide to have some default arrangement, at least you'll always gravitate to that and of course there will be exceptions. That's just part of working in a team vs isolated.

Practical example:

• Its budgetting time! Everyone loves planning budget (ok, joking!). You work with your counterparts in other teams to have a budget 0.1v. At the beggining of the week the executive team approves the budget and messaging, and by Tuesday you spoke with your directs, they spoke to theirs on Wednesday or Thursday, and the whole company knows it by Friday. Voilá!

1:1s in the afternoons

I keep those to the afternoons: at the start of the afternoons with my directs, and the later it gets in the day, then with busier people. Why? Because they are more likely to be unavailable and cancel once in a while, and then by the end of my day, my calendar gets a bit more unpredictable, but there are usually work items to resolve and having a suprise 30 minutes reclaimed at my calendar by 4pm is gold.

I do not like to stack all the 1:1s in the same day. Why not? Because then I do too much context switching in a day, and that for me is a brain grinder. By 4pm I will be hating my life, even though I do not actually hate my life.

2. Keep track of all your meetings

I have a sheet with all my meetings listed in it, the frequency and the duration. I categorize those. For 1:1s I usually use: direct report, peer, client, interview, mentoring, and so on. This way I can keep track of where I am spending my time, and assess if there are meetings I should be canceling. If at some point I see I have a weekly commitment of 30 hours of meetings, I know I am doing something wrong, because its unlikely I am getting any other work done than talking to people.

For project meetings, I create categories for them based on my objectives for the next three months. As an example: at the moment I am working a lot on Alfredo's pitch deck. So everything related to this pitch deck will be categorized as such.

3. Implode your calendar every 3 months

This is a way to keep my calendar current to my priorities. There's no space for meetings that I do not remember what they are for. If 1:1s with peers, for instance, stop being relevant, I kindly remove them from my schedule and let people know we'll book ad-hoc from there on.

Every 3 months your priorities will probably have slightly changed, and your calendar should change too, otherwise you'll spend time doing busy work instead of the very things you've decided that were importan

t.

4. Build in breaks and focus time

If you do not schedule, it won't happen, so figure out how long you can keep your brain “on” and make sure you take breaks. If you work from home, those are specially important because otherwise you'll literally seat at your desk without moving the whole day. Movement is important to keep. yourself healthy.

Practical examples:

• I avoid scheduling two 60 minutes meetings back to back. For me, it is hard to stay focused, or even to digest the first meeting before getting to the second, which means I will be thinking about what just happened instead of paying attention to what is in front of me. I generally avoid hour-long meetings, but if they need to happen, they do not happen all back to back.

• I am one of those annoying people who do stop to have lunch. That is not negotiable, in particular at an office setup. Usually my lunchs at my office past lives were booked for 12 or 12:30. At that point I was already 4-4.5 hours into my work day and it was important to chance scenery, walk to a restaurant/caffee and give my eyes a break from the screen. I rarely had lunch meetings.

• I avoid scheduling more than 90 minutes in sequence (unless its for focus time). I know I need to move, and I need to pee, and I need to refill my water. I use these breaks as a way to keep up with messages, emails and what not throughout the day. If I do not do that, when I will likely multitask, which is a beautiful way to say “not pay attention to anything, really”.

Have you ever thought about any of these topics I mentioned in detail? If not, what about you block 2 hours in your calendar in the next week and do a calendar review? If you'd like my Google Sheet template, and if so I will clean it up and share.

I have to confess that every time I hear someone saying they need to hire a Scrum Master, I am a bit judgemental. Not that I dislike Scrum, I actually think it is a nice tool. The issue though is that I think each team is made of different challenges and individuals, and I do not think one methodology is the best for every single team out there.

When I think methodologies, I think of them as tools for management. There are methodologies or frameworks for everything under the sun: how to see a career as a leader, how to structure feedback, how to organize goals and objectives, how to track progress, how to run a company, how to dress for work. You name it.

There's one book about management that really stuck to me, because I think it talks not directly about this, but in touches this point in general. The book is: First, Break All the Rules, by Marcus Buckingham. It is about a study on what makes a good manager. Read the book, it is great. I will break some hearts here, but I was not surprised when I read that what makes good leaders is not about how they applied the Agile or OKRs methodologies.

Spoiler alert: the thing in common amongst the great managers they researched was that they did not follow a prescription, or a given recipe. They broke rules, adapted to the people and the situation in front of them.

Making an analogy, picking a methodology to live behind is like picking a solution without knowing what the problem is yet. It is waking up with a hammer on your hand, but not all things that will show up for you to resolve are nails.

I see teams self inflicting pain to bend their work style into rigid adoption of methodologies with the illusion that it will give them extra productivity. It won't. You risk stopping to work for the company you work for, and starting working for the Methodologies’ God instead.

So whenever you step into a training for a new methodology for anything: project management, people management, whatever, please think about it as one more tool in your toolbox. Do not ditch all others, they might be useful for you in the future.

Not everything can be solved by a “Birmingham screwdriver”.

After a lot of thinking last year, I decided to dedicate my time to Alfredo, a subscription based assistance service that aims at bringing the luxury of help to many more people. Extra time is our value proposition. You delegate, you get time back to do whatever you want with it.

Adaptive to a person's demand, Alfredo is specialized in being a generalist. Yes, a generalist in a world of specialists. Why? Because the more services, companies and professionals specialize, less will be in their scope and critical to their mission, and the more we can help them focus.

The latest advances in technology make it a great time to build an operating system that customize the service to a person's demand, anticipate needs, and finally, offload a lot of administrative tasks so they can focus on what matters the most.

Are you a business? Focus on making it sucessful, not on filling reimbursement forms. Are you a professional? Advance your career and we can plan that surprise dinner for your next anniversary. Automation and artificial intelligence will allow us to anticiate your needs in a highly customized way, and hopefully, provide high level of customer satisfaction.

Even though technology is central to us, our vision is that you're always going to interact with a human in the other side of the line. In a world full of bots, we will provide people with human interactions. Our humans will use technology as their co-pilot.

Everyday is a learning journey at Alfredo. I will talk about the mistakes I've made so far in separate posts. Above all, playing startup for me doesn't mean taking it not seriously. I play hard! It means diving into a journey of learning a lot, which is my lifelong passion, and also building a business that somehow look like me: a generalist in a world of specialization.

For now, Alfredo is focused in Brazil as a first market: its a big market and has a single language, and that reduces complexity a lot! Hopefully soon we'll be able to offer our services in other markets and I will count on my network to help validate this crazy idea, give feedback on what we've built, and realizing this vision of more fullfilling lives to everyone. Living life in their own terms: your life, your way. Do what matter to you, for everything else call Alfredo.

Next learning opportunity: creating a compeling pitch deck. :-)

I was working at Facebook (now Meta) and a skip level report — someone who reported to a manager in my team — asked to talk to me after having a promotion not go through. I will call this person Amanda.

The person started the conversation talking about the chat they had with their own managers. I will call this manager Robert.

Amanda told me how Robert said that despite how much he fought for them in the calibration and promotion committees, the promotion didn't happen and how Robert and her were devastated by the news.

I will pause now and acknowledge that dealing with employees who are disappointed at performance ratings or promotion decisions is really tough. Usually those are strong performers and this adds an extra layer of complexity. It is a tough part of the job, but one that is necessary, and one that we as a manager want to get right to do the best for the person, and also the best for the company.

What is the problem with Robert's chat with Amanda?

He really wants Amanda to like him, and to know how much of a hero he was trying to fight for what was right but look at him, poor hero now defeated. Amanda gets out of this conversation feeling bad for even asking Robert to go through such hardship for her on top of feeling bad for her promotion. She also leaves the chat without looking at the actual feedback that came back from the discussion, but somehow also feeling a sense of debt and being taken care of this this hero, her manager.

The problem here is that Robert is an agent of the company. Every manager is an agent of the company they work for. Pause for a moment and think about that: if you are a manager, you are an agent of your company.

This means the decisions of the company are also your own. If you cannot make peace with that, you probably should look at going back to an individual contributor role.

When Robert tells Amanda that he fought for her but lost, he is also implying that the company is wrongly rejecting Amanda's promotion request, and with that creating a potential liability for the company.

For Amanda, instead of getting out of the conversation with solid feedback she can work towards and nail the promotion in the next cycle from a place of agency, she is now distrusting her employer, feeling terrible about her experience, mistrusting everyone who work with her.

The only person being served in this dynamic is the manager. He believes that by doing what he is doing he is creating a closer relationship with Amanda, and creating more trust between Amanda and himself. This can be true in the short term, but in the long term Amanda will likely end up realizing the obvious: building a career that depends on a hero to save you and fight for you isn't a great idea. They will go work elsewhere, and everyone loses.

It isn't the most fun part of your job as a manager to communicate decisions, in particular the ones you do not make on your own. It is, nevertheless, a very important part of the job, and one that you should look into being profficient at.

In fact, the company decisions that you can live with as a manager is how you know you are working in a company that is a good fit for you. Even the decisions you disagree with likely should not dispespect your core values. If you do not know what your core values are, I strongly suggest you have a therapy session on it. It will shed a lot of light on your behaviors and reactions in relationships, being them professional or personal.

The reader question I wanted to answer was about how to give feedback to your boss. In my opinion, there's no great answer to this question, as managers hold a position of power and authority over their team and unfortunately, a lot of managers do not handle feedback well just as a lot of people do not handle feedback well.

So my tips here is to start the conversation from the start: asking your manager how they like receiving feedback the best, and then following a few best practices on giving quality feedback to people.

If when you ask that first question you get a blank canvas, or a surprise face from your boss, it is likely they haven't gotten that question many times, or perhaps (I hope not) that they haven't thought about the subject very much which would be a yellow flag. You can help them, offering some options:

Some people prefer to receive feedback on the spot, others like to have a meeting just to discuss feedback and improvement points. Some people prefer to get a written note before hand, others do not. Give them choise and see how your boss react to your attempt.

Then, once that door is open, you can also share with your manager how you like receiving feedback — I hope they ask you back, but if they do not, you can always share as this is the subject of the conversation, or even use their answers to add on saying things like “oh yes, I also prefer to get feedback on the spot” and they might remember it later on.

Rule number one of good feedback: praise is public, feedback is always private. Do not give feedback to people in front of others.

Then the other rules have no particular order, here are they:

• Be timely. Do not wait 5 months until you raise something. I would say one week is the max time for expiration of your example.

• Have examples and be factual about what happen, and personal about how you perceived: “in that meeting you said x, y, z” (this is a fact) and then continue “the way I felt was like…blablabla”. A blast from my past: “in the meeting we had with person x, you raised your voice several times. When you do that, I feel like the environment is too aggressive and my opinion isn't welcome, and I stop interacting”.

• Even if you have a long list of things you'd like to discuss, focus on one or two things only. Having a laundry list doesn't help as people won't manage to digest it all and can change everything at once. In addition, there might be some underlying causes for all the issues in your laundry list, so take time to think about the feedback you're giving, and the situations you're experiencing, and try to get to the root cause, not the symptom. Seeking for patterns is helpful.

• Be forward looking. What happens next? As an example, if this is about a behavior in a meeting, can you agree what you will both do when it happen next time? Can you message them right after and have a chat? Should you intervene in some way that only the two of you know what's happening?

• Stay open minded because, as an ex boss of mine used to say: “perception is reality in the eyes of the beholder”

Professional outlook

If you know me, you know that I love learning. This is at the core of what brings me joy in most things in life and work is no different. I also love helping people.

When I left my executive role at VTEX in the end of last year, I wasn't sure what I would do next. A few months later, I have an idea, and have started a small project with a couple of friends.

This project is my first full time attempt at entrepeneurship, and is called Alfredo. It is a subscription service for personal and executive assistance, to make everyday help acessible to companies and people in need. We live busier and busier lives these days, and being able to offload some tasks to someone else is something I wish I could do many times a day as a working mom.

After some research, it was clear that there were not many offers of this kind in Brazil, and I have always enjoyed helping people, so I thought this could be a great match for something that is natural to me. This is also an opportunity to use my tech skills to build an operating system for administrative and executive assistants so we can put all the fancy technology available these days to serve as many people and small businesses as possible. I will write in more detail about Alfredo in a separate post in the near future.

My plan is to focus on this project and see where it takes me and what it teaches me. If you want to chat about entrepreneurship, what technologies can do to help humans these days, or just catch up, get in touch!

The format is simple, just send your questions through this form, and I will select 2-3 questions. You can submit questions in Portuguese or English.

Picture credit: Questions by Nick Youngson CC BY-SA 3.0 Alpha Stock Images

If you worked with me ever since the pandemic, you likely know that I am a strong advocate for the remote first, or even fully remote philosophies. I think that if you have the right set of people, you can do anything. And I believe it is possible to balance remote work with intentional togetherness, and with that build great things.

After 4.5 years working from home, I decided this model is no longer working for me personally though. I will expand on this point because I think many extroverts might be feeling the same, and perhaps haven’t yet noticed what is going on just yet.

As an extrovert, I love being amongst people. I thrive on connection, and I recharge connecting with people. When I do not see people regularly, my mood gets lower and lower, I feel less and less motivated and more prone to being grumpy to those around me. In a bad mood, concentrating on things costs me more energy. I get very distracted when I am getting depressed and have the feeling that I start many things, but do not finish any of them.

For me, the informal interactions at the kitchen, or between meetings, or the chitchat at the start of an in person meeting help me fuel to be my best at work. Being my best at work is when I am the most productive, and happiest.

There is a great upside to working from home. I had the privilege over the last 3.5 years to see my daughters growing near me. I followed each of their developmental phases, the first sounds, words, and steps.

The emotional cost of this isolation feeling has been heavier and heavier on me over time. I had to make a change and even hear my own advice from a few posts ago on when to change jobs. When the lifestyle it gives you no longer works for you. Here I am: I'm leaving my CTO role at VTEX.

I feel the timing works for VTEX too: I think my number one accomplishment was to focus on hiring and developing leadership at all levels in the Tech team and that team is rock solid. Together, we have set the foundations that changed fundamentally some of the ways we do things while keeping great aspects of our culture.

For the company as a whole, I have made my contribution to land our numbers, delivering a strong Q3 with great direct contribution of our efforts in Tech, focusing on good quality engineering while still keeping customer focus.

What now?

Until March 2024, I will be still involved at VTEX as their Advisor. After that, I don’t know. I am starting conversations with a few people and companies on some opportunities and possible projects and hopefully soon will be able to update you all. Meanwhile, I am open to chat in person or grab a virtual tea together.

Back in 2005, I was working at IBM in Brazil and still trying to make sense about what my future could look like. To be honest, I didn’t quite feel like I fit at IBM: the people who brought me in were great, but a few management changes later I was stuck with a bad manager who made my life much harder than necessary.

I received an invitation to speak at a conference in Germany, Linuxtag, to present the work I did to create inclusive communities for women in the Free Software scene. After the event, I was at the Frankfurt airport when I decided to review my spam folder to check if something ended up there mistakenly (I didn’t use Gmail at the time, and the spam filters were not great).

There was an email from a Google recruiter, Leila, asking about my situation at IBM and if I would be open to speak with Google about a job. I couldn’t believe it. What did Google want with a regular person like me? Back and forth with emails, I decided to go through the recruiting process. What did I have to lose? Not much and in the worse case scenario, rumor had it that everyone who went through the recruiting process at Google got a free t-shirt. I loved my free tech t-shirts back then. So I went with it.

I had a few conversations over the phone with recruiters and engineers, and then I was invited to fly to Mountain View for onsite interviews. I still remember that I had no money for the trip. Google sent me the tickets, but I would have to pay for incidentals at the hotel. I also would have to pay for my trip from the airport to the hotel (Hotel Avante, in Mountain View). Most importantly, I would have to figure out how to make it from the airport to the hotel. I was very young and very naive. I was only 23 back then.

I scheduled my interviews the week after I had a surgery, so I could use my medical leave days “recovering” while I was traveling for my interviews.

A recruiting coordinator met me at the Google Plex and took me to a room for my interviews. The whole thing seemed like a movie. Everything seemed perfect, amazing, and I could tell people were smart just by looking at them. I felt like I was walking on clouds.

I did the onsite interviews, and they were varied: there was some white-boarding code, troubleshooting, very hard conversations, and some other easier conversations. At the end of a day that felt very long, I got a bag with my prize inside it: a white t-shirt saying “I Google” in front. I reached my goal then and everything else would be a bonus.

After the trip, I received an email saying I would have a call with another engineer, and to my surprise it was a guy from Brazil, Andre, that later on became a friend. He asked me a couple of questions, but told me the main reason for the call was to ensure I was understanding the process I was going through 100%, because the interviewers agreed my English wasn’t great. I confirmed I was understanding.

It felt like years the weeks after that call while I waited for a contact from Leila to tell me whether they would offer me the job. In Moana terms, I was way beyond my reef, so beyond that I was allowing myself to be hopeful. When that email came saying they did want to offer me a job, I was a bit shocked though.

I had a decision to make: to continue at IBM, and at my not so great computer science university, and hope that after I finished my studies I would have another dream opportunity like this, or I could just take this leap of faith to live my dream, in a city I had never been before, to work for the most desired workplace in tech back then.

So in December of 2005 I left Brazil to move to Zurich where I lived for over 6 years until I left my job at Google.

Probably if Google didn’t give out those t-shirts at the interviews, I would not have tried because I was sure I wasn’t going to make it to the end.

Image credit: PikWizard

This is a great question and one that I come across often. When to change jobs is a very personal thing. I think first of all it is important to ask yourself why this is coming up. Then check a few other signals: are you learning in your job now? Is this job enabling the life I want to live?

Why this question is coming up seem clear in your case: you think you could be learning more. The jobs I loved the most in my career were the ones where I was feeling challenged most of the time (vs frustrated or bored most of the time). Being challenged is a proxy to learning for me: I will be doing things I haven’t done yet, working with people who question what I am doing, and resolving interesting problems.

The other issue is about the life you want to live. This can mean a lot of different things to different people. As an example, it can be that you do not feel fairly compensated for your job and your current salary level does not allow you to do things you’d like to do in your life. It can also be that the lifestyle that comes with your job is one that you dislike. Perhaps you’re traveling too much or maybe not enough and this is important to you.

Six years in a single job is a good run. I would double check that feeling that you could be learning, and ask yourself if you feel plato’ed in your current situation. If the answer is yes, I would then definitely see what else could be out there for you.

#2 I love my job. Quite often though people say that I should become a manager because I am so good at dealing with people. How do I know if I should become a manager?

I assume you already have a good portion of “dealing with people” in your current job, hence the comments. Is that the part you love the most? If you’re a specialist (individual contributor) perhaps is that part of the job that you really love.

Being a manager is career change. If today you work as an engineer and part of the job is to lead people, imagine that as a manager you will do zero engineering work, and most of your days will be handling the people side. I made a post a while back about the role of the manager, you can read it here. The further you advance in your career, less and less of your work will be connected to what you do today, and more and more will be connected to managing people, teams, organizations or companies and that’s a completely different job, no matter how much people might think it is the same with a little extra.

The one thing to consider though is that becoming a manager isn’t a irreversible change. Depending on the company you work at, you can even intentionally set things up so you can try it out, and if you dislike it, then go back to what you did before.

Once I spoke to an engineer who was considering to become a manager because she wanted to be more respected and have more impact. That’s not a great reason to become a manager because a manager doesn’t get respected by default or even have impact by default, and if you do your job badly the negative impact you have then can be even bigger than the positive.

I once had a terrible past manager tell me I should work in marketing, because I was so good at communicating with people. I always saw myself as an engineer and that advice made no sense to me. Needless to say I never moved to marketing, and I have zero regrets for ignoring that advice. You need to trust your gut a bit sometimes.

One thing I confess that I struggle with sometimes is to make sure my posts are relevant, and useful to people reading me.

One way we can ensure this is the case is with you sending me questions so I can answer them! Those AMA posts will be a bit shorter format, because I want to hit at least 3 questions and not more than 5 per post, but it is an opportunity for you to get specific questions answered.

Here is the link for a form where you can submit your questions. You may send questions in English or Portuguese.

One of the most frustrating moments in such conversations for me is when people raise the action item of creating a new alert that will detect (in the future) the specific failure which caused the incident in discussion.

One of the best indicators of a solid monitoring plan for a service is the number of alerts they trigger, independent of the level. Only production problems should alert oncalls and wake people in the middle of the night. A disk is full? Hopefully I do not care, unless it causes a production issue. It should probably not cause a production issue on a large scale system of hundreds or thousands of machines.

Monitoring systems for bad behavior is an uphill battle. If you go down this rabbit role, you will spend infinite amounts of time trying to anticipate how systems fail. Let me give you the spoiler: you will fail at that. Systems will, no matter what you do, surprise you on how they fail, and people will make mistakes and you won’t be able to anticipate what the next mistake will be. No number of alerts for failure will help you keep things under control. I have been in teams that had literally hundreds of alerts configured and got a couple of THOUSANDS of alerts triggered every day. I have been oncall for a rotation that had hundreds of alerts triggered daily. You know what I did? Learned which ones I should ignore, and looked only at the high signal alerts. As an engineer in the team, you likely know which ones those are too.

Should we give up? No. Of course not. There’s a very simple way to avoid this scenario.

First, you need to separate in your mind what is monitoring and alerting and what is troubleshooting.

Monitoring and alerting

Every system has a known expected behavior. It can be predictable egress curve, it can be number of orders, or error level, or a P99 latency number. Your monitoring system should have one alert for each of one of those, and let me give you another spoiler: if you spend a few days thinking about this, your list of alerts will likely be less than 10 for the *very important stuff* which will cover most if not all incidents you will see in the future. Monitor your service or product for its good behavior, and each deviation of that should be investigated.

Is it a system issue causing trouble to the one of the main good behavior my system should display? Then this is an incident. Is this something that can wait a bit to be looked at? Then this is a Jira ticket. Is this a small single host/instance issue that a robot can deal with? Then plug a response script to this alert. Make sure this is a convention in your team and everyone knows what type of attention each level of ticket priority requires.

Up to here, do I need to know what exactly is wrong? Probably not. An alert is the trigger of an action, which can be investigation or an automated response, it can be necessary immediately or not. An alert itself doesn’t have to contain the cause of the incident. You need to take the next step and try to uncover the cause of the problem at hand. But how?

Please don’t tell me you’ll start SSHing into machines and reading logs. :-)

Troubleshooting

Those are the systems that collect data from your service, plot graphs, allow you to drill down following an error, or re-doing the path of a request that is failing so you can get to the root cause.

Those are the systems you use to figure what what that flag raised by your monitoring system actually mean.

The better the troubleshooting systems you have, the least time you will spend investigating an issue and potentially your mitigation will be much shorter. I would even argue that time to mitigate an issue is more influenced by the troubleshooting systems you use than by the monitoring system you have, because in the end of the day, even if you do not detect an issue, eventually your users will let you know things aren’t working.

My suggestion here is that you treat this particular stack as a critical service you must provide to the engineering team, because well, it is. Having a good toolset to drill down into issues is a game changer for raising the bar of the quality of conversation about how things fail when they do.

There are several types of services that are useful in this scenario, from tools such as Honeycomb.io or Sentry, to other more traditional time series collection services for metrics you care about. You can use profiling systems for CPU and memory usage, you should likely save logs aggregated somewhere (probably sampled). There are a lot of options in the SaaS world.

Without good troubleshooting systems, the second best option is to create theories about what happened and trying to then confirm or falsify them. It is a valid investigation method if nothing else is available but those tend to take a lot more time, and if you have a SLO to your customers, you’re probably not interested in lengthy investigations if you can avoid them.

Not all incidents will be simple to troubleshoot and mitigate. I’ve been involved in incidents where basically the whole engineering team lost access to all of its resources, including troubleshooting systems. It does happen, but in my experience those “omgtheworldisfallingapart” type of incidents are much less common, thankfully.

Deliberately separating what is monitoring and what is alerting will reduce a lot the amount of alerts your team gets while not affecting your ability to detect production issues. In addition having clarity that you do need to invest on something else than alerts, like a good troubleshooting system will ensure that when such incidents happen, time to mitigate will be shorter than otherwise.

Some references on monitoring:

• Google SRE’s Monitoring Distributed Systems.

• Brendan Gregg’s USE Method.

• My favorite ever time series visualisation library: Cubism.

Existem muitos frameworks para lidar com essa priorização quando se trata de produto, porém para questões não funcionais de engenharia, a não ser que vire uma crise, os times tendem a sofrer em silêncio e aceitar que a realidade se resume a responder chamados, e fazer as coisas aleatórias que são demandadas no dia a dia. Com isso, acumula-se débito técnico, insatisfação e o risco de burn out no time cresce.

E como sair desse caos?

1. Trate interrupções como parte do trabalho.

2. Foque o resto do tempo em poucas coisas importantes.

3. Aprenda a dizer não.

Tratando interrupções como parte do trabalho

Quando eu comecei a trabalhar no Facebook, eu tinha um time de exatamente 3 pessoas para dar suporte a infraestrutura de caching da empresa. O time passava o tempo inteiro apagando incêndio. Um dos engenheiros do time, que não sabia dizer não, trabalhava dia e noite resolvendo problemas aleatórios de produção, mas além dele, todo mundo passava uma boa parte do seu tempo sendo interrompido em seus projetos para ajudar a resolver problemas aleatórios.

O que eu fiz? Eu estabeleci uma escala de suporte no time. Cada semana teríamos uma pessoa prestando suporte, full time, e as duas outras pessoas engenheiras poderiam então focar nos seus projetos.

“Ah Fernanda, mas nem todo mundo é capaz de resolver qualquer problema aleatório que chega no time!” — tenho certeza que você está pensando isso. Sim, isso é verdade, mas somente temporariamente.

Depois de uns 3 meses, todas as pessoas do time serão capazes de responder 99% das requisições sem precisar de ajuda, desde que todos sejam responsáveis por ajudar a pessoa em escala de suporte a resolver os problemas (e não mais resolver as coisas elas mesmas, como antes).

Quando o time vai planejar, a pessoa gestora do time precisa então contar que 1 pessoa full time vai sempre estar resolvendo interrupções, para deixar o resto do time trabalhar nos projetos de longo prazo. O que nos leva ao próximo ítem…

Focando no que é importante

Focar em projetos de longo prazo é uma maravilha, todos concordarão. Mas o que nem todo mundo concorda é como selecionar o que é mais importante.

Eu tenho um método bem simples para equipes que tem muita carga de interrupções e débito técnico: um dos projetos mais prioritários do time deve ser o projeto que reduza tempo dedicado a tarefas repetitivas.

Voltando ao meu exemplo lá do Facebook, existiam alguns fatores que criavam esses “incêndios” que o time passava muito do seu tempo resolvendo: a) novas versões sendo lançadas em produção, e como esse processo não tinha controle nenhum, haviam MUITAS versões em produção; b) alteração de configuração em produção quebrava o ambiente; e c) shards muito quente causavam instabilidade no ambiente.

O que nós fizemos? Investimos em três coisas. Adivinhem? Automação de deployment para que fossem feitos de forma gradual (e fácil). Melhoria da cobertura de teste do script que criava e distribuía configurações em produção, e criação de mecanismos para fazer “split” de “shards” que eram detectados como ficando muito quentes.

Seis meses depois o time era irreconhecível. Tínhamos conseguido contratar mais 3 pessoas, os projetos já estavam dando muito retorno e diminuíram muito a quantidade de incidentes que tínhamos, e também a quantidade de tickets.

Dizendo não

Tendo nossas prioridades claras fez com que a conversa sobre pedidos aleatórios diminuísse, porque não dizíamos simplesmente não, nós mostrávamos o que estávamos fazendo e porque, e na grande maioria das vezes, era óbvio o que estarmos priorizando isso versus outras coisas. Algumas vezes obviamente existiam outras urgências e adaptávamos o que o time estava fazendo.

O time foi de lugar de “burn out” para um dos times onde as pessoas queriam trabalhar. Fazíamos eventos sociais juntos, nos divertíamos muito, e o time de Production Engineering passou a brigar muito menos com o time de Software Engineering.

Cacheville, como chamávamos a organização, progrediu muito com relação a excelência operacional, empoderamento do time, e também satisfação no trabalho. Aprendi muito tecnicamente, e também como gestora.

Confesso que foi um dos momentos “de ouro” da minha carreira, e sempre me lembrarei com carinho.

Muitas vezes nós gestores pegamos a realidade e aceitamos ela como fato da vida, sem lembrar que é nossa responsabilidade mudar essa realidade, e sair do caos. Sair do caos é possível, é gratificante, e é parte do que faz gestão tão significativa nas organizações: é o nosso trabalho.

I left Brazil with 80 Euros in my pocket, and no functioning credit cards, because I was deep deep in financial debt. A few months before I had received my job offer, I met a woman, Katia, in the middle of the Amazon Rain Forest. She was on vacation there with her Swiss husband, and I was also on vacation there (I had a paid trip to speak at a conference, and I decided to extend by a few days and go visit the Rain Forest because who knows when I would have that opportunity again).

Katia, that almost stranger, went to pick me up at the airport, and brought me to her house to spend the weekend. During this weekend, I told her how Lufthansa had lost my luggage, and because of that, I had no clothes to wear to go to work in that winter weather, and I had to spend my 80 Euros buying some clothes. I had no idea when my first salary would be paid, and I had no cash until then. Katia helped me with some money.

On Sunday evening she dropped me at my corporate housing, and on Monday morning I looked at a paper map (there were no smart phones back then!), left my corporate housing to then realize I had no idea where to go. I walked around a bit and read the street signs in German (a language I did not speak), but I could not figure out directions to get to the office. I went back to the corporate apartment, got in bed wearing all my clothes, and cried for good 30 minutes: what the hell had I done with my life.

Eventually I made it to the office, and started to learn what living in Switzerland meant: what were my new responsibilities, how health worked, how public transportation worked, how to rent an apartment (without money, in particular).

Some people refused to show me their apartments, because I was a single Brazilian woman. Others were a bit nicer. A lot of people refused to speak English to me. I heard “no” quite a lot.

Eventually things got sorted out, and I got into my job at Google and felt productive, but I always had this pressure in the back of my mind that if I lost that job, that also meant leaving this brand new life and going back to Brazil. My visa was sponsored by Google, and who knows if I would find someone else to sponsor my visa if I lost that job.

One of the things not a lot of people realize about being an immigrant is that your status (meaning, right to live somewhere) is tied to your employment status. If you lose your job, you lose the right to live where you live, and that can have a pretty huge impact on your life.

On one hand, at that point I already had the impression I had hit the peak of my career because I was working at Google and therefore had no much to loose, on the other hand that gave me also a feeling of not being there permanently. It also added a lot more pressure to my then 23 years old self on performing well at my job.

Life went on, and in 2012 I decided to leave Google to join then Facebook (now Meta). My end goal, and offer, was to work in the United States, but in order to get there, I would need to go through a lengthy visa application process, so they decided to do it in two steps: they applied for a visa for me to live in Ireland, and in parallel also to a H1B visa to move to the United States.

Again, my status in Ireland, and then in the United States depended on being employed. More specifically, it depended on being employed by Facebook. It was not until 2015 when I had my Italian citizenship recognised, that I gained the right (which is an immense privilege) of choosing to live outside of Brazil, independent of who employed me. The catch here is that an European Union citizenship gives you the right to live in Europe. At that point I was in the United States, and my Green Card only showed up in 2017.

I remember the day I got my Green Card. I remember even having this feeling that I should change jobs, just to exercise this important freedom I had just gained. I didn’t do it, of course, but the thought was there. It was like I could own my destiny again.

Later on in 2019 when Mark and I decided to leave the United States and live in Switzerland, we could only do that because we both had European citizenship (which he no longer has because of Brexit, and now depends on my status to be able to live in Switzerland).

In over 17 years living abroad (8 of them as an European citizen), I have seen many people have their lives turned upside down because of sudden loss of status. Families with kids, single people, you name the configuration. In the US if you’re living in a L1 visa, you have a few days to leave the country when you lose your job. You cannot get another job with another company and continue to live there. You must leave the country. It is a level of discomfort and uncertainty that anyone who considers living outside of their home country should think carefully about. Not everyone has the appetite for this type of rollercoaster.

Looking back, I think this uncertainty and pressure built upon my impostor syndrome to turn me into someone who worked extremely hard, and also someone that had their personality mostly defined by their professional status. In 2019 when I left the corporate world to start a sabbatical, I had this immense fear of losing myself, losing my identity, and of course being forgotten by the industry. Who would I be then?

Shortly after I jumped in this abyss of identity crisis, I became a mother. I guess that worked out well as an intense character building exercise.

Living abroad was the most transformative experience of my life of course because of my professional circumstances, but also because of those struggles people rarely talk about.

It is not all flowers, but it comes with the upside of living in a beginner mentality which I think is a great life skill. Living in a new country means learning everything you took for granted from scratch, and opening yourself up for new ways of doing things and new society norms.

You give up on a lot too, including sometimes the given comfort that those who choose to live in their home countries have: the comfort of knowing that, no matter what happens to your job, you can call the place where you live home.

One thing I never thought I would do, though, was running. And then I signed up to a obstacle race (Spartan Race) with some work friends, and for that I would have to run 21k, besides of course, going through the obstacles. It was November 2017 when we signed up for the August 2018 race, so I thought perhaps being able to run would be helpful.

A friend suggested a couch to 5k program, which I slowly started working through. I decided that, once I could run 1k uninterrupted, I would go to a running shoe shop and get a pair of running shoes. Anyway, that was January 2018.

I participated in some obstacle races as a preparation, but the one I was practicing for never happened because of a hurricane that happened that week, that year, in Hawaii, where the race would have taken place. But I continued to run.

In 2019 I got pregnant with Lucia, and after a few months I could no longer run. So I stopped. I restarted running after she was born, but I had loads of pelvic pain, so I stopped again and went into PT to heal my pelvic floor, just in time to be pregnant again!

Last year, when we decided to move to Zurich again, Mark signed up to run a half marathon, and I decided to sign up to run a 10k. I had never ran 10k in my life. I started practicing for that in October, and the race would be April 23. Running postpartum ain’t no joke.

I completed the 10k race a few weeks ago. I was slower than I would have liked (I wanted to complete the race under 1:15 but really I wanted to do it under 1:10. I finished in 1:11:56) and I had to walk some stretches on Kilometre 9. The sense of accomplishment was phenomenal, regardless of these mishaps. I felt great physically, as I haven’t felt in a long time.

While preparing for the race, one of the things I did with my coach (Runkeeper coach) was to set an intention for my workouts. For me it was always self-care. But after the race was over, I still needed self-care of course, but my motivation wasn’t there anymore. Why was that?

So I decided to pick up another challenge. I want to run my fastest yet 5k. And then today I went for my run, my first practice towards my fastest 5k and BOOM, there was she! My motivation was back. It felt very gratifying. And then I understood. It is about challenging myself to do things I wasn’t capable of doing before, and while at it, have time for myself, my self-care time, which is much needed to clear my head and nurture my body.

Did you reach a goal recently? What’s a challenge you’re working towards? Why do you do it?

Isso acontece porque as engenheiras são responsáveis por criar as soluções que fazem com que essas empresas ganhem usuários, valor e o mundo. Os times de produto criam teses de desafios a serem solucionados, e o time de engenharia então propõe as soluções, valida, quantifica resultados e ajuda a provar essas teses ou desqualificá-las.

Em algumas scale ups, porém, esse nem sempre é o caso. Os problemas e as soluções já chegam definidos para as equipes de engenharia, e essas então precisam tratar da implementação com pouquíssimo espaço para contribuir com o direcionamento dessas implementações, e com priorizações de projetos que não impactem o cliente diretamente (eu argumentaria que sempre impacta, mas isso é outro assunto), como projetos que aumente a eficiência do time de engenharia em si.

Na minha opinião, esse posicionamento deixa muito potencial não realizado para as empresas, e também causam um grande problema de retenção de talento.

Potencial não realizado

Pessoas engenheiras são treinadas, formalmente ou não, para pensar desafios de forma lógica, usar dados para provar teses e também usar metologias que sejam possíveis de reproduzir para quantificar o impacto das soluções que criam.

Além de pensar na solução que é necessária hoje, a equipe de engenharia sabe e deve investir tempo em soluções escaláveis, que não só vão atender a empresa hoje, mas que vão permitir que a empresa continue crescendo 2, 3, 5 ou 10 vezes no futuro.

Quando essas equipes não tem voz e não participam da concepção de produtos, provavelmente esses ítens não são levados em consideração, ou não ganham a prioridade necessária. Isso na prática causa problemas de estabilidade nos produtos e também acúmulo do chamado débito técnico, que fazendo uma metáfora, são puxadinhos para acomodar necessidades de curto prazo, sem considerar o projeto arquitetônico e de engenharia necessário para que “a casa” fique de pé no longo prazo.

Além disso, para a empresa, é um investimento que não faz sentido. É comum um sentimento de que estamos “gastando demais com engenharia” para o retorno realizado. Isso se dá porque o time é tratado como braço, e não como cérebro, e obviamente sem pensar na escalabilidade e longo prazo, a produtividade do time não aumenta proporcionalmente com o seu aumento de tamanho.

O desafio de retenção

Para trabalhar em engenharia, geralmente são necessários anos e anos de dedicação e treinamento por parte dos profissionais. Agora imagine depois de tanto esforço e dedicação, tu chegares num emprego e não ter a oportunidade de contribuir com o seu completo potencial? Não há dinheiro que faça alguém ficar numa posição assim por muito tempo.

Além disso, de um ponto de vista de engenharia, o trabalho braçal de implementação é chato, repetitivo, e não desafiador. As equipes de engenharia vão inevitavelmente passar mais e mais tempo lidando com débito técnico porque os prazos impostos pelos times de venda e produto geralmente são mais curtos do que o necessário pra fazer diligência técnica. Com isso, se torna cada vez mais difícil testar, lançar nossas funcionalidades, monitorar e no geral, ter certeza que o produto que se está provendo está funcionando da forma que deveria.

Como mercado aquecido, é inevitável que as pessoas do time de engenharia que passem muito tempo fazendo trabalhos repetitivos e medíocres procurem outros desafios em curto espaço de tempo. É comum ver profissionais que trocam de emprego com uma frequência muito alta. Além da empresa perder o conhecimento acumulado por esses engenheiros, piora a situação de aquecimento do mercado porque se vive uma espécie de leilão sem fim por profissionais que, por não achar desafios que os retenham, continuam circulando no mercado. E por continuarem circulando no mercado com grande frequência, não se desenvolvem tanto quanto poderiam em senioridade.

Big tech brasileira?

Está na hora das empresas brasileiras, muitas que almejam ser big techs, começarem a pensar grande no que diz respeito a engenharia, começando por tratar os times de engenharia como eles são, de fato, tratados em big techs: como o cérebro da empresa.

A inovação nas empresas de tecnologia do Brasil não pode acontecer só a partir de demandas de clientes e idéias do/s fundador/es. A demanda de cliente é o futuro previsível. O futuro inesperado é onde a mágica acontece, e pra isso, precisamos de muito mais cérebros engajados no desafio.

Está na hora de fechar a fábrica de software e abrir as portas para as possibilidades que se abrem com essa mudança. Daí sim começaremos a criar big techs brasileiras.