Building a Distributed Optimization Team: Community-Led Growth Lessons from Scaling PageSpeed Matters

I started PageSpeed Matters six years ago with one engineer and a single WooCommerce client whose checkout was loading in twelve seconds. We now run more than fifteen hundred speed optimizations a year for stores on WordPress, WooCommerce, Shopify, and Shopify Plus. The work is technical, but the part that actually scaled the business was not the code. It was the team, and the small community that formed around it.

If you run a services business built on specialized skills, this piece is for you. I want to walk through what worked for us in building a distributed team of optimization engineers, how we used community-led growth patterns internally, and what I would tell any founder trying to move from ten clients to a thousand without losing the craft.

The first problem was not hiring. It was teaching.

When we passed roughly thirty clients a month, I ran out of hours. The obvious fix was to hire more engineers. The real fix was to write down what I knew. I kept a shared document of every optimization technique we used, every plugin trap on WooCommerce, every theme-level quirk we hit on Shopify. That document became our first internal handbook.

Lesson one for anyone building a remote team in a technical field: your content is your curriculum. If you cannot point a new hire at a written playbook for their first week, you do not have a team. You have five copies of yourself waiting to burn out.

Community-led growth is a hiring channel, not just a marketing term.

Most of my best engineers did not come from job boards. They came from the small, deeply technical slack groups and forums where people argue about Core Web Vitals, Largest Contentful Paint, and whether a given Shopify theme can be salvaged or needs to be rebuilt. I spent time in those rooms for years, not to recruit, but because that is where the work was being discussed.

When I eventually opened roles, I already knew who the thoughtful contributors were. Community-led growth in a services business works the same way it does in a product business. You show up, share real answers, credit other people, and over time the right people self-select into your orbit. That is a slower funnel than paid ads, but the retention numbers are not comparable.

Mentorship at scale means splitting the engineer from the critic.

One pattern that made our team stronger: we separated the engineer who does the work from the engineer who reviews the work. Every optimization project, no matter how small, has a second set of eyes before it ships to the client. That review is not a gate. It is a teaching moment. Junior engineers learn by seeing a senior engineer annotate their Lighthouse report and explain why they would have approached the Cumulative Layout Shift fix differently.

This doubles our per-project cost on paper. In practice, it reduced post-launch regressions, made training faster, and built the internal trust that lets people work across time zones without constant check-ins. It also turned every senior engineer into a mentor by default, which is far more sustainable than trying to hire mentors.

Write the feedback loop before the process.

Early on I tried to write process documents. Step one, step two, step three. They were useless inside of a month. Client stacks change, browsers change, Shopify ships new features, and any step-by-step gets stale. What did not get stale was the feedback loop: every project ends with a short written retro that lists one thing we would do differently next time.

Those retros, accumulated over years, are worth more than any SOP. New engineers read them in order and get a compressed tour of every mistake we ever made. If you are trying to build learning and development for a remote technical team, start there. Ritualize the retro before you ritualize the process.

Small rooms beat big rooms.

We tried a company-wide weekly meeting for about a year. It was a waste. People half-listened, the generalist topics did not serve anyone, and the timezone spread made it painful. We replaced it with small pods of three to five engineers who own a specific client vertical, meet weekly in their own room, and write a one-paragraph summary for everyone else.

The paragraph is the key. It forces each pod to say what they learned in plain language, and it gives the rest of the team a way to skim what is happening without sitting in meetings they do not need. Community inside a company works the same way community outside a company works: small rooms where people actually know each other, with a light layer of cross-room visibility on top.

Document the why, not the what.

Our internal wiki used to be a list of techniques. It is now a list of reasons. Instead of "how to preload fonts on WooCommerce," the entry is "why we preload fonts, when we do not, and what the tradeoff is on a low-traffic store." The shift changed how new engineers think. They stopped looking for the right answer and started asking the right question.

If you want your team to grow without you, teach judgment, not steps. Judgment generalizes to new platforms, new client problems, and new browser behavior. A step-by-step does not.

The compound effect shows up in client trust.

Six years in, our best clients are not the ones who bought the cheapest audit. They are the ones who watched us explain our reasoning over and over in emails, Slack threads, and quarterly reviews. They stayed because the team underneath the work was visibly learning. That is community-led growth pointed inward. When your own people are growing in view of your clients, clients compound.

What I would tell any founder trying to scale a technical services team

Start with the handbook before the hires. Spend real time in the communities your work lives in. Build review into every project, not as a gate but as a teaching moment. Retire process documents and keep retros. Split your team into small pods and make the pods write. Document reasoning, not steps. And then be patient. None of this shows up in the first quarter. It shows up around year three, when the team is running projects you never touched and the clients do not notice the difference.