Organizing R&D Teams

Tactical Approaches for Long-Term Impact

One of the most impactful long-term choices we make as R&D leaders is how we organize our teams.

It’s not just an org chart question. It’s an architecture, product, and strategy question. Conway’s Law has proven true in my experience: the systems we build mirror the communication structure of the teams that build them. The way we structure our teams directly shapes our architecture. That architecture, in turn, shapes our product over time — either enabling or constraining our long-term strategies.

Because team design is so important, I’ve written before about principles for making cross-team collaboration work. This post builds on those principles, sharing the tactical approaches I use when designing the team structures themselves.

Here are six tactics I rely on.

1. Take your time

I’ve yet to see a situation — either as a leader or an IC — where an urgent reorg was the best way to solve an immediate crisis. There are almost always faster, less disruptive ways to address the issue at hand. Reorgs are long-term moves that deserve deliberate, strategic thinking.

That’s why I recommend taking your time. Understand your business, your people, your opportunities, and your customers before you start rearranging teams. Thoughtful changes are more likely to stick — and more likely to deliver the results you actually need.

2. Start with your customers (and their customers)

When you are ready to rethink your org, start with your customers. Deeply understanding who they are, what they need, and how they experience your product should drive how you shape your teams.

At Kard, we’re a B2B company, so our direct customers are businesses — merchants and rewards issuers. But our thinking doesn’t stop there. Those businesses have customers too: cardholders shopping at those merchants or earning rewards from those issuers. The needs of our customers’ customers directly shape how we organize our teams.

This perspective — treating end consumers as key participants in our own value stream — helps us design better team boundaries and responsibilities. It’s easy to accidentally optimize your org for your internal systems. It’s much better to optimize for the customers you’re trying to serve.

3. Map the value stream starting with customer needs

This customer-first mindset naturally leads to the next tactic: map your value stream starting from the customer’s need, not your product’s current structure.

This is where product thinking comes in. Customers don’t care about your internal teams or architecture. They have a problem, and your product hopefully solves that problem better than the alternatives they can find.

If you map your value stream starting with that need — and follow it through to the product and systems that deliver it — you’ll get a much clearer sense of where value is created and where it’s at risk. This focus on customer needs is at the heart of the “jobs to be done” mindset, and it’s a powerful lens for organizational design.

At Kard, for example, card issuers aren’t buying a rewards platform because they want rewards. They’re buying a way to keep their cardholders happy and loyal. Rewards are just the tool. Keeping that end goal front and center helps us design teams that directly contribute to the outcomes our customers actually care about.

4. Bring in your architects early

Once you understand the customer needs and have mapped the value stream, it’s time to bring in your architects.

This is where Conway’s Law becomes intentional instead of accidental. Your org design is also a design for your future architecture. The teams you create and the boundaries you draw will influence how your systems evolve for years to come.

At Kard, I rely heavily on our staff engineers to help with this. They have the technical depth to see the tradeoffs between flexibility and cohesion, between independence and reuse. I like to work with a small group of trusted technical leaders to shape the initial design, then get broader input once we have something solid to react to.

The goal isn’t just a map of how things work today. It’s a vision for how they could work tomorrow.

5. Empower your product platform teams

This next point is critical, and it’s one I’ve seen too many teams skip. Your platform teams — specifically, your product platform teams — are the connective tissue between your customer-facing teams. They deserve intentional design and real empowerment.

At Kard, I distinguish between two types of platform teams:

• Product platform teams own the custom-built infrastructure that connects our product teams. They build the pipelines and shared systems that let product teams work independently while contributing to a coherent whole.

• Developer experience (DX) teams own the guardrails and automation that make day-to-day engineering easier, like infrastructure as code, CI/CD pipelines, and developer tooling.

Here, I’m talking about the product platform teams. These teams need to be empowered to own and evolve the cross-team architecture. They need to understand the customer needs and product goals driving that architecture, and they need the authority to make changes when necessary. At the same time, their goal should be to push as much ownership as possible to the customer-facing teams, keeping only the parts that require cross-team coordination.

The best product platform teams balance these two forces: centralizing only what’s necessary, and decentralizing everything else.

6. Design for cross-team contribution

This last tactic is one I’m particularly excited about right now. It’s easy to design team boundaries that look clean on paper, where each team owns a product surface, a customer journey, or a technical service. But real-world value delivery is rarely that tidy. Teams inevitably need to influence parts of the product they don’t directly own.

Rather than fighting that reality, design for it.

At Kard, we’re leaning into this with explicit plug points between teams. One example: our merchant team defines how offers should match transactions, but that offer-matching logic runs in a system owned by the loyalty experience team. Rather than requiring code contributions across teams, we use Open Policy Agent (OPA) and Rego rules to let the merchant team define their offer logic directly — no pull request required.

This kind of architecture, where teams build for cross-team contribution, speeds up delivery, reduces coordination overhead, and preserves team autonomy. Whether you use OPA, plug-in systems, configuration files, or something else, the goal is the same: make it easy for teams to contribute to each other’s work without bottlenecks.

Every org design is a bet

None of these tactics guarantee success. Every org design is a bet on your customers, your product, your team, and your future. But these approaches — taking your time, starting with customer needs, mapping the value stream, involving architects, empowering platform teams, and designing for cross-team contribution — have served me well across multiple companies and stages.

I’d love to hear how you approach team design in your own organizations. What’s worked for you? What’s surprised you? What’s still an open question? Let’s compare notes.