Leader Spotlight: Hiring and scaling a remote-first team, with Phil Freo
Phil Freo joined the founding team of Close, a specialized CRM platform designed for small to medium-sized businesses, over a decade ago. He serves as the organization’s VP of Product & Engineering. Phil started his career as a web developer after graduating with a degree in computer engineering and interned at companies such as Yahoo and Google. He later worked at Quizlet as a product manager and developer.
In our conversation, Phil talks about what it was like to scale Close from its founding team to more than 100 people and transition to being a fully remote company during that process. He shares his process of adding structure as the company added headcount across departments, as well as the advantages and challenges of a remote-first workforce.
A pioneer of remote work
Close was ahead of its time in terms of remote work. Could you talk about how you decided to operate the company remotely and how that impacted hiring?
In our early days, there were only six or seven of us working out of a small office in Palo Alto. We were trying to hire engineers in Silicon Valley, but we were a tiny startup that didn't have fancy offices or big VC funding, so it was hard to get the attention of great engineers. We found that hiring remotely really helped us stand out because back then, it wasn’t the norm.
As we grew, we largely focused on hiring people whom we had met in different ways or worked with in the past. At some point, about half of us were remote, and then, due to life events, about half of the people who were in the office moved out of state during the course of a year. There just wasn't much of an office left after that, and we’ve been fully remote ever since.
Searching for a culture and company fit
What advantages and challenges have you found when hiring remotely? Have you found any strategies to make that process more efficient?
The biggest advantage is that you can find talent anywhere in the world. Using a remote model helps retain employees when big life events happen, like relocating or starting a family. It enables people to spend more time with their loved ones, avoid long commutes, and more.
In terms of challenges, since we hire from roughly half the world’s time zones, we see more applicants for each role. It's gotten a lot more difficult now that people have built AI bots to auto-submit their resumes. In the past, we used to ask custom questions within the applications to screen for spam. AI makes that trickier now because LLMs are great at answering generic questions with something that sounds reasonable at first glance.
To combat this, we’ve added a little puzzle into our applications. Now, if you apply for a backend engineering role, you don't just submit your resume — you actually have to post a special HTTP request to one of our server endpoints and then submit the right thing back.
Cultural fit is harder to assess in a video call. Can you share any tips for how to assess that?
Because we're all working remotely, verbal — and especially written — communication is extremely important, so we look closely to identify that. We also try to find evidence that the person matches our company culture and the culture we need for that specific team. We want people who are very knowledgeable in their areas of expertise and care deeply about their work. That level of care and passion tends to come across fairly quickly in an interview.
Overall, we're looking for depth in craftsmanship, a passion for high-quality work, and strong communication skills. In a remote world specifically, you tend to have to over-communicate, so that skill is very important to us.
Adding structure as the company scales
You mentioned growing from a tight-knit team of six to over 100 people. What was that process like?
When you're just a few people, everything is super informal, and you're chatting all the time. As you grow, you start to introduce a little bit of structure. In engineering, that would mean having tech leads oversee specific areas. We didn’t initially feel like we needed managers, per se. We just said, "You own this area and have some real responsibility for it."
We introduced a show-and-tell culture to share knowledge and promote the use of informal and formal collaboration sessions, like frequent 1:1s, productive team meetings, and retrospectives. Then, as the teams grew, we slowly introduced more structure and hired managers.
When we first started looking for engineering managers, we promoted people internally but also hired some that had experience outside of Close. At first, we mostly hired full-stack engineers. We didn’t have dedicated designers or product managers, so we looked for engineers who had design or product skills. The smaller the company, the more hats people have to wear. But as we grew, we started looking for specialized engineering roles, and then, eventually, we hired our first designer and PM.
How did you continue to organize departments as you grew, and how did that eventually contribute to your success?
We grew from everybody-does-a-little-bit-of-everything to being organized by function. We had a team for both frontend and backend engineering, infrastructure, product management, and product design. That worked well — being one big product and engineering team organized functionally gave us a lot of flexibility. We pulled a few people together for six weeks at a time to work on a project, and we continued with this approach until we grew to a 50-person team.
As the product became more complex, it became harder to be an expert in all aspects of it. This is why last year, we restructured to six cross-functional teams that each have full ownership over a particular product area. This enabled us to balance that area's short-term and long-term needs, innovate, and collaborate more tightly.
What was it like for the individuals on those teams as you were making those changes? Were the changes hard for people to adjust to?
People had been asking for this type of structure for a while, although it was a big change from how we had been working for years. For example, it involved a lot of engineers having to switch managers.
My strategy in rolling this out involved writing a big document explaining why we’re doing this. Why now? What problems are we trying to solve? Where do we want to go with it? What is each team going to look like? I looped in the leadership team and fleshed out this document to answer any questions that popped up. By the time we unveiled this new structure to the whole team, we had answers to all the main questions. It was conveyed as a well-thought-out idea, so it was well-received.
We also asked for everybody's input on which team they should join. We defined the team’s missions and scopes first. Next, we established three leads (an engineering manager, product manager, and product designer trio) for each team based on their preferences. If a designer and a product manager were in opposite time zones, for example, we took that into account. Finally, we took preferences from the rest of engineering and finalized the teams. Nearly everybody was happy with where they ended up. There weren't many surprises. We also had a transition period, so not everything changed from one day to the next — it took a few months.
Overall, I find that people feel a lot more ownership over their areas. They're able to dig deeper and establish consistency with their team members.
The importance of trust and flexibility
With a fully dispersed team, how do you ensure that the vision for the company and new initiatives are communicated and that everyone stays on the same page?
Even though it requires a lot of logistics at our size, a key element is our annual team retreat. We find it critical for developing personal relationships, building camaraderie, team bonding, vision setting, and helping new team members get to know and understand the company better. This May, we’re getting together just outside of Paris.
With that said, talking about the company mission and vision only once a year is not enough. We’ve recently started hosting quarterly virtual summits to supplement the annual retreat. We give updates across the company, recast challenges for where we're going, etc.
We also have smaller meetups for managers and leaders. There are also some smaller team meetups. A few months ago, I got the product and design teams together in person because we had a bunch of new people and a new leader. Smaller meetups or mini-retreats are easier to plan, and you still get the benefit of face time with your team.
You've implemented the Shape Up product development methodology at Close. Why did you select that methodology, and how have you adapted it for a remote team?
What I find attractive about the Shape Up methodology is its fixed timeline and flexible scope. It has six-week cycles with two-week gaps between each cycle. While many engineering teams work in two-week sprints, that doesn’t typically provide enough time to deliver significant user value once the product has reached a certain level of maturity. It’s not realistic to start and ship a new big feature in just two weeks.
Shape Up’s six-week time frame, combined with the idea of a fixed timeline and flexible scope, helps us deliver value to customers without letting the scope get too large. It's also helped us to improve consistency and predictability, as the rest of the company knows when something will be done. We might not be able to say exactly how a feature will look once completed, but we know we're going to ship a version of it six weeks from now. It can be good for marketing teams and other teams to have those expectations.
Plus, the two-week cool-down periods — which we call “gap weeks” — are good for giving engineers room for paying down technical debt, handling bug fixes, and working on their own R&D projects. These gap weeks are also used to finish planning the next cycle.
How do you think your experience being one of the founding team members has shaped the way you lead the team remotely? Has it given you a different lens or perspective?
I certainly think so. We were able to shift to a fully remote company so well and so easily because our team has high trust. Trust is earned — or at least strengthened — over time and is easier to develop in person initially. We built the foundation of our company in person, and that’s been instrumental to our success. Now, we have the structure in place to extend trust and autonomy to remote team members, and that’s helped us retain amazing talent.