How We Structure Rohlik Tech: Cells, Metrics, and the Thin Layer on Top
We organize engineering around small cells of 3–5 people, each owning one business metric and a handful of guardrails — here's why and how.
The problem with the structure we had before
For years, Rohlik Tech was organized into Tribes — big, multi-quarter product organizations. Tribes had targets. That wasn't the problem. The problem was that the targets got lost in a sea of parallel projects, with initiatives that offset each other's benefits, ROI that was never fully attributable, and success metrics that quietly shifted between quarters.
In practice that meant you could finish a strong year inside a Tribe and still find it hard to point at the number that moved because you were there. A team in that state gets work routed to it by whoever shouts loudest, optimizes for shipping rather than outcomes, and quietly turns engineering capacity into a cost center.
So we rebuilt around cells.
What a cell actually is
A cell is a contract between business and engineering. It has:
- 3–5 engineers. Sometimes a bit more with QA, ML, AI, or Operations Research engineers embedded. Not 8. Not 15.
- A business Lead. They own the metric from the commercial side.
- An Engineering Manager. They own delivery, people, and — increasingly — the technical craft as a player-coach (more on that below).
- Often a Tech Lead. For cells in complex domains.
- One North Star metric. One. Not a dashboard — one number that goes on the scoreboard.
- 2–3 guardrails. Things we promise not to break while we chase the North Star.
- A 24/7 on-call plan routed directly to the cell via incident.io — no more "@team in Slack" theater. On-call can be shared across several cells where the surface area and risk profile make that sensible.
- Data ownership. Every cell is the explicit source of truth for a defined data entity.
A few live examples:
| Cell | North Star | Example guardrail |
|---|---|---|
| Maia | Conversations per day | CSAT must not drop |
| Ads | Ads revenue per Monthly Active User | Webshop conversion rate must not drop |
| Availability (supply) | Sales-weighted availability | Shrink levels maintained |
| Margin | Absolute margin | SKU count per fulfillment center capped |
| Last Mile Optimization | Route Efficiency | Delivery delays must not worsen |
| Picking | Picking performance (order lines / hour) | No impact on delivery delay |
| Finance 2-way match | % of paired items | Pairing quality within paired set preserved |
If a cell can't articulate its North Star and guardrails cleanly, that's a signal — not a reason to dress it up in generalities. We work with the Lead and EM to sharpen the definition, because a cell without a public metric can't honestly coordinate with the rest of the business.
Why cells are so small
Two reasons, both boring and both true.
- Five people can hold a problem in their heads. Fifteen can't. Every additional body is an additional coordination edge; past five, you spend more energy on the team than on the problem.
- You can't hide in a cell of four. The North Star is public, the baseline is public, the target is public. There's no "the team is working on many things." The team is working on the thing.
The side effect we didn't fully predict: cells of 3–5 force aggressive delegation to agents and automation. When you physically can't throw more people at scope, you throw agents. That's a bigger topic and a post of its own — for now, take it as given that agentic engineering is no longer optional for us.
The layer on top
Not everything fits neatly in a cell. Some things are genuinely cross-cutting, and some things are inside a product domain but not inside any one cell. We run two kinds of teams outside cells.
Central horizontal teams — one of each, company-wide, for cross-cell infrastructure:
- Platform & Infrastructure. DevOps/SRE, databases, networking, platform QA. Owns the paved road. Doesn't ship features — enables features to ship safely many times a day.
- Application Support / L2. First responder for production pain, runbook curator, operational eyes. Heavy user of our own internal agents that generate runbooks straight from incidents.
- Data Engineering. Pipelines, warehouse, and the plumbing that makes "one North Star metric" actually measurable — and powers the data pipelines that make or forecasting and automated agents across company work.
Small domain-scoped platform teams — inside product domains where several cells share a surface:
- Customer Experience platform team — for the customer-facing components that aren't any one cell's primary scope but still need ongoing application development (shared frames, cross-cell flows, standalone customer-facing projects that don't map to a cell's North Star).
- Internal Systems platform team — the equivalent for shared back-office and operations surfaces used by multiple Internal Systems cells.
These domain platform teams are small and deliberately scoped. They aren't mini Tribes.
Note what's not on this list: ML, AI, and Operations Research engineering. We used to think of them as horizontal teams. They aren't. ML, AI, and OR engineers are embedded inside the cells where their work lives — Availability, AI Customer Care, Forecasting, FC Planning, and so on. They keep their craft identity through guilds and regular syncs, but they live, stand up, and are on-call with the cell. Distance between the model and the business metric was exactly the thing we were trying to eliminate.
Engineering Managers as player-coaches
The EM role at Rohlik is moving from manager to player-coach. In tech, a player-coach is a hands-on engineering manager — someone who still contributes technically (designs systems, reviews and writes code, joins on-call rotations, sometimes takes architecture calls) while also coaching engineers, owning delivery, and running people development.
Why this direction? Because pure manager EMs drift away from the code, and in an agentic engineering environment the distance between management and the actual craft is the thing that makes decisions worse. A player-coach EM has the technical credibility to unblock the team when it matters, and the context to coach engineers on real problems rather than abstract ones.
Cell-to-EM ratios vary. Some EMs run a single cell because its application surface is complex and deserves undivided attention. Others run two or three cells with simpler, parallel scopes. The decision is driven by the complexity of the application surface — not by a head-count formula.
Senior Technical Domain Leads
Senior Technical Domain Leads (STDLs) are one of the most important roles in how we operate. They don't run a team. They are individual contributors who go where the technical risk is highest — sometimes embedded inside a single cell for a hard architectural push, sometimes floating across a domain when the challenge spans several cells.
Their remit is three things at once:
- Architecture and data contracts — keeping cells from fracturing the monolith into a hundred local optima.
- Decoupling strategy — defining how cells separate safely so they can ship independently.
- Developer experience and shipping speed — because architecture that's technically correct but slow to work with isn't actually correct for us.
When a cell wants to pick up speed by breaking something it shouldn't break, the STDL is the person who says "no, or yes, here's how." When the paved road isn't paved enough, the STDL is the person who notices and fixes it.
What this setup is designed to do
Three things.
- Decouple output from headcount. Small cells, plus an agentic engineering stack, plus unified build/test/run tooling — we ship more per engineer, year on year.
- Kill "fear of deployment." Direct P1 routing, tight SLOs in every domain, low alert noise, fast time-to-detect. If deploying is scary, cells can't iterate. If cells can't iterate, the metric doesn't move.
- Surface cell ROI and make contributions visible. When every cell has a public North Star, a public guardrail set, and a public baseline, individual and team impact stops being an argument and starts being a number. That changes how we calibrate, how we promote, and how we decide what to fund next.
What we don't claim
This isn't a framework we invented. Cells look a lot like what others have called two-pizza teams or squads. What's ours is the contract — the explicit metric + guardrails + on-call + data-ownership bundle — and the decision to pair it with an agentic engineering stack and a player-coach EM model so that cells stay small as scope grows.
We're also honest that it's still in motion. Some cells are green-field and humming. Some are still filling in their on-call plan and SLOs. A few are TBD on the North Star number because the measurement pipeline isn't there yet. That's fine — a cell without a number has a clock on the wall to put one up, which is a healthier failure mode than a structure that never had the number to begin with.
If you're joining
You will belong to one cell. You'll know the metric on day one. Your EM will probably be managing two other cells, so you'll rely on your cell Lead and Tech Lead for day-to-day direction. You'll be expected to use agentic tooling aggressively — our ratio of human-written to agent-written code is inverting, and the engineers thriving here are the ones who treat agents as leverage rather than threat.
And yes, you'll potentially be on call for the thing you built. Because we believe that's the only honest way to write code that runs in production.
Questions, pushback, "you're wrong about X" — always welcome. Find me on LinkedIn or email.