Mobile Lead 101 — Lesson 3: Let your developers lead
What I learned working as a Mobile Lead for seven years
At work, many people speak about “dream teams” or the “A-Team”, how should my A-team look like?
Be able to build your team from scratch: it is a great advantage. But in both case, if you inherit a team or if you build, it is critical to take essential decision when a team member doesn’t fit.
To become effective during your hiring process, and while coaching your team, you should ask yourself the question: how should my development team be? My team should be empowered, focus and motivated!
Empowered
A team requires people that think. Developers must receive clear guidelines and processes, but, at the same time, be put in a position to be able to fail, learn/adapt and try again.
Empowering is not like mentoring. It is a complex topic that can’t be summarized with an algorithm or procedure as you might understand reading those Quora answers.
It is a pull approach and not push, and listening is a critical skill. Each developer has a different relationship with me. I know that some people are shy, and others are more talkative. It is important to remember everyone to avoid to fail to recognize silent talents. A monthly feedback session might be crucial. Be equal with your team is an essential value that pay-back in a long time frame. Also, I tried to focus on the future rather than the past with my team. If there somebody went wrong, it is crucial to perform the proper root cause analysis to understand what went wrong to understand what can be done better in the future. For example, should we change the procedure or stick to it more carefully? It is important to avoid blaming anybody and avoid creating this kind of culture.
The objective of empowering the team is to make sure that each developer will show ownership for the project and not just for the small component they developed. Leading with example is essential to achieve it.
Some developers might enjoy adding some gamification or healthy competition between squads on the number of story points delivered of bugs fixed. But it might not be appreciated by everybody. In the past, I worked with a team that appreciated the irony, and we were awarded significant failure trophies.
We were doing since we were 100% sure that failure was not impacting our performance, but in Asia, I strongly recommend not to try a similar approach.
Please try your best to have a diverse team. In some countries, it might be a complex challenge, but it will pay-back.
Empowering is not a perfect science, I recommend it, but it is better to know when it might fail.
Motivated
You can make some assumptions on what motivates your team. But if you never ask, you will never know. Usually, after a few months, I organize a poll, and anonymously I ask an open question such as“What are your motivations to come to work?”.
The answers are always different. I would like to share some example from one of my projects after I will also share some of the actions I did to improve the overall team satisfaction.
In this project, the developers had different needs from improving the code to have a better understanding of the whole project (see above figure). Some were more beneficial for an individual and other more for the project. I could not improve all of them at the same time.
Also, at that moment, there were two significant problems that I would have like to solve:
- the recurrent slack fights between new joiners and seasoned developers on the introduction of new patterns;
- the project complains about the lack of communications between teams causing bugs and delays.
After several brainstorming with my team, we decided to introduce a weekly forum to discuss the code and give the ability to anybody junior or senior to bring any topic to discuss, called Tech Debts meetings, and the rotation program (called internally “the internship project”).
Tech Debts Meetings
Before starting the meetings, I decided to create a structured process to open and review technical debts. I gave the ability to any developer to add Jira tickets in this tech debts board. Those tickets could include code refactoring, the introduction of new design patterns, upgrade of libraries and even introduction of new coding guidelines.
Every Wednesday, the team was reviewing the proposed design. If they were able to finalize their solution, the item would be assigned to me for the final review and the backlog prioritization.
These meetings were constructive to empower them better and make them feel ownership for their project.
The rotation program
Since months I was spending a lot of time explaining the different teams’ challenges in the project, but most of my developers didn’t want to put themself in other shoes. So for the developers that wished to “see the full picture” or “learn new technologies”, they might benefit in joining a different team for a short period.
We started an internship program of 2 weeks for the developers to experience the work in application design, back-end development, testing. The objective was to let people explore other areas of interests and perform knowledge sharing. It helped remove barriers between teams. We didn’t lose any developer, and we benefit a lot by creating more reliable connections with other groups.
In addition to this process, I strongly recommend organizing retrospective sessions at the end of each sprint or release to understand better and take action on the day to day issues faced by your team.
Focused
How can a team be on time, with high-quality standard and collaborative at the same time? The activities that I found useful are:
- Design together:
Design is the most formative moment to share guidelines, directions and challenge the solution. It is vital to remind how important is this meeting and to share it with all the senior developers (front-end and back-end). The entire team should join as an essential moment to align the whole team on a single objective. It is critical to keep all the people in the loop, and for this reason, we were always creating a feature’s channel in slack to enable a fast communication channel in case any change was needed. - A common goal: the development exit-criteria
After many years, I created and updated a list of questions and validations that are my definition of done for the mobile team. The checklists include questions about: unit-testing, e2e test, SonarQube, PO and design reviews. This maker and checker approach helped me to decrease bugs up to 20% in each release. - Peer reviews:
How do you measure the collaboration within a team? Especially when you are managing several groups, the visibility on the internal dynamics might be limited. To overcome this issue, every three months, we organize a peer review session. Each developer should provide an evaluation for his/her team member and himself/herself on several topics ranging from attitude to technical skills.
Thanks to this process, I was able to acknowledge issues such as low performant team members, bad attitudes with other teammates and in the codebase and to award team players.
My first 100 days
This article didn’t cover so far a critical activity that a leader should do: build her/his credibility. My formula is usually the following:
- I start a project as mobile lead with an in-depth hands-on experience
- I spend some time to develop my opinion about the code and processes in place.
- I start to write down all the improvements I would like to do
- I engage in informal chats with the developers to understand their pain points and their recommendations about the code/projects.
- I define the new processes, architectures and guidelines, but before presenting it to the big audience, I validated it with the senior developers trying to understand what can be achieved and what should be changed.
- When I finally present the change, I try to provide a 360 degrees view on the benefits and the motivations behind my decisions.
- I start to execute the plan. Be coherent, and a hard worker will explain who you are to your team.
Focusing on the ground job in the first weeks or months of a project instead of trying to take substantial architectural decision will help you bond with the team and have a more in-depth technical understanding. I learn to work with developers and engineers that you don’t build trust overnight or with an inspirational speech, but working with them fixing code until late nights.
Conclusions
Managing a mobile team requires some technical skills at the beginning to gain trust, but in the long term, it requires more to develop your emotional intelligence. The critical activity to let your developers lead, it is to listen to them. You should adapt your process and your problem solving to find the most efficient way for your team to be productive.
Don’t work on assumptions and don’t think that all the teams should work in the same ways. The developers’ cultures change a lot between different companies and countries; please ask them what motivates them and try to adapt the working style to make the moving experience better.
The technical debts meetings and rotation programs can be an exciting exercise that you can replicate in your project. The exit criteria checklist was a way to improve quality, but there might be others, please contact me for any feedback about this article. I would love to discuss this topic and collect a different point of view about it.
About the author
Since 2012, Francesco managed six mobile projects as a Mobile Lead or CTO. He covered several industries, from banking to lifestyle. Francesco led teams from one to sixty developers in four continents. In his project, he used technologies such as PhoneGap, Objective-C, Java, Kotlin, Swift, ReactNative and Flutter. His most successful project has almost 8 million active users a month.
Disclaimer
This article reflects my personal opinions, and it should not be attributed to the view of any my past or present employers.
