Jelena Racković · · 4 min read · Teams & delivery
Running delivery and R&D in parallel without starving either
Let me begin with the part that isn’t up for debate: delivery comes first. Clients pay for what we promised, on the date we promised it, and no experiment is worth missing that. And yet, in my own practice, research and product development have never had to starve because of it. Whether they do depends far less on the calendar than on how you work with people.
Delivery comes first, and that’s that
I have never seen a team that could afford to treat delivery as optional, and I wouldn’t want to lead one that tried. When a release is at risk, everything else waits, R&D included. Saying so plainly is important, because a team that suspects its priorities are blurred will hedge on all of them.
What I don’t accept is the conclusion that usually follows: that research therefore happens “when there is time”. In delivery, there is never time. If R&D waits for a quiet month, it waits for ever.
Why R&D usually starves
In most places I have seen, R&D fails for reasons that have little to do with ideas. It arrives as a large, vague block of work that nobody can fit into a normal week. It is treated as a favour on top of the real job, so people take it home in the evenings, or quietly don’t. And the person asking for it, often without meaning to, leaves everyone with the uneasy sense that they now owe something extra.
None of that is sustainable. People can carry a little extra for a while, but not a debt that never closes.
Small pieces, honestly sized
The first thing that helps is breaking R&D into small, self-contained pieces: a quick prototype, a short comparison, one flow sketched out, a single question answered. Each piece should fit into the gaps that delivery naturally leaves, between reviews, after a release, while waiting on a client. Large ambitions are fine, provided they are eaten in small bites.
Time management does the rest. When people use their delivery time well, those gaps appear on their own, and when they don’t, no amount of good intentions will create them. I plan R&D around the peaks of delivery rather than against them, so that nobody has to choose between the two in the same week.
Coordination that doesn’t cost time
The mechanisms around R&D should be almost invisible. A short written note instead of another meeting, one shared place where the work lives, a fixed small slot that people can rely on rather than an open-ended request. If taking part in research means extra calls and extra reporting, it has already become a burden, and people will avoid it for perfectly sensible reasons.
My role in that is mostly coordination: knowing who has room this week, who is overloaded, and which piece fits which person. It is quiet work, but it is the reason nobody feels the pressure.
Creative leadership, not extra work
In the end, it comes down to how the work is offered. I don’t hand out R&D as an obligation. I invite people into it, explain why it matters and make it clear that their part counts, both in the result and in how we talk about it afterwards. When someone’s idea or prototype shapes a product decision, they hear about it, and so does everyone else.
People who feel they are part of something creative, interesting and potentially important for all of us give it a different kind of attention. They don’t need to be pushed, and they rarely feel they are paying a price. That, more than any process, is what lets R&D move quickly and lightly alongside delivery.
What it looks like when it works
Delivery stays on track, because it was never in competition. R&D moves in small, steady steps, and quite often what it produces flows straight back into delivery as a better component, a faster flow or a clearer decision. And the people involved grow, because they get to think beyond the ticket in front of them without it costing them their weekends.
Delivery comes first. Done well, it doesn’t have to come alone.