Lessons from scaling a tech startup to multi-million ARR (Part I: communication and management)

The startup I’ve been working for is nearing its 2nd anniversary. I’ve been there from Day 1 and have seen a few-people team grow into a branched structure with over 150 employees.

I wouldn’t say the journey had no bumps across all levels (engineering, marketing, product). Still, I believe that what we achieved from the technical and customer satisfaction standpoints was quite impressive.

I think half of our success was in knowing how to design systems and implement practices, understanding when and who we should hire, and quickly adapting to the market (that, during the pandemic, changed by the day).

The other half of our success is in using technology where we could, automating tedious processes, and finding tools that would help us make the most out of human resources.

In this post, I want to reflect on the practices and platforms we used to drive growth as a small team and sustain it as we scale. I put this with engineers, project managers, and business owners in mind to help them tame chaos and turn ideas into organizations.

In part two, I will delve deeper into software engineering practices fellow developers can apply to their projects. Stay tuned!

Quick background on the project

To make sure we are on the same page for the rest of the post, I’ll give you a quick reference note about the project I have been working on:

Idea: oVice is a virtual office space company that brings hybrid and remote teams together in the same virtual room. It trumps Slack by bringing a visual component to remote teamwork - you see everyone in the organization at a glance.

It beats Teams and Zoom in spontaneity and engagement - you can walk up to teammates and casually chat with them. You can move around as you talk or have different meetings in different areas to spice up the routine of back-to-back calls.

We also focused on stability making sure our product leads the market by the stability of audio and video.

Launch process: we launched in August 2020, when the world was still processing the pandemic. oVice is based in Japan, where teams who mostly worked at the office, were now scrambling for tools that would help them get by remotely. Most of them missed the connectivity, even the look and feel of the virtual office space. That’s where oVice came in, offering businesses a way to move their offices to the web.

Later, we expanded in South Korea and started building up our global department. Now, oVice has three divisions: a Japanese, Korean, and global one. Managing such a distributed company has its own challenges - I’ll talk about them in more detail.

Milestones:
Since its launch, the project blew up in Japan and had moderate success in other markets. Two years later, we are looking at:

• Multi-million ARR that tripled since 2021
• Over 2,200 clients worldwide
• Over 60,000 DAUs worldwide
• Over 100 virtual spaces are created every day

Challenges teams faced when growing the project

In 2020, launching a startup felt like exploring the Wild West - on the one hand, digital projects were booming and breaking records in revenue. On the other hand, setting up infrastructures and operations during the pandemic was overwhelming.

At the time, leaders were getting used to digital-only interactions, wondering what they should do if key knowledge holders have to take a break due to COVID, and looking for ways to shield teams from stress.

For me and my team, the key challenges of growing a project were:

• Market expansion - when piloting an innovative idea, you have no way of knowing how the market is going to take it. Before we could focus on promoting our product, we had to first show team leaders they had communication challenges and convince them to try tools they had no idea about. That required a lot of work in awareness, especially in the Japanese market where Slack, Zoom, and other collaboration platforms had slower penetration.
• Communicating with distributed teams. From day one, the availability of project teams was all over the place - some worked in EST, others - in CET, and most of us were based in JST. Finding sweet spots where everyone is available was a pain in the neck.
• Connecting with target audiences. During the pandemic, we couldn’t rely on event-based networking or meeting with people face-to-face. Instead, our sales teams had to focus on social media prospecting and find tools that would facilitate data gathering and lead nurturing in a digital environment.
• Hiring new talent. We launched the project in a heavily candidate-driven market. Everyone was hiring - from Google and Netflix to startups and small businesses. Finding a package of benefits that would lure skilled candidates in took us time. Also, teams had to learn to make the most out of the resources at their disposal - people, tools, and time.

Organizational best practices

When a new project like ours enters the market, it doesn’t have the prestige, budget, or enough talent to successfully storm into its target market. What we lacked in these areas, we made up for with an intentional approach to engineering, product design, and marketing management.

Here are the practices I and other team leaders have discovered on the journey of scaling a multi-million startup in two years.

Know when you are ready to hire (because you might not be)

We launched oVice during the pandemic - back then, the collaboration market was booming. New products were sprouting out of every corner and the pressure to do better was in the air.

A surface-level solution was obvious: hiring. We could put our revenue into bringing in more engineers, push the product to the market faster than anyone else, and snatch that first-mover advantage.

The math is as simple as a standard pop quiz question: “If one person can dig a hole in two days, how long will it take for two people to dig a hole?

From a managerial point of view, the answer is not straightforward.

By doubling your resources you will not necessarily double the output if the people you hire to dig a hole keep arguing about the best way to hold a shovel and get no work done.

That’s why I believe that hiring is not always the best way to boost project speed. You should only hire when you have enough resources to invest in leadership, processes, collaboration tools, and other building blocks of an expanding organization.

If your goal is speed alone, there are other ways to reach the destination:

• Automating workflows
• Lowering the bar of requirements
• Reusing components
• Buying off-the-shelf solutions
• Bringing in a third-party contractor who has the team and the infrastructure set up

Expanding your in-house team might be the most obvious answer but, whether your organization needs it or not, is a very case-by-case discussion.

Don’t underestimate communication when working remotely

Numbers show that most companies interact more once they start working remotely. A lot of engineers are unhappy about it because when meetings take up most of the workday and drain us emotionally, when are we supposed to code?

I used to think so myself but, the more I work in management, the more I realize the value of collaboration. If two exceptional engineers don’t communicate, teams are running a risk of:

• Work duplication
• Having two pieces of code that don’t fit together
• Low codebase reusability: the dev who wrote it is the only person understanding the code
• No organization-wide best practices: two features of the same product will look drastically different making maintenance a nightmare
• And many more issues…

There’s the classical “this meeting could’ve been an email” rant which I agree with - for the most part. I’ve had a project that the team discussed mainly asynchronously (email, Slack, etc.) and, when the result came out, no one was happy about it, though everyone seemed to agree in writing.

The issue was in the fact that people had small comments or concerns which didn’t feel important enough to write down on Slack. Yet, as these details compounded, we ended up with an unusable output.

That’s how I learned I should take the time to put people in the same room and encourage them to nitpick the project and share the littlest concerns. Now I know that some emails should be meetings instead.

Let the data solve arguments

This may be a “duh” statement for many but, as teams grow bigger, so much time is lost over people arguing.

I’ve seen this on every level - engineers fighting each other over best practices, designers having heated debates on wireframes and prototypes, and marketers speculating which campaign will do better.

Unfortunately, teams can spend months bickering and have no tangible progress. That’s why, rather than trying to reach a consensus on calls, I encourage my reports to shortlist 2-3 digestible ideas and test them.

Once we do, there’s data on which teams can base conclusions. Since numbers don’t have personal preferences, egos to protect, and faces to save, they are way better at telling the truth.

Build cross-department connections

As a manager at an international company, keeping a keen eye on what other teams are doing is vital.

Whenever I got too caught up in a problem my team was trying to solve and forgot to see the big picture, I would inevitably discover that someone in the Japanese or Korean team had already found the answer.

In such situations, it’s always painful to think I would’ve spared my team months of effort if I knew what was happening outside of my division.

That’s why I encourage leaders to take aligning with other teams seriously. Helping each other out and sharing knowledge can propel growth and save you a lot of resources.

Here are the practices we set up:

• Document all meetings so that people from other teams can keep tabs.
• Add translation bots like Deep Thought (by DeepL) to Slack - it helps us translate the Slack channels of the Japanese team to English.
• Create designated “bridge” roles - hire people who would follow and align processes in both teams.
• Share knowledge in weekly town halls and team-building events.
• Meet in person whenever possible to build stronger relationships

Spend as much time on research as you do on execution

When you work for a startup, there are millions of ways to use your time and there’s always ground to cover. That’s why, at some point, teams find themselves (as mine did) endlessly juggling task lists and trying to maintain the processes we had set up.

Your reports might get so absorbed by agendas that they no longer have the time to explore market trends and best practices and reignite the passion for their field.

For a continuously evolving market like ours, working in a vacuum is a disaster. Trends come and go - so, if I missed an opening, there’s no way to get it back. Our team is not immune to this - in retrospect, I know there were market signals I should’ve taken more seriously and once-in-a-lifetime opportunities, that we could but failed to seize.

To make sure we keep track of market trends and technology advancements continuously, I adopted the following practices:

• Created Slack channels where people can share news
• Asked the marketing team to create weekly roundups of industry updates and share it on social media so that both our clients and our team can stay updated

• Subscribed to relevant tech and industry newsletters (Programming Digest, McKinsey On Point, Management Tip of the Day by HBR, and others)
• Curated a list of social media influencers I follow on LinkedIn and Twitter to stay in the loop

These discovery sessions add a sense of direction to our work, fuel creativity, and promote personal, as well as career development.

I believe that encouraging people to get involved in the industry of the project will give them a sense of purpose and a clear “why” behind every item on their to-do lists.

Tame the chaos when you can, embrace it when you cannot

Unfortunately, chaos has become the synonym for working at a startup. When you have competitors like Microsoft and Meta to go against, as well as ambitious market entrants, it’s easy to get overwhelmed by everything you as a startup founder or department leader have to do.

For a while, working in a chaotic environment might not bother you but, in the long run, its damage is lethal. Your reports will feel stressed by instability, their work hours will get insane due to the task and information overload - I’ve seen engineers on Reddit complain about panic attacks, weight gain, and severe mental health issues developed in disorganized workplaces.

From the productivity standpoint, a chaotic environment is just as damaging - no matter how fast your teams are moving, if that velocity is directed every which way, it will cancel itself out, leading to no net progress.

That’s why, in managing teams, I focus on structuring processes and putting things on track. Here are a few easy-to-set-up practices I adopted to spare teammates stress:

Learning how to create data-driven timeline and budget estimates

It takes no effort for a manager to pull a guesstimate out of thin air and pass it over to the team as an industry standard.

It will take a lot for the team to try and squeeze a mammoth’s work into a tight timeline. If you keep asking people for the impossible, your reports will feel like they are failing all the time until, one day, they will break under the pressure of continuously underperforming and start silently handing in resignation letters.

That’s why I took some time to research Youtube videos, blogs, forums, and the scientific evidence behind deadline planning to make sure my team doesn’t rely on guesstimates but on carefully constructed prognoses.

Focusing on processes, not tasks
Another realization that came to me was that, rather than assigning one-off tasks to my team that people would have to repeat from scratch without a consistent timeline, I would create structured workflows where every step logically leads to the next one and the result is clear before you start.

I find tools like Miro are extremely useful in visualizing a workflow and summarizing complex processes.

As part of the same initiative, I try to not assign one-off tasks to my team altogether.

When I think about future projects, I ask myself “Can I make this idea a consistent practice?” If the answer is “No”, I will explore a different idea.

Setting up flexible routines

There’s an interesting discrepancy between flexibility and stability. Lately, there’s a lot of buzz about employees valuing autonomy and yearning for full freedom. Some managers are happy to follow that train and set up no routines whatsoever - no meetings, no weekly reports, nothing.

Yet, there’s a different side to the coin. Studies show that, once given the flexible arrangement, employees still tend to build routines around it - they come to work at the same time, work for roughly the same number of hours, and clock out on a steady schedule. It is fascinating how predictable humans can be, and managers should leverage that tendency.

In my case, I started setting up regular weekly syncs and dedicated project meetings to give my reports a sense of structure and order - especially since I know that, for many, a prospect of a day full of unknowns is uncomfortable.

These are some of the practices I adopted to reduce stress levels and increase predictability in my team. While they help me somewhat structure operations, I can only ever know one thing - change is constant.

Things outside of my control will keep happening, the workplace will keep changing, and there will be new fires to put out.

A degree of flexibility and adaptability is essential - otherwise, organizations become too rigid and ultimately go down, outpaced by faster, more flexible, and daring competitors.

Last but not least: failure comes before success

The last and most important lesson I learned is that my team's successes grow in line with our failures. I used to be extremely worried about not always being on schedule or not hitting a milestone - in my mind, these were the red flags for a dying project.

Over time, I’ve seen how much failing contributed to resilience and encouraged us to keep searching.

During the last two years, we had to make major product tweaks and redesign our website because the solutions we had before weren’t right. I won’t even mention countless iterations of specific features, design elements, or social media ad campaigns we had to test and discard.

At the time, they seemed like failures but, in retrospect, we interpret them as experiments that led us to better answers.

As I look ahead, I know some calls we make will be wrong. However, I’m not concerned about them - at this point, I would be worried a lot more if my team stopped failing. That would mean we are playing it too safe.

If you want to follow my journey in management and are interested in my insights in working in engineering and leadership, come back for weekly updates. If you want to talk to me about my project, discuss partnership opportunities, or chat about running a remote/hybrid team - come by my virtual office.