Around May 2020, right at the start of the pandemic, a team was born at Ambev Tech to build Ambev’s new product promotion platform in Brazil. The team was remote from day one, still learning to cope with new routines and with the explosion of Zoom meetings.

Leaving out other roles such as product owner and coordinator, the team looked like this:

• Me, recently promoted to architect, but with experience in the Hércules work model
• Another architect, who had just joined the company
• An intern still in high school (who did great work and was hired full-time)
• A few developers with a year or less of experience, coming from the Padawan Program, some of whom had experience with Python, C# or React
• An experienced developer who had just joined

In short, we had a team with very varied backgrounds and experience, spread across a very wide range of skills, and with a huge challenge ahead. Right from the start, it was clear we needed to level up the team quickly to give the new product a strong start.

Our strategy

The strategy we chose was to create a weekly knowledge-sharing event within the team.

That seems like a natural move in this kind of situation, but we flipped who was responsible for the presentations. It wouldn’t be the most experienced members presenting tools and technologies every week, but the people who had just learned them for the first time.

Of course, in that case the learning curve will be pretty steep for some people. That’s why many of these tasks are done in groups. Mobs naturally form on Zoom to solve a problem, or a more experienced developer jumps on the Zoom call to help and guide as needed.

Can an intern take on complex tasks?

On our team, the answer is yes. We encourage everyone on the team to pick, whenever possible, tasks that are outside their comfort zone.

This means a task to create a new pipeline in Azure DevOps will preferably be done by someone who has never created or touched a continuous integration pipeline.

Intense learning

At Ambev Tech, we use a modern tech stack, which naturally involves dozens of tools and technologies.

Our microservices are containerized with Docker and run on Kubernetes clusters on AKS. We use Datadog to monitor our applications, logs, and APM traces. Sentry for error tracking in production. Relational and non-relational databases. RabbitMQ and Azure Service Bus. We have microservices written in C#, Java, Python and Go. Microfrontends built with React and Redux. SonarQube, Nexus, HotJar and many others.

Since at first everything was new to most of the team, there was more than enough material for several presentations a week. Whenever someone on the team picked up a task involving something new, like a new library, tool, or technology, or applied some technique or learned a best practice, they were right away encouraged to prepare a presentation for the team.

They say teaching is the best way to learn. When preparing a presentation for the team, a person pushes beyond what they learned to get the task done in that Sprint.

When preparing a presentation, even a short one, they’ll spot any gaps in their understanding of the topic and research it further, deepening and strengthening what they learned.

And when they present to the group, they spread that knowledge, and the team’s command of the tech stack grows exponentially.

A safe environment

Since a good part of the team was new to the field, it was essential that we provide a safe environment for them to give these presentations.

That’s why, at first, the presentations were only between the two architects who kicked off the event and the less experienced developers. Presenting to a smaller group was less emotionally demanding.

Our focus at that point was giving them feedback, free of judgment, so they could improve their presentation and communication skills until they felt comfortable bringing in other team members.

We had two presentation formats, chosen freely by the presenter:

• Light talks: short presentations, between 10 and 20 minutes long
• Tech talks: medium and long presentations, 30 minutes or more

Being able to give really short presentations helps make the experience more manageable at first. At the end of each presentation, we have a Q&A session.

We kept this up for a few weeks. In less than three months, the whole team was taking part in this weekly event. Every Friday ended with a relaxed moment of knowledge sharing within the team.

In a very short time, they lost their fear of presenting. Communication within the team improved, the quality of the slide decks went up a lot, and the team ended up reaching enviable performance.

Today, all our presentations are recorded and made available to the whole company. Since the team is now well established, we’ve expanded the event, which now includes a few more squads, ensuring its continuity and enabling great exchanges of experience.

A high-performance team

At Ambev Tech, we use some engineering metrics inspired by the book Accelerate: The Science of Lean Software and DevOps.

To illustrate the results we got in just a few months, by the end of 2020 our numbers were already quite impressive:

• Lead Time of 20 days (per epic, from being prioritized in a Sprint to completion)
• MTTR (Mean Time to Restore) of 13 minutes
• Deploy Frequency of 2.6 production deploys per day
• Change Failure Rate of 3.5%, meaning only 3.5% of releases introduced errors detected in production
• 95 points on the NPS survey

Reflection

This strategy worked very well for our team, and it’s spreading to other corners of Ambev Tech. With it, we managed to avoid a scenario of individualized learning, and reached a model where learning is collective; where ideas spread faster, flow, and bear generous fruit. We built a strong team, with an excellent relationship; a team where collaboration is a first-class citizen.

For me, what matters is treating each other with respect and humility, and knowing how to listen.

Sometimes we need to leave our comfort zone and put ourselves in the teacher’s seat. Other times, all we need to do is put on the white belt and be willing to learn.

Podcast

I also had the chance to talk about this topic on the Ambev Tech Talk podcast. You can check out the episode at this link, or right below: