Michael Matloka is a product engineer at PostHog. He leads the Max AI team and originally posted this on his blog, where he posts interesting things sometimes.
In the early days of a startup, there’s clarity.
You’ve got a tight team. Everyone builds the product. Everyone’s “customer-obsessed”. Everyone is scrambling for product-market fit.
The org chart is a circle with a post-it note saying “build something people want”. A customer wants to pay the SSO tax? Say no more.
But then you grow. Areas need to be split up for ownership. Some bits get chopped up cleanly, others turn into murky waters. This is where the problems start.
Two types of teams
As product-focused companies scale, you’ll hear calls for two kinds of engineering teams1: back-office teams and glue teams.
People think they’re the same because they both:
Span multiple product areas.
Own features and problems no one else wants to own.
(Theoretically) bring order to previously messy and opaque systems.
Spoiler: they’re worlds apart.
Back-office teams serve other teams. Period.
Their customers are on the same payroll. Like the back office of a bank, paying customers never see them.
They provide backend infrastructure, build developer tools, maintain component libraries, and run data platforms. It’s neat stuff. Stuff that makes developers happy.
But back-office teams are always one layer removed from real impact.
They make tools that help people who help users. There’s a layer of indirection, and an inevitable loss of context.
Blink, and that team just spent a week solving an internal problem with minimal impact. Useful? Sure. Valuable? Not so much.
Glue teams serve users. Directly.
These folks do glue work at the level of the product. They’re product teams that just happen to cut horizontally across features instead of owning vertical slices.
Think, auth. Not flashy, not a standalone product line, yet it keeps the product together in one piece. It makes or breaks enterprise deals, or a user’s day.
Billing? The ultimate glue. That’s systems, UI, and accounting, all in one. The spice must flow.
The folks owning these areas should be talking to users, they should be owning product metrics.
Resist the calls for nice-to-haves
People want more back-office teams as you grow because it feels safer. They soothe anxiety. Reduce chaos. “It would be nice to have XYZ”, they say.
But here’s the uncomfortable truth: you can get away without back-office teams much longer than you think, and you should.
I know. Engineers are complaining about CI. Internal tools could be better. Still, keep that zero degrees of separation from customers for as long as you can.
The space of possible work is infinite; the set of tasks needed for success? Surprisingly narrow.
Distance from users makes it hard to see which is which, whether you’re an engineer, designer, or founder!
Distributed ownership is the name of the game for those internal aspects. It takes some healthy agency, for example:
One person improves the dev environment as a side quest.
Someone else maintains the component library between feature work.
Another migrates you to the latest language version.
It’s not their full-time job, and it shouldn’t be yet. And, for the hairiest problems, you agree to spin up a short-lived project team to address that specifically.
Obviously, some back-office work is an early must-have. You won’t get far without a clear owner of data infra, especially if you run a data-intensive SaaS like we do at PostHog.2
But, beyond the absolute essentials, only start a back-office team when you can honestly call its resources a rounding error compared to product development. Backend infra at 20 engineers, anything else at 50+.
Until then – a little bit of chaos is valuable: desirable, even. It teaches everyone which problems actually matter.
Address must-have gaps
Meanwhile, it’s easy to set aside shared areas of the product and forget about them. Don’t mistake them for back-office functions. This is precisely where you need glue teams.
We’re talking about aspects users hit all the time. Customers using your SDKs across 10 platforms? Without dedicated owners, the quality of those SDKs plummets over time. Paying users suffer, and not only them, as the mess is also making other teams less productive.
Auth? Billing? You already know the story.
Those glue areas don’t bring product-market fit by themselves, but neglecting them sure as hell can lose you product-user fit.
The bottom line
Spin up back-office teams when the ROI of such a team starts feeling unreasonably large – much later than you think.
Spin up glue teams when users run into pain in cross-cutting areas of the product – often earlier than you think. Keep building something people want this way.
And remember: an org that over indexes on back-office teams early will:
Optimize for fluffy internal goals more than real value.
Create an approval culture that erodes autonomy and slows you down.
That’s a death sentence, so choose wisely.
If you liked this, consider sharing it on Hacker News, X, LinkedIn, or your internet points provider of choice. You can subscribe here – it’s free and always will be.
🧠 Good reads for people who build cool stuff
How we use PostHog's built-in data warehouse – Ian Vanagas
Why LLMs Can't Really Build Software – Conrad Irwin
Everything I know about good system design – Sean Goedecke
If you're remote, ramble – Steph Ango
This article is specifically about engineering teams. There are many non-engineering teams, such as support or customer success, that you could call glue teams, too.
Still, with so much of hosting outsourced to cloud providers, infra is leaner than ever. More so if you run on Vercel + Supabase.
 | A guest post by
|
How is it that every single post you guys write resonates so much with my experience? It's so easy to lose track of the user and start focusing on internals and other companies' shenanigans. It's also true that when you have 50+ engineers, you need to start thinking about your own developers' experience as a way of keeping things moving at a good pace. Thanks for the awesome insights!
This was wonderfully put across. At my org, we perform back-office work then and there. I have been wondering when to have a full-time team for such tasks and this post gave me clarity.