Who's Holding The Map?
Collaboration, alignment, and the work underneath the work.
Welcome back to Tech Team Talk!
This series is about widening the lens on engineering culture, making space for the people who shape it from seats that aren’t always centered in leadership conversations. Engineers, designers, technical writers, and today, a product manager I’ve worked with for over a decade.
Introducing Ksenia Svetlichnaya
I’m so pleased to have Ksenia here. We’ve worked together remotely for ten years, with regular in-person offsites along the way. In that time she’s become one of the sharpest thinkers I know about how cross-functional teams actually function.
She’s clear-eyed about the friction, the defense phases, the moments when smart people with good intentions stop collaborating and start protecting their turf. But more importantly, she understands what sits underneath those moments, and what it takes to move past them.
Ksenia has taught me to see things in cross-functional rooms that most people miss. This piece is a good example of what that looks like in practice.
Now over to Ksenia!
What cross-functional work looks like from the PM seat
Everyone in your cross-functional meetings cares about the work.
That’s the problem, actually.
When people care, they protect. They’ve thought through their piece. They believe in their approach. And when someone else’s opinion bumps against it, the walls go up.
“Don’t come onto my territory. Don’t make a mess here. Go do your part.”
It doesn’t matter which seat you’re in, engineering, design, product, data, or leadership. The dynamic is the same: smart people, good intentions, and shared goals.
And somehow, a room full of alignment turns into a room full of defense.
I’ve spent ten years in the middle of these rooms. Product and project. Strategy and execution. What we’re building and why we’re building it.
The hardest part is never the planning. It’s never prioritization.
It’s getting people who care – really care – to realize they’re already saying the same thing. Just in different words.
The Role
I’m a product manager, though like most PMs now, the role spills beyond the title. I handle:
Strategy
Execution
Discovery
Delivery
And the endless work of alignment
But there’s a useful distinction here.
Project asks: what do we need to build? Product asks: why do we need to build it?
The second question is nuanced. You have to interact with users, work with estimates, and find the middle ground between what everyone wants.
The role has blurred over the years. Everyone’s role has. Developers think about design. Designers think about architecture. I’m asking “why are we doing this?” on top of “what are we doing?”
We’re all stepping on each other’s heels a little. That’s just how it is now when you’re on a small team where everyone wears multiple hats.
This also means I see the defense phase from every angle. I see when engineers feel their technical judgment is being dismissed. I see when designers feel their work is being reduced to decoration. I see when leadership’s timelines don’t match anyone’s reality.
And I see what happens when people stop defending and start asking better questions.
One thing about this role: it requires constant focus-switching. I’m holding multiple processes in parallel: what was said in this meeting, what was decided in that one, what’s still unresolved from last week. I hold the context so you don’t have to.
The Map
The biggest misconception is that product managers exist to clash with engineering. Think about it: why would anyone hire a person whose job is to fight with the team?
They wouldn’t.
Take rally racing. There’s a driver: hands on the wheel, eyes on the road, shifting gears, braking, accelerating. Total focus on controlling the car. And there’s a co-driver: reading the route, calling out what’s ahead, warning about the turn before you can see it.
If the driver had to navigate and steer at the same time, they’d go half as fast. The cognitive load would break something.
That’s the dynamic.
I’m not the person with the plan. I’m the person holding the live-updating map so you can keep your hands on the wheel.
The second misconception is that PMs make plans so teams can follow them.
No.
We make plans so we know when something’s not going according to plan. So we can figure out the new route before anyone drives off a cliff.
The map is constantly updating. That’s the job: holding the context, tracking the changes, remembering what was said three meetings ago so you don’t have to.
There’s a tension I navigate constantly. The architect needs to think long-term and build something that will last. But they also need to understand that what we’re building right now might change fifteen times, and we don’t need a fundamental solution yet. It needs to be simple enough that someone else can pick it up. Balancing long-term thinking with right-now flexibility is part of what I hold.
When someone’s plan breaks – and it will – they can come to me and say: “This point didn’t work.”
And instead of recalculating everything themselves, they get their picture of the world back. That’s the phrase we use in Russian, картина мира/kartina mira. Not just the next step, the whole orientation: where you are, where you’re going, how things fit together.
That’s what the PM returns to you. So you don’t have to rebuild it from scratch every time something shifts.
That’s the value. Not control but clarity.
The Walls
But clarity isn’t enough if the walls are already up.
So you learn to watch for them.
I track shifts:
Someone’s quieter than usual
Someone who used to comment isn’t commenting
Someone’s energy has changed
These are the early signs.
We do this thing at the start of meetings, maybe you’ve seen it, you pick an emoji that shows how you’re feeling. For example:
A hedgehog 🦔
A block of ice 🧊
A burning fire 🔥
A warm coffee ☕
What’s interesting is that the same image means different things to different people. Warm coffee might mean warmth and ease. Or it might mean: I’ve had three cups and I’m barely functioning.
So you ask. You don’t assume.
Here’s something I’ve noticed: alignment is much easier when both sides see something as trivial. And trivial doesn’t mean small, it means predictable.
I know the steps: one, two, three, four, five, six. When both the PM and the engineer see the work that way – same appetite, same expectations – things flow. The context is small, easy to hold in your head, no hidden layers.
But when there’s a mismatch, when I think it’s straightforward and engineering sees an unsolved problem or the other way around, that’s when the walls start going up.
Very often, the people in these rooms are perfectionists. They care about their piece being done well. When that gets questioned, it doesn’t just feel like disagreement. It feels like being diminished. And when you feel diminished, you stop collaborating. You start defending.
When you notice someone’s shifted – when you sense the walls going up – you find a way to ask: what happened?
People usually tell you, they want to be seen.
Empathy is a core skill here. I think it’s actually my strength. If you assume the person across from you is throwing a spanner in the works, it’s hard to support them. But if you start from the position that they’re not your enemy, that they have feelings, beliefs, and a desire to do good work – you can find a way through.
That’s the real work: noticing, asking, and making space for the actual conversation.
The Work
When it works, it feels like a relay race.
I lay out the strategy. The architects help decompose it. The designer understands the user problem and knows how to solve it in the interface. The developers support the solution with fast, efficient implementation. We deliver what the user expected: no delays, no deployment surprises.
And when the feedback comes in – when users tell us it’s working – every team member shares in the joy.
That’s what I love about this work. When we’re on the same page. When we trust each other, understand who does what, and the baton passes cleanly from hand to hand.
But when someone misunderstands or doesn’t listen, the baton drops. Someone fumbles it. The race is lost. And the whole team feels that too.
The work is keeping the baton moving. Making sure everyone knows when it’s coming and that their hands are ready.
The Settling
The defense phase is real. When people feel their territory is threatened, they stop building and start protecting. Nothing moves until the walls come down.
When someone finally asks “what exactly do you mean by that?” and you get into the details, something settles. Not just relief, a kind of quiet. No one got steamrolled. No one walked away feeling pushed aside.
Misalignment isn’t usually disagreement. It’s people who haven’t yet realized they’re on the same side. And the PM’s job – the real job – is to hold the map steady long enough for everyone to see they’re headed the same direction.
If you’re sitting in one of these rooms (whatever seat you’re in) it might be worth noticing: Where are the walls? And who’s trying to bring them down?
Thank you
Thank you, Ksenia, for sharing strategies and insights for better collaboration between team members and teams!
Enjoyed This?
📩 Subscribe
❤️ Hit the heart
💬 Comment
🔁 Share
🌱 And help this newsletter grow!