23:22
cross-team dependencies
Anna Hannemann (Picnic, warehouse systems domain lead) argues that roadmaps fail not because ideas are bad but because cross-team dependencies are left implicit; the fix is a disciplined process that makes trade-offs explicit, forces dependencies through a time-boxed pre-alignment cycle, and keeps iterating alignment throughout delivery.
Picnic is an app-only, Dutch online supermarket that delivers to the door instead of running physical stores, cutting the store infrastructure traditional supermarkets need.
Picnic buys/produces stock just-in-time (e.g., baking ordered bread overnight) rather than stocking a full range like a traditional supermarket, reducing waste.
Picnic builds nearly all software in-house (app, distribution/last-mile routing, driver coaching, and warehouse systems/fulfillment) and only buys external software for non-differentiating functions like accounting, because vendor change requests are too slow.
The warehouse systems domain splits into three pillars: inbound (register and replenish goods), stock (orchestrate, count, clear inventory), and outbound (picking, dispatching, shipping — the largest pillar).
Anna leads 12 product teams plus a QA team and an 'op center' (first-level support) under the warehouse systems domain.
The general fulfillment goal stack is: safety (non-negotiable), quality (e.g., not crushing an avocado under a six-pack of water), productivity/efficiency (thin margins on cheap items require efficiency), and innovation (continuous change, with ideas welcomed from developers, business owners, and founders alike).
Idea intake works bottom-up: initiatives are collected, then WS leads/POs/tech leads convert competing options into explicit either/or trade-offs (sized in work-days), which go to founders/top management for a top-down decision; business owners are then told what they get and what they wait for.
The core failure mode identified is cross-team dependency without pre-alignment: a team ready to start gets told 'come back in two weeks' by another team, or a tech lead joins a meeting without real bandwidth, nods along, and only surfaces disagreement once the other team is already halfway through development.
Pre-alignment is meant to produce: a transparent per-team delivery plan mapped across weeks, cross-team dependencies explicitly resolved (accept/renegotiate/escalate), critical task groups visible to leads, and no hidden delivery-impacting assumptions.
The pre-alignment cadence runs roughly four weeks in three stages: week 1, tech lead and PO review the epic for completeness; week 2, the tech lead re-discusses it with their own team; weeks 3–4, a domain-level cross-team session with a devx coach maps out all dependencies.
Development continues in parallel during the four weeks; the dependency-uncovering work itself is only a couple of time-boxed meetings.
Alignment is not final — once development starts, gaps like missing data points still surface, so Picnic runs weekly check-ins between corresponding tech leads to keep realigning through the quarter.
Anna reports going directly to Picnic's founders with explicit trade-offs ('if you want this, you're not getting that') rather than hiding the cost of decisions.
Picnic treats its own dependency/trade-off process as a product to be monitored and iterated, and already has ideas for improving both the trade-off visualization and the dependency-alignment tooling.
Explicit trade-offs framework — A practice where WS leads/POs/tech leads convert competing initiative requests into concrete either/or trade-off options, sized (e.g., in work-days), instead of promising to do everything. Apply: Before committing to competing initiatives, size each option and present leadership with an explicit 'either A or B' choice so the cost of picking one is visible up front.
Three-stage pre-alignment process — A roughly four-week cadence run before big or cross-team initiatives: week 1, tech lead and PO review the epic for completeness; week 2, the tech lead re-discusses it with their own team; weeks 3–4, a domain-level cross-team session with a devx coach maps out all dependencies. Apply: Schedule these three dedicated, time-boxed touchpoints ahead of a quarter or initiative kickoff so blocking dependencies and unclear requirements surface before development starts.
Accept / renegotiate / escalate — The three required resolutions for every cross-team dependency surfaced during pre-alignment, so nothing is left as an assumed 'it'll work out.'. Apply: For each identified cross-team dependency, force a decision into one of these three buckets rather than leaving it ambiguous.
Continuous iteration on alignment — A follow-up practice where, after kickoff, teams hold weekly check-ins between corresponding tech leads to catch gaps (e.g., missing data points) that pre-alignment missed. Apply: Keep a recurring weekly tech-lead sync running through the whole delivery period, not just during planning, since alignment can still break down mid-execution.
Build vs. buy decision rule — Picnic builds software in-house where it believes the system creates competitive advantage (app, distribution, warehouse systems) and buys externally only for non-differentiating functions like accounting, to avoid slow vendor change-request cycles. Apply: Assess whether a system is a source of competitive differentiation; build in-house for speed of iteration if yes, buy externally if it's a commodity back-office function.
Monitor-and-adapt process loop — Treating the dependency/trade-off process itself as a product to be reviewed and improved over time, rather than a fixed procedure. Apply: Periodically revisit your own planning artifacts and tooling (e.g., the trade-off slide format, the dependency-tracking tool) and update them as weaknesses are identified.
The costliest dependency failures aren't teams openly refusing to help but a tech lead nodding along in a meeting without real capacity, with the conflict only surfacing once the other team is already halfway through development — damage scales with how late the hidden disagreement surfaces.
Making trade-offs explicit in work-days functions as a trust-building device with stakeholders: once a business owner sees a concrete cost ('this costs 25 work days and displaces X'), a political-feeling 'no' becomes an arithmetic one.
The pre-alignment process is deliberately timeboxed to roughly two meetings within four weeks specifically so that surfacing dependencies doesn't itself become a second roadmap-killing time sink.
Picnic's build-in-house strategy is what creates the dependency problem in the first place: because almost everything is developed internally (versus a purchased CRM's slow change-request cycle), the speed advantage they're protecting is exactly what's put at risk by unmanaged cross-team dependencies, which is why so much process investment goes into alignment.
Picnic assumes 'you can never be sure' even after formal alignment, treating continued weekly realignment as an expected second phase of the process rather than evidence that the initial alignment failed.
«today I would love to talk about managing dependence in practice uh or why your road map is lying to you.»
— 00:54
«actually official name of picnic I don't know if someone checked it but it's picnic technologies and we define ourself as a tech company. We just ended up to sell food but maybe tomorrow we are not.»
— 04:01
«you write a change request, you submit it, then you wait three weeks and you get something that change yeah that much of money and wait half a year. So that is what we don't want to do. That is why software in our hands.»
— 05:30
«general fulfillment goal that all orders are safe and a high quality and as efficient as possible.»
— 09:48
«if I just don't care about the order of picking products, I can end up putting a bulky six pack of water on your avocado. I assume you will not like this avocado.»
— 10:14
«everyone developer, business owner, founder, they are more or less at the same level of bringing up great ideas and we have seen great ideas coming from all the corners and we want to enable it.»
— 11:19
«it's all fair and people have thought about it and we can work upon what people propose but we have to do the tradeoffs explicit»
— 11:46
«why we always kind of we plan something then it takes us longer and one of the findings is cross team dependency»
— 15:56
«this team is already halfway through into the develop payment they will now start and say ah no that should this end point should not look like this and I see people nodding you you understand my pain»
— 16:52
«if there is not a clear pre-alignment it just it just wastes so much of waste of time and effort which is just a sad story.»
— 17:14
«all cross team dependency are explicitly resolved you either accept re renegotiate or escalate.»
— 17:48
«no delivery impacting assumptions remains hidden.»
— 18:17
«you align you prepare but then the life happens»
— 20:09
«I do go to them and say look if you want this you're not getting that. So this making this trade of explicit does work because otherwise why we hiding it.»
— 21:40
«continuously iterate on your alignment.»
— 22:17
Reception
No comments are available to gauge audience reception.
This is a practitioner case study grounded in Picnic's specific 12-team fulfillment domain, offering a concrete process (explicit trade-offs, staged pre-alignment, continuous realignment) rather than abstract product-management theory.
23:22