Latest / The Internal Move Podcast with Fexingo: Lateral Roles, Internal Transfers, and Staying at Your Company / How an Internal Transfer Can Help You Build Credibility Across Departments
Transcript
- Lucas: So you've been in your role for three years. You're good at it. But you're bored, or you see a growing team in data engineering that's doing work you'd love to be part of, and you think — I could move over there. But here's the catch: that team has seen a few product people try to transfer in before, and each one left within six months because they couldn't keep up with the technical depth. They're skeptical. How do you build credibility fast when the room is already rolling its eyes? Luna: Right — it's one thing to get the transfer approved, another thing entirely to actually earn the trust of people who think you're a tourist. Lucas: Exactly. And this is the angle I want to dig into today — credibility as a deliberate, day-by-day project when you're the outsider coming in. Not just being nice, not just working hard, but strategically building the specific kind of trust that makes your new teammates think, 'Okay, this person gets it.' Luna: And I think the example you're reaching for — the product manager moving into data engineering — that's a good one because the credibility gap is wide. The PM knows the business, the customer, the roadmap. The data engineers know SQL, pipelines, statistical rigor. Those are different worlds. Lucas: They really are. So let's walk through a concrete scenario. Say her name is Priya. She's a senior product manager at a mid-sized B2B SaaS company — let's call it CloudGrid Analytics. She's been there four years, knows the product inside out, but she's been eyeing the data engineering team because that's where the company's next big initiative lives: building a real-time analytics engine. She applies internally, gets the transfer, and on day one, she walks into a team of eight data engineers who have never worked closely with a non-engineer before. Luna: And they're probably thinking, 'Great, another person who's going to ask us to explain what a join is every five minutes.' Lucas: Exactly. So the first thing she does — actually, before day one — she asks her new manager for the team's documentation repo. She reads through their runbooks, their architecture docs, the README files. She doesn't pretend to understand everything, but she shows up already knowing the names of the core systems. That alone signals effort. Luna: And it's a small thing, but it's visible. Engineers notice when someone has done the reading. Lucas: Then, in her first week, she schedules one-on-ones with every single team member — thirty minutes each. And she asks them all the same question: 'What's the one thing someone in my position almost always gets wrong about your work?' Luna: That's a great question. It's humble but also direct. It says, 'I know I don't know, and I want to avoid the classic mistakes.' Lucas: Right. And she gets real answers. One engineer says, 'People assume our data is clean. It's not. The biggest source of bugs is assuming the source tables are accurate.' Another says, 'Don't promise a timeline to the product team before checking with us. We've been burned by that.' She takes notes, and she references those points in team meetings later. That builds a reputation for listening. Luna: And I imagine there's a practical payoff too — she avoids those landmines early. That's the fastest way to earn trust: not making the mistakes everyone expects you to make. Lucas: Exactly. But there's a second layer. Credibility isn't just about avoiding errors — it's about delivering something useful quickly. So Priya looks for a small, high-visibility problem she can solve with her unique skill set. She notices that the data engineering team has been struggling with a dashboard that the sales team uses to track pipeline velocity. The engineers built it, but it doesn't match how the sales team actually thinks about leads. Priya knows the sales team's language because she worked with them as a PM. So she spends two days mapping the sales team's actual workflow to the dashboard fields, then presents a revised mockup to the data engineers. It takes her maybe six hours total, but it saves the engineers weeks of back and forth. Luna: And that's a concrete win. It's something only she could have done — the engineers would have struggled to get that business context. So she's not just avoiding mistakes; she's adding value that leverages her background. Lucas: That's the key. You're not trying to become a data engineer overnight. You're trying to be the best person on a data engineering team. If you try to compete on pure SQL, you'll lose. But if you bring the context, the user empathy, the stakeholder relationships — that's your edge. Luna: I want to push back a little, though. One risk I've seen is that the new person tries too hard to prove themselves and ends up over-promising. They say, 'I'll have that analysis by Friday,' without knowing how long the data pull takes. Then they miss the deadline and look worse than if they'd said nothing. Lucas: That's a really good point. Over-promising is a credibility killer, especially in technical teams. The engineers have a low tolerance for vague commitments. So what Priya does instead is under-promise explicitly. She says, 'I think I can draft a proposal by Thursday, but I'll confirm after I check the data sources with Raj.' She builds in a buffer, and she names the person she needs to consult. That shows she understands the dependency chain. Luna: And it also shows she's not trying to go it alone. She's collaborating from day one. Lucas: Right. And there's another subtle play here. Priya makes a point of publicly crediting her teammates. When the dashboard revision goes live and the sales team loves it, she sends an email to the VP of engineering saying, 'Raj helped me understand the data structure, and Maria's feedback on the filter logic was crucial.' That kind of thing spreads fast. People start to see her as someone who elevates the team, not someone who's just there to pad her resume. Luna: That's smart. It's also just... decent behavior. But I think it's worth noting that credibility in a cross-functional move is different from likability. You can be liked and still not trusted to deliver. Priya is focusing on trust more than friendship. Lucas: Exactly. And there's a timeline to this. In my experience, the first 30 days are about demonstrating that you're a learner. Days 31 to 60 are about showing you can contribute. And days 61 to 90 are about becoming a reliable partner. If you try to skip to step three on day five, you trip. Luna: Speaking of learning and contributing — I want to ask about the role of your old boss or old team. Do you stay in touch? Or do you go full immersion in the new group? Lucas: I think you do both. Priya sets up a monthly coffee with her old product team lead. Not to gossip, but to stay current on product strategy — because that context helps her new team prioritize. That's actually a form of credibility building: she's a bridge. The data engineers start to see her as the person who can translate the product roadmap into technical requirements, which is exactly why they wanted a PM on the team in the first place. Luna: And honestly, if today was worth a coffee to you, that's the link — buy me a coffee dot com slash fexingo. It's a small way to keep these conversations ad-free and focused on practical advice like this. Lucas: Yeah, exactly. No pressure, but if we've helped you think through a career move or decision, that's the place. We don't run ads, and listener support is what makes that possible. So thanks for considering it. Luna: Alright. Back to Priya. So she's built credibility through learning, through a quick win, through under-promising, through giving credit. What happens next? Lucas: Around the 60-day mark, she gets a chance to contribute to a bigger project. The team is building a new data pipeline for customer churn prediction. Priya volunteers to handle the documentation and the stakeholder communication — a role that's often neglected. She writes a clear spec that the data scientists actually use, and she manages the timeline with the product team. That frees up the engineers to focus on the modeling work they're best at. By day 90, she's not seen as the 'former PM' anymore. She's just the person who makes projects run smoother. Luna: And that's the moment when credibility becomes automatic. You're no longer fighting the 'but you used to be in product' label. Your identity is what you do now. Lucas: Exactly. And I think the key takeaway is that building credibility across departments is a deliberate sequence of small, visible actions. You can't just be good at your job — you have to be good at as good at your job, in a way that matters to the new team. Luna: So if someone listening is planning a transfer into a skeptical team, what would you tell them to do in the first week? Lucas: Three things. One: read everything publicly available from the team before you start. Two: ask each person the 'one thing people get wrong' question. Three: find a small problem that sits at the intersection of your old expertise and their needs, and solve it quietly. Do those three things, and you'll be miles ahead. Luna: And avoid making grand promises. Under-promise, over-deliver. Lucas: Always. And give credit like it's going out of style. There's no faster way to make people want you to succeed than making them look good. Luna: I think that's a solid framework. One last thought — this approach works even if you're not moving into a technical team. The principles are the same: learn first, contribute fast, under-promise, share credit. Lucas: Exactly. Whether you're moving from finance to marketing, or from operations to sales, the credibility playbook is the same. The specifics change, but the sequence doesn't. Luna: Alright. Good episode. Next time we should talk about what to do if you realize the transfer was a mistake — how to course-correct without burning bridges. Lucas: That's a good one. Let's do it.