Always be leaving
“Always be leaving”, a quote from Bharat Mediratta (former Google engineering director), is one of the topics in the chapter “Leading at scale” in the book Software Engineering at Google.
The idea behind this topic is to avoid the anti-pattern that “things doesn’t work without you”. The goal here is to create a team/organization that could solve its own problems by itself instead of being you the one who solves the problems.
Here I want to share keys to follow this idea in different contexts.
For Individual contributors
As an “individual contributor” you are supposed to work on task without people management responsibilities but that doesn’t mean we should not think about the future consequences for other colleagues or even for ourselves. Things we can do for this could be:
- Create or update documentation: every time you create, modify or fix something try to add information at some place where you or any other person in the future could go to find answers. Create a new service?, add its related doc; update some process?, find the documentation and update with the changes; follow some outdated guide? fix that and let it be better than you found it.
- Always share knowledge: doing a code review and saw something about you have more information?, share the link to know more; have you learned something new that could be useful for your coworkers? share the links or give them a talk.
- Write code for others: when writing code think about if other people in the team could be able to understand easily and try to make it for them (and for your future you)
- Work to solve the problem not the concrete case: someone asks you about something you know? instead of just tell that person, create a documentation, share with that person, get feedback en improve to ensure anyone at anytime could get the same information with the same quality (no matter you are available or not)
For Engineering managers / Tech leads
It’s quite clear that Engineering managers are dedicated to work for their team, help them solve problems, be an “umbrella” for them and help to move things forward with external dependencies. Tech leads are in a complicated position between individual contributors and people management (a recommended lecture about them could be “Talking with Tech Leads” book). Here are going to focus on how to create “self-leading teams” and how the “leaving mentality” could help them:
- Dividing problems and adjustment: to solve a complex problem it’s always easier to break it into smaller ones and let people handle each one of them. The issue here is to be able to create a culture that knows when a problem changes and how to adapt to it. It should be a mix between creating a team which follows its procedures but at the same time it’s flexible enough to adapt to situations.
- Delegation: creating a strong team and future leaders is key for any team. Let people handle problems, take decisions and assume responsibilities is the key. As leaders most of the time we may think that if something is “important” it should be done by us, but instead of that what we should do is always question us: “am I the only person who can handle this?”. If it’s always us who handle those kinds of stuff, we are never going to create a “self-leading team”. Not be the SinglePointOfFailure of your team!.
- Adjusting and iterating: give advice, let people take decisions and evaluate results. Maybe the % of freedom starts at 50%, at each iteration drops the number and gives even more autonomy.
- Give the team problems not tasks: for a full autonomy, ownership and context are required if we only assign tasks or features we are not letting the team see the big picture. To create a self-leading team, they need to have all the context and be owners of problems so they can find their own solutions.
“Always be leaving” is a philosophy for personal and team growth. It has benefits for a single person or a whole team and organization. It helps to always keep looking for better and more efficient teams.
What do you think? Do you have other actions/ideas to follow this principle?. Share with us in the comments.
Thanks for reading.
