How we organize & collaborate
Most companies organise by function — engineering reports to engineering, product reports to product, and getting anything shipped means coordinating across five departments that each have their own priorities. We did that too, for a while. Then we stopped.
At Infobip, engineers work in Bases — cross-functional units that own a product domain end-to-end. Your team isn't just other engineers. It's product, go-to-market, support — everyone who needs to be in the room to ship something real and see it land with customers. You build it, you own it, and you're close enough to the customer to know whether it mattered.
Why we changed
As we scaled past thousands of employees and dozens of products, three problems kept getting worse:
- Distance from customers. Engineers were building features based on specs that had passed through three layers of translation. The people closest to the code were furthest from the people using it.
- Handoff hell. Delivering anything meaningful required coordinating across multiple departments, each with their own priorities and definition of "done." Accountability was diffuse.
- Competing priorities. "We hit our sprint goals" didn't always mean "the customer got what they needed."
We didn't need a reorg. We needed a different operating model.
Enter Bases
We adopted an approach inspired by the unFIX model — an organisational design framework built around modular, cross-functional units.
Think of a Base as a small company within the company. Each Base owns a product domain end-to-end: strategy, engineering, product, go-to-market, and support. Shared goals, shared accountability, its own OKRs and P&L. The people who build the product, sell it, and support it are in the same unit.
This wasn't a top-down mandate. It evolved, building on earlier experiments with mission-based teams and cross-functional squads. Today, we operate 11 Bases across our core products.
What's inside a Base
Each Base is structured around value streams — small, cross-functional teams (typically 3–7 people) that own a specific slice of the product from customer need to delivered value.
- Base Leader — runs the unit like the CEO of a small business. Sets strategy, owns outcomes.
- Governance Crew — the leadership team. Decisions on staffing, performance, and direction.
- Value Streams — the teams that actually ship. Engineers, product, and whoever else is needed, working together daily.
- Embedded partners — each Base has its own people partner and finance partner in the team.
Instead of working in an engineering team that serves multiple products, you're embedded in the product. When a customer has a problem, you hear about it directly.
You'll have a clear reporting line, backed by engineering leadership that maintains consistent standards and career growth across the company.
Cross-Base: How work actually flows
Bases give you a home. But real products don't respect org boundaries, so cross-Base collaboration needs to happen without building new walls. Mostly, you just do it — find someone on Slack and ask. Engineers are connected across the company, technical standards get debated and "we solved exactly that last quarter" actually happens.
The culture that makes it work
The culture that holds all of this together has been there since the garage. A junior engineer can reach out to a Principal and get a real answer. Teams set their own working agreements; the Governance Crew gives you direction and constraints — how you get there is your call.
The hardest part of this model isn't the org chart. It's the mindset. Moving from "this is my scope" to "what does the customer actually need" is a real shift — and nobody's going to manage you through it. Engineers who thrive here think about impact over output and are comfortable making calls without a detailed spec. If that sounds energising rather than exhausting, you'll fit right in.
Was this page helpful?