Ralali Tech Journey

Hi, I’m Eko ​​Suharyo Djomi also known as Echo. My role in Ralali.com is as an Engineering manager. I want to share my 4-year experience with this company. I started my professional career since 2008 in other tech companies and finally made a match with Ralali.com around the 4th quarter in 2015. I was assigned as Senior Software Engineer and continued as an Engineering Manager in early 2018. Here I share with you my journey here along with the seed of Tech team in Ralali.com

Working system

Ready to serve!

We have several departments, in 2015 when I joined Ralali.com, the management between technology and business team seems haven’t performed well. The business problems haven’t been recognized appropriately by the tech team directly. Not so long after that, Ralali.com started to apply Cross-Function teams to overcome these problems, they are: Technology, Business, and Marketing.

Why do we have to apply Cross-Function teams to our organizational structure? As part of Tech department, we have different job complexities, so that the work is not more abstract. It ended up with each team focuses on bounded contexts. What’s the point of it? First and foremost, continuous learning and continuous increments are needed.

Take the Billing Team (Pulsa, PLN, PDAM, BPJS) as an example. They will create a billing system for customers to be able to click buy billing products easily. Is the work done? Nope.

They also made data monitoring applications for internal teams (Product Team, Operational Team, and Data Team). Also to monitor usage, to collect the data growth that will become the next sprint planning material (every sprint provides an opportunity to learn about the product).

Before conducting the next sprint, we usually arrange Retrospective first. A Retrospective event helps us re-evaluate the prior sprint toward the next development. The evaluations are including: the things that have been an obstacle, maintaining a well-down job, and propose to the next improvement. These all require a shared commitment within the team.

Talking about decision-making teams, previously in 2015, all of our team was managed directly by our CTO, Irwan Suryadi (since the tech team was still small, approximately around 20 people). He, who also acted as the Product Owner had to decide on the number of members and placement of each individual in the team. This thing has been done in order to fulfill the task that the Product Owner wants to implement. The aim was to enhance the team’s capability to explore their task technically and also be able to see it from a business perspective.

Working culture

Journey to the agile development

Ralali.com applied the agile methodology in 2015. When I just implemented agile guided by Joshua Partogi. After that, Ralali.com continues to use the agile methodology until now because the products require a never-ending development and will always crave for new innovations. In addition, this methodology makes engineers have full responsibility and ownership of a product that they make.

Why would we need an engineer to have ownership and responsibility? As Ralali.com engineers we always have targets and plans on a daily basis, how do we as the engineers know? With sprint planning being held every two weeks, each developer team will have a committed sprint goal to achieve, to see the progress towards the sprint goals every day we sync and adapt through daily scrum events. What is Daily Scrum? Daily Scrum is an activity with a maximum time limit of 15 minutes (exclude gossip, etc Lol ​:’D) which aims to synchronize work between the development team. Each team member must report what has been done the previous day and plan for the day after that.

In addition, we have specific reasoning to divide the team into some of Ralali’s branches. FYI, our team is growing up from 20 people, double raised to 40 in 2016, and ended up with 130 this year (but we’re still hiring, guys!)

Raise the number, raise the benefit

We divide teams in some cities to gain local talent in each city. After Jakarta (BluGreen Building, our headquarter), we built our branch office in Yogyakarta, in the middle of 2016 and continued in Bandung in mid-2018. However, Ralali.com still open job opportunitie s in other major cities.

We make it a habit to meet via video conference at each sprint. One of them is a review event. What’s the point of a sprint review? After two weeks of running, the team will carry out a sprint review to review the work results of the team (due to the timeline we arrange together prior the project). It’s not a good idea to execute a theory alone because it would take too much of a hassle without seeing the real evidence, so a benchmark would help us a lot.

Benchmark

At the beginning of 2016, we learned a benchmark to Booster.com, a startup in Malaysia. They visited the country to learn how the team establishes self organize. We were guided by their CTO directly, Welly, to see how their development process. We were surprised that it turned out to be an extraordinary development process. At first, after they finish developing, they also make automated tests, and they also do mutual code correction via Pull Request, and what’s great is that they also deploy to production with the CI/CD process. To test their features, they also use Feature Toggles.

Feature Toggles is used to hide, enable or disable the feature during run time. For example, during the development process, a developer can enable the feature for testing and disable it for other users. Please note that in Booster.com, there are only 3 teams and each team has 5–6 people, 2 teams in Malaysia and 1 team in America.

In the middle of 2016, we took another benchmark from Tokopedia. We met with Leontinus as the CTO and also met with the product owner, Tri Nugroho, up to the SysOps team. Long story short, we gained some new knowledge, such as:

• Each team has to be divided into smaller task forces/teams
• Onboarding employees: a proper induction program through two weeks of training to sign new employees. The point is to synchronize new employees, introduce cultural styles and the development of Tokopedia

Where we need a high level of innovation, treat our employees as knowledgeable workers not just as actors. Innovation requires collective intelligence, not just a one man show. You may also visit our Linkedin Page for the rest story about the kinds of stuff we create here. Thanks for reading!