TL;DR

• - Real history on the best engineering team that I’ve worked on.
• - Talks about engineering culture, autonomy, trust, impact, and more.

Warning: this history does not begin with success and glamour. I became the leader of a team of 3 engineers, where 2 decided to leave the company and the last one asked to move to another business unit, caused by a reorg and the end of a product they worked for. Probably It was the worst team start in history.

HIRING

It could be a tragic ending, but we were actively recruiting at that time and we had two candidates that were great at the interviews, they had good experiences and were being underrated at previous companies, after a mutual match both started to work with us in time to avoid the crash of the team.

CREATING CONNECTION

At first, the mood of the team was a strange thing to define, with some feelings of failure mixed with a glance of hope for better days. This started to change on our retrospectives, we decided to add a team-building section right before the biweekly retro meeting. At each session, one team member was responsible for bringing one activity, an example of activity is the: 2 facts and 1 lie about your life. That’s a good way of even in a remote team creating a sense of proximity and trust by knowing a little bit more about the others that work with you.

BUILDING PURPOSE

Once people had connected themselves, it was still missing a connection with the business to create purpose and ownership. So we made a few sessions to create this mission, and some topics were co-created by the team:

• - What the team is and what is not
• - Weakness and strengths
• - Letter for the future
• - Mission statement

DEVELOPING SELF-AWARENESS AND AUTONOMY

At this point, the team mood was quite different from the beginning, people were comfortable with their daily activities and were working with a sense of belonging and focus toward our mission goals. So it was time to start looking into our flow efficiency and increasing the autonomy of the group.

To help with this step, one mentor recommended me a book called: “Accelerate: The Science of Lean Software and DevOps”. This book brings scientific research looking into hundreds of companies pulling out characteristics and how to measure the performance of their teams, and what capabilities they should invest in to drive higher performance. Using the KPIs from the book and incrementing with the ones that made sense to us understand how much value we were delivering to the user and to the company, we set up a routine of measuring, digesting, and acting to improve things that were not that good.

DELIVERING IMPACT

The show time was about to start. The product manager brought up a business problem that was about creating a transfer money flow required by the central bank, with a huge scope, complex use cases, and a restricted time box that made it impossible to achieve.

But not everything was bad, at this time we had our metrics in place, so after refining the problem we applied a statistical model called “Monte Carlo” to map our delivery forecast and give an estimation to the business stakeholders. This map made clear to everyone that with such scope and team size would not be possible to deliver what was required. So we made a task force to replan the scope, breaking small deliveries of the most important things first, we also rethink tech on how to use frameworks and how to adapt services already made to that necessity, and after all those rearrangements, we started to code and build things.

The result came as expected, an engaged team, with a clear scope, clear mission, right tooling, and autonomy was more than capable of taking this challenge and delivering it smoothly, task by task tested by a group of insider users and then gradually roll outed to thousands of users. The rest of the scope that was deprioritized at the beginning came back to the backlog and was also delivered over the next weeks.

THE END

After this challenging delivery, the doubt look that some had over our team changed to admiration and pride. Of course, this is not an ending, after this situation the team passed through many other changes and challenges, but with a clear vision of the process that took us to that place before, it was easier to pass through the phases of reshaping to find performance.