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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
Nick Fisk shares his experience leading transformations and transitioning companies to a product ownership model.
It’s easy to hide behind charts and justify decisions with shallow metrics. But great product teams resist that urge.
Tony Schumacher shares important lessons he learned and has taken with him from working under his former boss and mentor.
Using these guidelines, you can ensure that you develop lean, functional, and valuable products — all while avoiding feature creep.
Learn more →
