Building a Remote Company: Lessons Learned from Idea to Exit
We built a company from idea to exit. Our team was fully remote since day 1.
2015-2019: Perengo Case Study
When we started Perengo, all of us were working full-time in our day jobs. Our team was distributed across various cities (San Francisco; Palo Alto; Ashburn, VA; Kaiserslautern) so we worked/communicated exclusively through digital channels.
This pattern stuck with us through all phases of the company and to this day we are still working remotely even within the new company structure.
Fun fact: The first time I met my co-founder Erik face to face was 2 years into building the company.
Disclaimer
We built and exited a business, hence it worked for us. But take all information with a grain of salt since we are most likely in ‘Survivorship Bias’ territory and not all approaches/workflows can be re-applied 1:1. It might not work for you.
Most importantly, industries/context/time are changing and the ‘decks are re-shuffled’ all the time. New situations need new approaches.
Remote: Different Setups
Remote companies come in different flavors. A good way to classify organizations is across 2 dimensions: location (horizontally) and communication (vertically).
We were distributed (West Coast; East Coast; Germany; Poland; Italy; Spain) and due to the time difference needed to work/communicate in an asynchronous way (project management tools + company chat). Hence you can find Perengo in the top right quadrant.
Some of our initial considerations:
Location
- Limit the team locations to US/EU time zones since it gives a max time ∂ of 10 hours and allows for at least 3 hours of overlap across all teams
- We initially had a contributor based in Singapore, yet it was more difficult to accommodate all-hands meetings across 3 continents (there are many scheduling tools but what ends up happening is that one region has to participate at an extremely late/early hour, which makes it difficult for regular meetings in the long run).
Work/Communication
- Asynchronous communication is standard for engineers // it worked equally well for all non-tech functions
- Async allows for extended blocks of uninterrupted working time (recommended reading: maker’s schedule, manager’s schedule)
Workflows
Remote work is standard practice for many engineering teams.
I worked primarily on our ABC projects (all but code), including:
- Accounting & Finance: book keeping; monthly closes; invoicing/billing; budgeting/forecasting
- HR & Legal: Contract creation/review/negotiation/signing; recruitment + hiring
- Partnership Development: Acquisition/management of partners; audits/reviews; work w/ product team to create analytics/data tools for partnership management + partner audiences
- Sales & Marketing: Lead gen activities; content planning/creation/distribution
All of the tasks above can be completed remotely.
Strategic/conceptual work is facilitated by video conference calls or occasional face-to-face meetings. Execution of tasks is easy through collaborative tools with comment/comms/real-time editing functions.
Why Remote
We see a couple of benefits in working remotely.
Hiring
- GEO: Your talent pool is much larger. Some job/skill types might be more prevalent in other cities/areas (example: adtech expertise found in NYC; Paris; Berlin; Tel Aviv; cities where there are lots of adtech companies)
- Salaries: You are not limited to local market dynamics and salary expectations. Example: Perengo is SF-based but recruiting engineers in the Bay Area is competitive and expensive.
- Work/Life Balance: All our team members enjoy the benefits of working from home or while traveling (E.g. flexibility to move around; reduction of commute time; etc.)
Process & Systems
- Processes: Use of standardized tools with inherent governance allows us to scale/onboard easily.
- Transparency: Increased transparency via better documentation (shared folders/docs) and communication (open comms channels in slack).
- Evaluation: Improved performance measurement by judging quality of work (vs. time ‘spent’ in office)
Cost Savings
- Office: Reduced monthly overhead via not having an office. We still had a postbox in a Regus co-working space to receive mail and having the flexibility to work from a day-office.
- Commute: No need to spend on commute-related items.
Team Enablement
Optimize for Single Player
Providing clear guidance and enablement for team members will help them to execute remotely. Andi Klinger (Head of Remote at AngelList, previously Product Hunt CTO) has talked about this concept at length.
Read Andi’s in-depth blog post. Has a lot of good suggestions/best-practices for remote engineering teams specifically.
OKRs and Guidelines
Alignment of prioritization & execution via OKRs (Objectives and Key Results) helps to align a team member’s direction with the organization’s high-level goals. Read: Firstround Capital intro to OKRs.
If objectives and guidelines (see further below) are clearly defined it helps the individual team member to be productive.
Quality > Effort
Quality/process of work should be evaluated, not clocked hours.
Work Principles
These ideas help us to be productive:
Standardization
Work with templates and standardized guides/rule books to [1] save time and [2] achieve consistency.
One of my favorite tools to achieve standardization - in this case consistent brand execution - is the Brand Pyramid and its application for Product Value Propositions (PVP). The purpose is to serve as a single source of truth for messaging. A product value prop is made up of the following sections:
- Benefit pillars: high-level benefits to customer
- Feature bullets: actual product features on a detailed level (serve as reasons-to-believe for benefit pillars)
- Talking points: tailored story lines for different audiences
The PVP document has many uses:
- [Internal] Onboarding documentation for all new hires
- [Internal] Training manual for sales teams
- [External] Messaging guideline for all asset creation (Sales decks; marketing/landing pages; blog posts; ad copy; website copy; press release content; etc)
- [External] Editorial calendar for blog posts (use the different content points and turn them into fleshed out blog posts)
Automation
If a task needs to be done more than once, try to automate. For business workflows there are a few helpful tools:
- Zapier is a tool to create ‘automation recipes’ for a extensive list of services (e.g. moving a form capture into a google sheet). Not free but very helpful.
- GMass is a mail merge/automation tool, which kicks your sales/comms work into overdrive. The coolest feature is a rule-based auto-follow up, which allows you to send up to 8 pre-scheduled follow-up mails depending on the recipients activity. Another benefit is that it is 1:1 communication and is sent straight from your gmail account vs. a mail server (benefit: it is a 1:1 communication and your mails don’t land in spam folders).
- (Virtual Assistants) are technically not an automation but they certainly feel like it. I would use VAs to conduct structured/extensive research tasks. Write a concise brief/task description and extend your team/productivity on-demand.
- Tool-specific Automations are productized automations for frequent workflows. One example would be invoice conversion (pdf doc from email > creation of entry in accounting system).
Iteration
Systems/processes need to be revisited on a regular basis, since they are usually a fix for the issue at hand. We do think about scalability and ‘future-proofness’ of fixes but we are also aware that most likely an updated will be needed once complexity increases.
We usually did not put solutions in place for challenges, which might or might not happen in the future. It’s ‘work in progress’. 🚧
Tools
Many have written about tooling for remote companies, hence I’ll leave you with a visual of our setup through most of the years:
Communication
We have experimented with various meeting cadences and compositions and have arrived at the following:
Daily Comms
Written communication is our default. Whether it's via slack, JIRA, google docs, etc it allows for transparency, asynchronous communication, and the creation of reusable assets.
Weekly Dept Sync
Regular department/team check-in (can be more frequent depending on team/type of work)
Weekly 1:1s
Colleague sync for management of direct reports and project-based collaboration (also cross-functional when needed)
Bi-weekly All-Team Sync
All-team call primarily focused on giving face-time with the rest of the team.
During this call each person answers 4 questions:
- How do I feel?
- My biggest positive?
- My biggest negative?
- What is my one wish?
After everyone is done with their answers (usually 1min max per person) our team/department Leads give a high-level overview of what has been done in the past two weeks and what is planned for the next week.
Quarterly Hackathon
Eng/Dev/Prod meet in person to work on roadmap planning or focused feature development. Usually we change cities (previously: Washington D.C.; Jersey City; Warsaw; Berlin; Barcelona) but try to optimize for easy travel arrangement.
* Optional syncs are added when/where needed
Resources/Thinkers
There are many awesome companies and individuals who have shared their learnings experience. We have used many of these resources to inform our own setup.
- Buffer
- Zapier
- Automattic
- Slite
- Helpscout
- remote fabric
- Andreas Klinger
- Managing People
- GitLab’s Guide to All-Remote
- GitLab's Company Handbook
- remote farbric on Documentation
- Written communication is remote work super power
“Adapt what is useful, reject what is useless, and add what is specifically your own.” – Bruce Lee
Get in touch if you have feedback/input/different experience/etc.
Also, we’re hiring across all teams. 🚀
