Back to resources

Company Growth: The Good, the Bad and the Ugly

Dev Processes
Feedback
Strategy
Team Processes

18 March, 2022

Renaldi Renaldi
Renaldi Renaldi

Director of Engineering at Boku Inc

Renaldi, Director of Engineering at Boku Inc., shares his guide for improving problem-plague processes into strategic initiatives.

The Good

The company continues to grow year over year. We continue to hire and also acquire a few other companies. Starting from just a few engineers in San Francisco, by 2020, we had diverse engineering teams working from different continents (Asia, Europe, and America).  

The Bad and Ugly

Some of the challenges that came with the growing organization were:

  • Teams sometimes made decisions that prioritized their own success over the overall success of the organization.
  • Engineers spent a lot of time discussing trade-offs during the technical discussions because there were no clear guidelines on what was important for the organization. Is it speed? Is it reliability?
  • Sometimes different teams solved the same problem differently resulting in unnecessary duplication and maintenance costs.
  • There were issues regarding cross-team collaboration and communication in general. The cultural difference and time zone difference made it even more challenging.

How to Break Down Processes Into Smaller Chunks

To begin with, we started by emphasizing the company values and how that translated into the way the Engineering teams should work together. Why? Instead of each team having their own values, we wanted everyone to follow company values, ensuring that everyone was on the same page and eliminating misunderstandings. We updated our hiring process to include questions related to our values and evaluate candidates based on those values. We updated our performance review process to make sure that the people we promote are those who exemplify our company values.

From there, we worked on our Technology Pillars and Principles. Pillars are the overarching umbrella on what we should prioritize when making technical decisions. E.g. reliability over speed, security over efficiency, etc. These pillars are not invented in a vacuum but based on the feedback from our customers and internal stakeholders. From the pillars, comes the technical principles, which express our preferences when evaluating problems or making decisions. E.g. We should prefer battle-tested technology over cutting-edge technology to reduce the unknown unknown and keep the platform reliability high. If functionality is a key business differentiator then we should prefer to build, rather than buy and/or customize.

Next are the Technology Map and Architecture Northstar. Technology Map is a collection of technology used within the company and their stages (Default Choice, Allowed, Trial, Deprecated), which is inspired by ThoughtWork’s Tech Radar. The goal is to provide visibility around what technology we currently support and should be used vs what should not be used anymore (deprecated) vs future technology we are trialing. We also write down the process for introducing and evaluating new technology that the team wants to bring in. The Architecture Northstar is a forward-looking architecture design to ensure that teams are moving in the same direction. E.g. Given the importance of security for the company, we will have security tools embedded as part of the developer life cycle so that we can find security vulnerabilities as early as possible.

We also introduced programs like recorded lunch and learn sessions. It encouraged teams from different regions to eat together in a group while simultaneously utilizing the time to complete training or other activities. We had an ongoing bi-weekly update through Slack about the work being done and delivered, updates on new technologies adopted, updates on the overall health of the platform, and other engineering updates. The goal is to keep everyone aligned in terms of where we are and where we are going.

In summary, we started from crafting the overarching direction and then broke it down into smaller, more manageable processes. We also invited the managers and the senior ICs to provide feedback and suggestions so that we can get buy-in from them.

Lessons Learned

  • We are often hesitant to introduce new processes into the organization because of the bureaucracy sentiment that comes with it. But, not having one can also create confusion, friction, and misunderstanding. Relying on word of mouth does not work as you scale and have people in different locations and time zones. Having it written down also ensures that everyone has access to the same information.
  • As you define your process and guidelines, make sure to invite the manager and the engineer to provide feedback and get buy-in. Often they can also provide you with different viewpoints or help you clarify your message.
  • Discussing values and direction can be challenging because different people have different opinions. However, if you can successfully manage it, you can create a strong alignment across your engineering teams.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Delegate
Team Processes
Prioritization
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO

Leading Your Team in Stressful Situations

27 April

David Kormushoff, Director at Koho, recalls how he galvanized his team to tackle a time-sensitive problem, sharing his tips on how to shift chaos into calm.

Goal Setting
Leadership
Conflict Solving
Deadlines
Collaboration
Motivation
Strategy
Health / Stress / Burn-Out
David Kormushoff

David Kormushoff

Director at Koho

Why You Should Take Technology Risks in Product Development

25 April

Matias Pizarro, CTO and VP of Residents at ComunidadFeliz, recalls a time in his early career when he took a technology risk that had wide-ranging benefits to his product's user experience.

Innovation / Experiment
Product
Scaling Team
Dev Processes
Matias Pizarro

Matias Pizarro

CTO and VP of Residents at ComunidadFeliz

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.