Scaling a startup is hard. Transitioning from the garage, where there are no processes, just a shared goal the founders are working towards, to an organization with over 20 people in two years is one of the biggest challenges you face. How to keep everyone aligned, productive, and, most importantly, hit your business goal. Drawing from our experience with daily.dev, I aim to share insights that aren't commonly discussed outside closed circles. These strategies have been pivotal for us, although they require continuous reflection and optimization. Consider this as a guide to adapt to your startup's needs.
It's important to note that daily.dev is a remote company, comprising 24 team members across 14 countries, which adds complexity regarding time zones and communication.
Routines
I did my best to cover all our existing routines. We introduced these routines to solve a problem we experienced as we scaled the company. Here's an overview of each:
Weekly founders' meeting
Our oldest routine, the three of us meet weekly to discuss almost everything. Personal life, management, product, marketing, strategy, anything goes. It's there to ensure we have time just for us; otherwise, it won't happen. It's a one-hour meeting, and we always have something valuable to discuss. The founders' relationship is significant to nurture, and as the company grows, you get less quality time together. This routine evolved. When we started, it was very technical and hands-on; as we grew and got to do less hands-on work, we had more time to talk strategy.
Daily standups
Every member shares a written update on Slack about what they did yesterday, what they plan to do today, and if there are any blockers. We introduced it to help managers ensure everyone is aligned on the priorities and no one is stuck on the same task for a long time. We're a remote company, so we had to make sure we had this touch base on one hand, and on the other hand, we wanted to go with something other than the classic standup meeting, which is a waste of time. It's also much more complicated since we operate in different time zones.
All Hands
Once we hired the first team members, we introduced a weekly meeting with everyone to align on the critical matters as a company. This also evolved with time. These days, we start with reviewing the progress of the week and upcoming events. Followed by demos presented by individuals, and other sessions if needed. For example, if a launch is coming, the head of marketing will share what's planned and how other members can contribute. Sometimes, we want to go over new routines or procedures so the head of HR can update them, and so on. The CEO leads this meeting.
Once a month, we cover our progress in more depth. The CEO presents the performance of the business, how well we performed, what we learned this month, and what we can do better next time, and shares insights. This helps everyone know exactly the company's state; it's also a great chance to pat ourselves on the back or ask hard questions if needed.
Coffee breaks
As a remote company, the default is to feel alone unless we as a company act on that. So, we introduced coffee breaks and have 3 of them throughout the week. These breaks have no agenda and are off-topic so that you can talk about whatever. As we scale, we see some challenges in making everyone feel welcome. Usually, a few individuals speak, and others listen; we have some ideas on tackling that, but it's still a challenge for now. That said, it allows us to talk to members we don't usually work with and feel more together. The relationship of members is critical to nurture and a key to long-term success.
Knowledge sharing
Every month, someone gives a presentation about anything they'd like and shares it with the company. It is limited to 20 minutes, but you can talk about anything. We wanted to allow people to show more than their professional side and let members know each other on a deeper level. Some members are introverts and find it hard to give a presentation in front of the entire company, so we're not pushing anyone; we try to ask gently.
1-1s
One of the most fundamental routines you should have once you hire your first team member is incredibly remote. Every manager does a weekly 1-1 with their direct reports. The default is 45 minutes, but we adjust it as needed; we usually end up earlier. I also do 1-1s with my skip reports every several weeks to get in touch. A crucial aspect to understand is that 1-1s are two sides; both should set the agenda. If the report has something they want to discuss, it precedes your agenda unless you have something urgent. During the 1-1s, you'd like to understand the member's well-being, hear about their personal life and what they are going through, align with them on priorities, personal and professional growth, and anything else you have in mind. If the report is also a manager, you will talk a lot about their team and how it's doing. 1-1 is a topic for a blog post on its own, but there's already so much information available, so I'll keep it short.
Execution sync
This one is relatively new. We've been doing it for several months now. Once we grew to several teams, we realized that our major bottleneck in delivery was the handover of a task to different teams. For example, a new feature is handed over to design from product or design to engineering. We applied several changes to address this concern, but one of them is the execution sync. It's a fortnightly leadership (team leads and above) meeting discussing delivery and execution. We align on timelines and active projects and raise any blockers or potential issues that can slow us down. It's like doing a health check that all teams function as they should. Sometimes, we also discuss improving our workflows and what processes require revisiting.
Weekly updates
As we scaled, members mentioned they felt siloed. They want to be made aware of what's happening outside their teams. One way to address it was through our weekly updates. A message on Slack written by me every week covers the state of every active project. At the end of the week, every leader provides me with an update about their activity, and I compile everything into one coherent message. This is also used later in all the hands. At this point, we're about to hit the limit of a single person who writes the update, and we will soon have to transition into updates by several stakeholders. Keeping it focused and coherent will be challenging, but we'll nail it!
Monthly business review
Our newest routine. You can think of it as a monthly retro for the business. Our senior data analyst reviews the core metrics and deep dives where needed to provide a clear picture of the company's performance. He shares a document and loom as a preparation for the actual meeting. The meeting includes all business stakeholders (founders, data analyst, product manager, and head of marketing) and is being recorded. We review it together and decide how to adjust our plans based on the current state. It helps us to make sure we hit our goals. Before that, we measured every initiative's contribution to the bigger picture, but no dedicated event was set for measuring the company itself.
Product development cycle
The fundamental process you want to nail is the lifecycle of a feature. This process indicates the velocity at which the company operates. In a B2C startup like ours, getting it right and constantly fine-tuning it as the startup scales is crucial. In our case, the flow is:
- Kickoff - All relevant stakeholders meet to discuss the feature at a high level and agree on the scope.
- Wireframe - Product design uses the kickoff document and turn it into a wireframe, something visual we can discuss and provide feedback.
- Specs & pixel perfect - The product manager writes specs and user stories to be used by engineering later. In parallel, product design turns their wireframe into pixel-perfect designs.
- Technical design - Engineering assigns an epic owner, who starts writing a decision record (more about it later) to describe how they will approach it.
- Development - Once the DR is approved, we start the development.
- Launch - 99% of our features are rolled out as an experiment to understand their impact on our metrics. Once the experiment is concluded, we announce it publicly on social media and in-app channels.
We learned the hard way that the further you are in the process, the more expensive it becomes to fix a mistake. For example, if we are already in the late stages of development and the product manager suddenly wants to change the requirements, it will take significantly longer. Hence, we introduced several checkpoints and do our best to plan ahead. We try to minimize the surprises in this process.
Experimentation
To improve our intuition, ability to forecast, and understanding of the product, we must measure the impact of everything we do. Most of our features are being rolled as an A/B experiment. If something doesn't work, we roll back, of course. Everyone knows that, no hard feelings, no attachments to that work that has been done. Our primary target is to hit our company goals. Experiments allow us to work towards that safely. We also operate in such a way that we validate our hypothesis as fast as possible and then refactor what is needed. If something doesn't work, we learn whatever we can and plan a follow experiment. When it works, we celebrate together the achievement. Anyway, there's a post-analysis report that is shared publicly.
Gatherings
Twice a year, we meet in person! Our gatherings are such an exciting event. We wait for them relentlessly every time. Meeting in person isn't taken for granted when you work remotely. We hang together for several days, usually somewhere in Europe. The agenda includes working sessions, lectures, social activities, hanging out during the evenings, and having fun!
This is an exceptional experience for the team, and everyone is super hyped about it.
Engineering epic owners and decision record
We found a solid way to operate our engineering activities. I shared exactly how we do it in a previous blog post. Check it out.
Engineering weekly planning
I meet weekly with the engineering team leads to plan their sprints together. We cover the progress on the active projects, groom the backlog if needed, discuss priorities, and agree on the scope of work for the upcoming week.
Tools
It is the most subjective topic ever. You all love to hate tooling, so we made it a very straightforward decision. The worst thing you can do is battle for weeks where to manage your tickets. I'm sharing the tools we use (at least the ones I remember). Choose whatever you'd like:
- Google Workspace: org email, shared storage, calendar, the basics you need
- Atlassian stack: primarily Jira for task management and Confluence for knowledge base
- Gather.town: virtual office to make us feel less lonely, replaces Google Meet / Zoom as well
- Slack: org instant messaging
- Google Cloud: as our primary cloud provider (we have others for niche requirements)
- Deel: payroll for global teams
- Loom: sometimes we prefer to record ourselves instead of having a meeting or as prep material for a meeting
- Miro: for sharing wireframes and collaborating on them
- Figma: almost everything design-related, used by product and marketing designers
- Sendgrid: marketing and transactional emails
- Growthbook: feature flag and experimentation platform
Slack conventions
Instant messaging can make or break productivity. We came up with certain conventions to help us with this mission. I'll include only the top suggestions here, as we can spend a whole day discussing these best practices.
First, we agreed that it's the receiver's responsibility to manage their notification settings to ensure the messages don't interfere with their routine or work-life balance. Since we operate from different time zones, as a writer, finding the right time that fits everyone takes time. So, it's okay to send messages any time and tag whoever you need, assuming notifications are correctly set on the other side.
We use the 👀 reaction to acknowledge the message was read, but a response will be provided later. This solves the doubt of whether the recipient saw the message or whether you should escalate or, god forbid, call them.
Proper naming of channels is also critical to navigate between the hundreds of channels. We came up with the following prefix for channels:
- team - Indicates that it's a dedicated channel.
- feat - Used for feature communication. We open a channel for every feature to keep the discussion focused and invite only the relevant stakeholders.
- marketing - For any marketing initiatives or campaigns. Similar to feature channels.
All channels are public by default unless sensitive information is being shared there. We also don't promote the use of group messages. Most communication should happen in public channels to increase awareness and avoid broken communication.
Org Structure
Every early-stage startup reflects the founders to some extent, and so does the organizational structure. In our case, we are three founders: CEO, CDO, and CTO (myself). This is our current structure, but we learned that structure is not set in stone and should change as the company scales. You should experiment with different organizational structures, just like with other things. It's okay to try something and revert if it doesn't work.
Product
Managed directly by the CEO, consists of a product manager.
Marketing
Managed by the head of marketing and includes a designer and devrel.
HR and Operations
Managed by the head of HR and includes a business operation individual.
Product design
Managed by the CDO and consists of a product designer.
Engineering
Managed by me and consists of two teams; every team has a team lead and several engineers. The first is our platform team, and the other is the web team. We're about to introduce an organizational change to switch from domain separation to product separation. Ideally, we want teams to be autonomous and able to accomplish their tasks independently.
Analytics
Managed by me and consists of a data analyst. I mostly manage him from a professional perspective and provide my guidance where needed, but most of the prioritization is done with the product team.
Documentation
Documentation is vital for our operation as a remote and async company. We do our best to document our processes, decision-making, learning process, culture, and everything that will help us achieve our goals. New hires find it useful, and it accelerates their onboarding process. They get a document that describes what they have to do, their goals, useful links, etc. When we develop a feature, we write a DR, which other engineers can refer to understand the bigger picture. Make sure to dedicate time to having proper docs; it will help you scale your company while keeping it efficient and productive.