It’s been a wild journey the past year at Ritual and I’m really proud of what I’ve accomplished and things I’ve learnt. In the first half of the year, Ritual responded to competition by deciding to expand internationally. Under tight deadlines, I built a translation platform that helped launch our first non-english city in Montreal by April. Since then, we have launched in Germany, Netherlands and Hong Kong.
In the second half of the year, I lead a team of 7 engineers to build a massive data platform to gather, clean and link restaurant data from a variety of worldwide sources. Compared to our legacy system, we obtained 20% richer data, identified 6k+ major brands, clustered restuarants, built hitlists and lead to an array of key improvements in our expansion strategy and planning. These efforts lead to my promotion to tech lead manager.
Reflecting back, it was a stressful year but the learnings for me were invaluable. I realized that solving people problems and fixing processes were often more important than solving technical problems.
With stakeholders, these were usually related to miscommuncation or misalignment. Documentation, meeting minutes and weekly syncs with leadership proved useful. Flagging issues proactively was especially important. Moreover, when organizations move at a breakneck speed, it isn’t merely enough to flag issues, but to flag them to the correct set of people, and in a tailored manner (I learnt this lesson the hard way). By delivering small wins consistently, being transparent and listening, trust can be built with stakeholders.
With teammates, it is important to recognize and reward good work. I found that having 1:1s was a good way to build trust with teammates and understand their goals and help them overcome their weaknesses to reach these goals. Demos and knowledge sharing sessions were great ways to let teammates shine and spread knowledge and avoid silos. Team lunches and outings were fun ways to build trust.
When business problems are large and complicated and not enough time is allocated to explore and understand these problems, planning suffers. Creating templates for product review docs and tech review docs can really help in this stage (apart from the meetings of course). Filling these docs standardizes the process of gathering requirements and also gives all parties time to reflect, to step-back and look at the bigger picture and question assumptions. There is ususally a disconnect between the business side and the tech side in terms of what needs to be done and rushing this phase creates a ton of assumptions, leading to poor requirements, weird metrics, inaccurate timelines, suboptimal solutions, undefined scope, etc. I learnt to pushback on pressure to shortcut the planning phase of any large or important project.
It is far better to focus on fewer things and do them well rather than do everything and let things slip. I’m someone who’s interested in everything and eager to learn and get better but it’s not worth spreading yourself too thin. A lot of product managers I’ve worked with also have this problem and it spills down to the tech lead and the team. Saying “no” is often a necessary evil.
In 2020, I hope to continue improving my communication skills, help teammates level up, take more time to plan and focus on the largest, most important problems. One of my goals is to network and build connections with managers in other teams and also in other organizations so we can share experiences and learn from each other.