Compound Returns on Engineering Excellence

I see a lack of honesty in our industry when we share knowledge. Every post is intented to sell the legend because we are as great as the legend we create.

I'm going to try to be honest and share with you a simple initiative I'm trying out with my team. My objective is to solve some of the problems we have and improve our Engineering Excellence.

What is Engineering Excellence?

The truth is... nobody really knows. So nobody will give you a right answer. I went on twitter and asked the community, I read a bunch of Medium posts and I had conversations with other technical leaders. Only to arrive at the conclusion that Engineering Excellence can only be improved; it cannot be achieved.

I found out that Engineering Excellence is about how a Product Engineering team approaches problems, breaks them into steps that add value, implements those steps and learns from how the solution is performing at a Business, Product and Engineering level. In three words: plan, build and learn.

Compound Returns on Engineering Excellence is just a mental model. A metaphor. A way of giving meaning to my quest of trying to improve my team by telling an interesting story. Compounding is about taking advantage of the returns your investments already generate by reinvesting them again. In other words, compounding is where you earn a return on returns that are already earned and reinvested.

With time, an Engineering team will improve their practices and systems if well though improvements are implemented. Every consecutive improvement will benefit from the last one. You must find your own story and give it the meaning your team needs. I work at a fintech so compounding seemed the right metaphor for us.

It's dangerous to go alone!

In the the very first cave of The Legend of Zelda, an old man says: It's dangerous to go alone! Take this. He gives Link a sword to help him on his quest to defeat Ganon and rescue Princess Zelda.

There is no way you can accurately find out what the team needs to improve by yourself. I picked up three of the people I trust most. They don't have to be the most Senior Engineers; they only have to be people others can look at and see as role models. They will help you find out what the team needs to improve. They will also help you create a plan, lead initiatives and inspire others to join in your quest.

But before starting the journey, I shared the initiative with the people I trust. I tried to enlist them, make space for them so they can grow and that way I tried to build trust. You do that last one by being honest and transparent about the problems you will encounter on your journey.

What to improve?

There are many ways you can lead the people you have chosen to help you find it out. But the main idea is drawn from the Design Sprint methodology: diverge and converge. You need to find spaces where you can together explore many possibilities, find out what others think, set clear objectives, ask for feedback, give everyone a role and make decisions. Other book that talks about how to approach a problem as a team, explore possible solutions and make a decision is Mastering Collaboration: Make Working Together Less Painful and More Productive.

You will lead one initiative yourself to give example. But each one of those people you've chosen will also lead one. This is important because it will allow them to shine, inspire and involve other members of the team. Leading does not mean doing. It means pursuing, involving others and making sure it happens.

What are we improving?

After a couple of weeks of brainstorming, debating, analysing and asking for feedback, we decided to focus on three aspects we must improve in the short term:

• Vertical Continuous Delivery. The team's ability to break big problems into small pieces so every step makes sense, adds value and reduces risk.
• Quality. The team's ability and processes to build simple yet testable, readable, maintainable and evolvable code.
• Observability & Monitoring. The team's mindset to think and learn about what happens to the code after it is in one of the dark corners of the internet.

The journey is broken down into three phases: Shu-Ha-Ri. Nobody explains this better than Martin Fowler so I'm not going to even try to do a better job.

Every team needs to improve different aspects of its Engineering Excellence throughout its life. Your team will have to follow its own path and battle its own demons.

Make sure you have checkpoints along the journey so you can adjust your plans for the needs your team has. Also, make sure you can escape from the chaos and day to day histeria so you can have some time to think and reflect on the changes happening because this initiative.

What could possibly go wrong?

Everything. One of the most famous quotes in business is:

If you can't measure it, you can't improve it.

What if you're starting to improve your team's Engineering Excellence but you are not measuring anything yet (quantitatively or qualitatively)? Keep going. You don't have time to measure first and improve later. You'll need to do both at the same time. Actually, make the team understand why measuring themsleves is so damn important as part of the journey.

If you know something about Engineering teams and people in general you know there is no guarantee this initiative will succeed. But I would love to have a chat if you try this or something similar.

What to do when you finish?

You never finish. When you do, if you do, you start over. But make sure you assess your team has actually improved their Engineering Excellence from time to time.