99 Group Work Culture

99 Group

Claimed

99 Group is a leading real estate technology company that operates real estate portals across South East Asia, specialising in digital property advertising.Headquartered in Singapore, it is currently operational in Singapore and Indonesia and employs over 350 employees.In Singapore, 99 Group operates 99.co, SRX.com.sg and iProperty.com.sg, while in Indonesia, it operates 99.co/id and Rumah123.com.Here at 99 Group, we know a property is the single largest financial decision - and affects how people accumulate wealth, raise their children, or even plan for retirement.More importantly, your property is a safe haven, and for most- where you return home to. That’s why it’s our goal to build the simplest and most trusted platform to help un-complicate the property journey and help 99% of homeseekers find their way home.We do this by working collectively to support the needs of property seekers every day. This commitment comes through in the development of powerful products and services for people to love and use.Whether it is on software and usability, on infrastructure and research or on powerful storytelling and delivery of meaningful insights — our work speaks volumes within the company, and throughout the community.If you’re curious, data-driven, and passionate about using tech to help people solve (arguably) the most important decision of their lives, we’d love to have you join the team! Visit 99.co/team for openings.

99.co has come a long way in creating a test, build and deployment process that is as easy as possible. For most of our services, tests and builds are done automatically through Travis or Google Cloud Build.

Every pull request has to be approved before changes can be deployed, and deployment of our web services takes as little as 3 minutes from pushing the code to seeing the changes live on site.

Failures can happen even after the most stringent checks and reviews have been conducted. At 99.co, we believe that when a failure occurs, there is an existing gap in our process, rather than the fault of an engineer. When things break, we conduct postmortems, investigate and document the lessons learnt, and make incremental changes to our development process to reduce the odds of the same failure happening again.

Keeping it real is one of the six core values, and we do so by building a culture that assumes positive intent and creating a safe environment for difficult conversations.

During town halls, all employees are encouraged to raise questions anonymously and are addressed head-on by the relevant stakeholders.

With Team First being one of our core values, we want our teammates to be unimpeded to do their best work. Engineers are strongly encouraged to ask questions in public forums so that others who have context or knowledge can and have jumped in, and information about problems need not be repeated.

This extends beyond technical discussions. We make it a point to check in on each other regularly to ensure that we are not overworking or getting burnt out, and if so, help start conversations with relevant stakeholders on managing the workload of the overworked individual.

Culture QnA

We have the automated build process that does automatic linting, code formatting, running test cases, and building artifacts.

Once the code is good for deployment (approved by the code reviewers), we merge the code to certain Git branches for the deployment.

Once the engineers have written the code and tested it thoroughly either by themselves or by test cases, they have to submit their code for the Code Review.

We have a written guideline on how we do the code review (for both the author and the reviewer).

During the process, we focus on the design issue and focus the tone around learning and improvement.

We don't really have a 24/7 standby on-call practice as our infra team is relatively small and we have not been experiencing frequent outages.

For day-to-day infrastructure-related issues or high-priority issues (P0, P1, etc), we have a member of the infrastructure team monitor our automated alarms every week. Then we rotate the duty throughout the team.

We practice the Agile/SCRUM process. Each product squad will focus on different parts of the whole product.

The overview process will look like this; gathering the requirements and doing a mock design, product planning, estimating the technical complexity, planning the (two weeks) spring, doing the actual implementation and QA, deploying the feature, and lastly, following up by a retrospective.

Every week, there is a product squad to monitor the product-related support issues and fix them as their regular product sprint.
That way, the squad members can work on the bugs together and not worry about both product sprint tasks and support issues.

Then we do the rotation to the next product squad next week.

We plan this whole which-squad-do-which-week in advance to ensure the squad knows when they will be on the support week.

We make sure everyone (PMs, Designers, Engineers, QA, etc) is aware of our trade-offs.

We try to strike a balance between delivering product features and maintaining technical quality.

The team keeps a backlog of tasks for the things we can improve in the future, such as refactoring, migration, upgrades, etc.

Once every quarter, we do a "tech debt sprint" (1 to 2 weeks). During that sprint, we go back to the backlog and only focus on the technical tasks.

Depends on the priority of the (support) ticket

We have an onboarding document for each newcomer.

In addition, we pair the newcomer with an existing team member.

During the first week, we ensure the newcomer can set up all the necessary toolings and applications and make the first commit to the codebase.

We also set up a 30/60/90 days expectations and follow up on these until the newcomer passes the probation.

We don’t pair-program as a day-to-day development practice.

We do pair-program when it comes to solving tricky bugs, brainstorming a particular design issue, or onboarding a newcomer.

The engineers are part of the product squads, and the squads do a daily standup meeting to discuss their status and blockers.

For purely technical discussion and issues, we do a weekly sync-up.

We practice blameless post-mortems for the P0 (critical) issues. We focus on what was the issue, not who caused it.

During the process, we gather input from everyone and find out the root cause.

Then we discuss the post-mortem and plan for the action items to prevent the issue from happening again.

We try to isolate all the possible meetings into a single day and make sure some days are free from meetings.

In addition, for each day, we suggest blocking off at least 4 hours of uninterrupted time to focus on the tasks.

Also, as a communication practice, we encourage everyone to discuss issues/questions in the public Slack channels instead of messaging individuals in practice.

We evaluate the engineers based on the input from the team members they have been working with for some time and their managers.

We evaluate whether the engineer has been demonstrating what level of the core values (soft skills) and the technical competency (hard skills) through the past months.

We have a 300$ personal development fund for the engineers to spend whatever learning resources they would like to purchase (online courses, books etc.)

We share the interesting things we learned recently during the weekly sync-ups.

We also read a book (as a book club) once every two weeks and discuss our learning too.

We do check-ins with all the engineers to gauge their energy levels, and how they feel about the previous features and sprints they have worked on.

Based on that feedback, we try to adjust our timelines and resources.

We encourage them to take a time off to disconnect from work and have a break.

Yes, based on their interest and the resources we have, we rotate people from one squad to another. That way, they have a chance to work together with different people and work on different parts of the product.

While product requirements are challenging, the technical solutions to build them usually aren't so. Engineers who leave generally find that they have built a strong foundation and are looking for places where they can be challenged even further.

We hold internal hackathons in December every year.

At the team or individual level, negative feedback or bad news is communicated to each individual.

At the company level, depending on the urgency and nature of these messages, they would either be communicated during town halls and weekly company standups, or a meeting called for the entire company to make such announcements.

Time is allocated to such sessions for Q&A. There may also be follow-up sessions with smaller groups of employees with the management team to address further questions and concerns.