The story of the Mobile Guild @ Luko
Before joining Luko, I worked as a Freelance Mobile Engineer for 5 years within many companies where organizations were different. I was really curious to find strengths and weaknesses in companies’ structure that have 10 to 500 employees. The most adopted system that I have seen is the “Spotify model”. I think the main benefit of it is to use the same terminology at every scale of the company (Chapters, Tribes, Squads, and Guilds).
Initially, Luko Mobile app was built by a squad of 3 mobile engineers, 1 designer, and a product manager. Today, we are 10 mobile engineers working in different tribes on the same app. We will share in this post why we switched to a Guild, how we are organized to keep cohesion, share knowledge, collaborate, and also have fun! 🏄
Why having a guild?
When working in the same squad, it is easy to communicate because everyone is aware of the work other engineers do. This is all fine until the application starts covering many different user needs. At that point, we had to ask ourselves. What is the best way to organise in a way that we can scale the team and allow people focusing on concrete user and business needs? At that time, we had the following questions to answer.
- How can we keep cohesion in the team?
- How can we keep product alignment with stakeholders?
- How can we continue improving quality and maintain sharing best practices?
Luko mission is to reinvent HomeCare and it was clear that our mobile application will become a “super-app” supporting a lot of different user needs. A user in the app can find, insure, monitor, and repair their home!
We decided to grow by forming mobile teams in the tribes that worked on different mobile app modules. Today, the mobile app has ~140.000 lines of codes where we definitely need collaboration!
To ensure collaboration and address the aforementioned questions, we decided that each engineer in a tribe should have one day per week dedicated to Guild topics (Navigation, Design System, Infrastructure, etc.). In addition, while scaling the team we decided to have a small core team to focus on cross tribes improvements of the underlying technology.
This approach allowed us to align everyone on HOW we build mobile features by focusing on quality and productivity while leaving the WHAT to be built with the tribes. For example, engineers in the Home Monitoring squad will focus on features enabling our users to monitor their electricity, gas and water consumption. Engineers in the Moment Of Truth tribe will focus on improving the claim management process in the app. They both have their own objectives aligned with their tribes while following the best practices and contributing to the shared Guild initiatives.
How do we organize our week?
Asynchronous daily
Every day we use Slack to say hello and update others on what’s our priority today and if we need help. This practice was already in place in the squad, doing it asynchronously help us avoid too many meetings and sync at our own pace independently of our core Tribe activities.
Happy Monday! Coffee time ☕️
As we mainly work remotely, we take 30 minutes every Monday for chatting about our weekend, what our focus is at the moment, and if we need help. People can join as they see fit and most of us are always happy to start our week together.
Backlog refinement on Tuesday
During the week every engineer can create stories to suggest improvements that we will discuss and decide if and how to do. To refine those ideas we take 30 minutes every Tuesday to discuss them within the Guild. At the beginning engineers were mostly focused on user added-value features and not enough to enhancing the technology. Nowadays, everyone contributes 20% of their time to the core technology and Guild initiatives that drive the improvement of our codebase and help us increase our productivity and ship faster. The latter certainly has allowed us to respond faster to user and business needs.
Wednesday is a focus day
No meetings are scheduled on that day across Luko. Sometimes there are exceptions but, in general, we follow this best practice.
Mobile tech talk on every second Thursday
We have a dedicated bi-weekly session to discuss new tools, new ways of doing our work, and share what we have been learning. We choose topics and everyone has the opportunity to suggest a topic and deep dive into it during the session.
Some time ago, Bastien presented a VSCode extension he worked on. Recently, Anthony shared how to create custom ESLint rules. Shortly, Adrien will be sharing how to use visual regression tests on iOS and Android with our CI. We are also open to learning from non-Luko engineers experience. Some time ago Ludwig has invited Jerome to share his experience with AppScan, a tool to inspect iOS packages.
Merge Request Reviews on Friday
We have an available time slot on Friday morning to do code reviews synchronously. Most people will join if they do not have anything urgently. This is a great moment for us that we have been using to discuss and share good coding and software design practices. Asynchronous work is powerful and our main “modus operandi” as a remote friendly company and it’s also nice to be able to connect synchronously to other Guild members.
That’s a practice we keep for a quick problem resolution. We also connect ad-hoc for quick chats. If something can be fixed in 10 minutes with the help of someone else, let’s connect and talk about it. Next to those synchronous moments we meet face to face regularly in the office. We also participate in an offsite twice a year which has proven to be a great time together.
Best Practices
Code Reviews
We consider code collaboration an important part of engineers’ life. Hence, we have defined some rules for doing it effectively.
We focus on product quality and sharing knowledge about the code base. Each review will be done and approved by two other engineers from the Guild before merging the changes. ✅ ✅
Guidelines
We follow the practice to write all important decisions made during Code Reviews in a shared guideline documentation.
Request For Comments
We use RFC documents to align the team before jumping on implementation. RFCs are mostly used for outlining a solution to a problem that will affect multiple teams, it is complex and the writer would like to collect the feedback of others, or in situations where we would like to share some key decisions. An RFC starts with a problem description outlining the problem and providing relevant background information. A proposal will follow that explains the motivation, any requirements, metrics, and all the considered solutions with pros and cons. The RFC is wrapped up with a conclusion.
Release Routine
Every engineer is involved in the app release. We have a release routine in place for everyone to follow.
Flying Goalkeeper
Luko’s super app is used by tens of thousands monthly active users. That means that we have the responsibility to make sure that those users have consistent experience with a mobile application that doesn’t fail and when it fails, there is a resolution provided shortly.
The flying goalkeeper (aka “goal volant 🇫🇷“) is a role to improve the team’s focus during a sprint and dedicate someone each week to answer requests from Customer Success team or act on issues. Their role is to resolve issues and help others fix them when they are blocked. The goalkeeper also supervises the e2e tests.
Guild documentation
To keep track of our decisions, we initiated documentation about our technical stacks:
- React Native, Typescript, react-query, restyle, react-hooks-form, zod, Detox, testing-library, Firebase, CodePush, Bitrise
Tech watch & events
We created a Slack channel to communicate news from outside related to our technologies. This allows our Guild team to share their findings and thoughts anytime they see fit.
Open source conferences
We love these open source conferences and are happy to recommend them to you.
Autonomy and scale
This organization works well for us. As we are scaling very fast it is certain that some changes will happen in the future. Our main goal is to scale the team while continuing to improve collaboration and quality in mobile engineering.
The Guild allows us to have deeper discussions between technology owners. Before, I have seen products managers aligning four roadmaps; one for each — iOS, Android, Web, and Backend. At Luko all engineers are able to contribute to Guild initiatives while focused on our customers’ needs with the work they do in their Tribes.
Separating the HOW from the WHAT allows us to keep each team’s autonomy. In addition, React Native gives the power to one engineer to deploy a feature on iOS and Android at the same time.
We are happy to hear what your thoughts are on this organization.
