Last week I listen to an amazing new podcast from Twentyminutevc with Mathilde Collin, the Co-Founder & CEO @ Front, and the main subject was “discipline”, the discipline in your day-to-day, week-to-week, month-to-month and year-to-year work, that discipline that helps you to achieve your goals, that discipline that is so simple to understand but hard to follow. After I listen to the podcast I was curious to see how it is the discipline in software development, after simple search on Google, nothing, what? Did nobody share his discipline in their software development process? It seems that not, and I decided to write an article about discipline, discipline in our company.
When I think of discipline I have two people in my mind, one it is the Jiro Ono, a guy who is 93 years old, who has spent the last seven decades of his life into his craft. Here’s a guy who after decades of practice and three Michelin Stars, could just retire and walk away from his craft. But he goes back every day because he can and should strive to improve.
Here are some lessons from Jiro Ono:
“It’s just about making an effort and repeating the same thing every day.”
“He sets the standard for self-discipline. It has to be better than last time.”
“He is always looking ahead. He is never satisfied with his work.”
“He is always trying to find ways to make the sushi better or to improve his skills.”
And the other one is Jeff Bezos, and how in the last 22 years executed his vision from the first annual letter in 1997. Bezos is guided by a focus on decision velocity to drive innovation, at the expense of consensus and even if it increases the risk of mistakes.
Here are some lessons from Jeff Bezos:
“I believe we are the best place in the world to fail (we have plenty of practice!), and failure and invention are inseparable twins.”
“To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment.”
“You have to somehow make high-quality, high-velocity decisions, It’s easy for startups and very challenging for large organizations. The senior team at Amazon is determined to keep our decision-making velocity high. Speed matters in business — plus a high-velocity decision-making environment is more fun too”
“Make Decisions With 70% Of The Info You Wish You Had, If you wait for 90%, in most cases, you’re probably being slow”
What I would like to point out it is that you need discipline in order to achieve your goals, and if you’re working with engineers is hard, because you work with artists, how to convince an artist to have discipline? It is hard but not impossible, and our company helps engineering leaders to have better discipline.
What is our discipline?
One strategy meeting per week: Monday morning it is for brainstorming, we’re thinking what we’ve done well last week, and what we will do this week. It is that moment in the week when we make decisions, as an engineering manager, it is the only moment when I can add new things. After this meeting, the engineers need freedom from management in order to achieve our weekly plan.
Follow a data-driven approach: As a manager, your gut tells you to have daily meetings, to see if you’re engineers are on the right path, but I don’t think this is the right decision, because engineers are artists and they need time in order to deliver, and what they hate most it is an early meeting each day, a meeting to see how “I didn’t deliver yesterday”. Waydev, our solution came with two amazing features in order to solve your gut issue, we have the Work Log where you can see in real time all the commits and the output for each commit, and Daily Update where you can compare your last week impact with the current week impact. With these features, you will be able to see how your team is performing and if they are on the right path. If you see any anomalies in your team, we have the Developer Summary feature where you can see the specific stats for each engineer.
With a data-driven approach, you can have a very good discipline without the input of the engineers, because everything is automatically pulled and processed by Waydev from your Git repos.
You see I didn’t say anything about Agile or Waterfall method because I don’t think it is still relevant to relate only on the methods we created 20 years ago, it is not relevant because we don’t build as we’ve done 20 years ago, now we have relevant data we can follow and we can understand what’s happening with the project in real-time, this is why I think that a data-driven approach will help you to have more discipline and build better and faster.
The data-driven manager of tomorrows don’t need to spend hours in understanding the code, his job is understanding the team, solve their problems and have a discipline of following the same metrics week-over-week, in order to improve them.