Latest / The Career Change Podcast with Fexingo: Switching Fields, Bootcamps, and Reskilling / How Bootcamp Grads Can Communicate With Stakeholders
Transcript
- Lucas: So last week I was talking to a hiring manager at a Series B e-commerce startup, and she mentioned something that surprised me. She said the number one skill she looks for in bootcamp grads isn't coding speed or even system design — it's the ability to explain what they're building to someone who doesn't write code. Luna: That actually makes a ton of sense. At a Series B, you're probably working directly with product and operations folks who just want to know if the feature ships on time. Lucas: Exactly. And for bootcamp grads especially — you're often coming from a different industry, so you might already have that muscle from your previous career. But the tech context adds a whole new layer. Today I want to focus on one specific scenario: you're a junior data engineer, and you have to tell a product manager that a pipeline is going to be delayed by two weeks. How do you have that conversation without sounding defensive or vague? Luna: Okay, I can already feel the anxiety. What's the first mistake people make? Lucas: They lead with the technical reason. They say something like 'The ETL job is failing because of a schema mismatch in the source system, and the transformation layer needs a rewrite.' The product manager's eyes glaze over. They don't care about ETL or schema mismatches — they care about the launch date and the revenue forecast tied to that feature. Luna: So the fix is to start with the impact, not the cause. Lucas: Exactly. You lead with the 'so what.' So a better opening is: 'The recommendation engine feature will be delayed by two weeks. Here's what that means for the Q3 launch timeline, and here's what we're doing to minimize the impact.' Then, if they ask why, you give the technical detail in one sentence. The rule is: business impact first, technical cause second. Luna: I like that. And it builds trust because you're not hiding the delay — you're owning it and showing you've already thought about the consequences. Lucas: Right. And there's a second part to this: the one-number summary. When you're giving a status update, pick one number that captures the essence. For example, 'We've completed 70 percent of the data migration, but the remaining 30 percent is more complex because we're dealing with legacy records that need manual mapping.' That gives the listener a concrete anchor. Luna: So instead of saying 'we're making good progress,' you say '70 percent done, but the last 30 percent is harder.' That's actually actionable. Lucas: Exactly. And the third piece is what I call the 'jargon detector.' Before any meeting, review your message and replace every piece of technical shorthand with plain English. 'API endpoint' becomes 'the service that sends customer data.' 'Latency' becomes 'how fast the page loads.' 'Throughput' becomes 'how many orders we can process per minute.' Luna: That feels obvious, but I bet people skip it because they're used to talking to other engineers all day. Lucas: Exactly. And the risk is that you sound like you're speaking a different language. The hiring manager I spoke with said she's had bootcamp grads who were technically strong but couldn't get buy-in from stakeholders, and that ultimately hurt their career growth. She actually shared a framework she uses: before any cross-functional meeting, write down the one thing you want the listener to remember. If it's longer than one sentence, you're not ready. Luna: That's a good litmus test. So for the delayed pipeline example, the one thing might be 'The feature is delayed by two weeks, but we're adding an extra engineer to hit the revised date.' Lucas: Perfect. And then you back it up with details only if asked. Let's talk about a real case. A friend of mine — let's call her Priya — graduated from a data science bootcamp last year. She joined a mid-size fintech company as a junior data engineer. Three months in, she had to present to the VP of Product on a dashboard project that was behind schedule. Luna: Oof. That's a high-stakes audience. Lucas: Right. Her first instinct was to explain that the data warehouse had a schema change that broke her queries. But she took a step back and reframed it. She said: 'The customer churn dashboard will be ready two weeks later than planned. The good news is that we now have access to a richer dataset that will give us more accurate predictions. I've updated the timeline and I'll send a revised delivery date by end of day.' Luna: That's brilliant. She turned a delay into an upgrade. She didn't hide the bad news, but she reframed it as a trade-off, not a failure. Lucas: Exactly. And the VP's response? He said, 'Thanks for the heads-up. I appreciate the transparency. Let me know if you need any help prioritizing resources.' That's the outcome you want — you want to become the person they trust with bad news because you handle it professionally. Luna: So stakeholder communication is really about managing expectations and building credibility over time. It's not about being a smooth talker. Lucas: Exactly. And there's a specific technique that helps with that: the 'before and after' summary. When you present a project update, frame it as what the stakeholder should have expected before, and what they should expect now. That makes the change explicit. For example: 'Previously, we expected the dashboard to be live on July 1st. After the schema change, we're now targeting July 15th. The extra time allows us to include a new churn prediction model.' Luna: That's clear and direct. No ambiguity. And it shows you're tracking the change, not just reacting. Lucas: Right. And one more thing — the follow-up email. After any meeting where you've communicated a change, send a brief email summarizing what you said. This does two things: it creates a paper trail, and it gives the other person a chance to catch anything they missed. Keep it to three bullet points max. Luna: And that's especially important for bootcamp grads who might not have a reputation yet. You want to be known as the person who communicates clearly, not the person who disappears into a coding cave. Lucas: Yeah. And look, this is a skill you can practice. Before your next stand-up or status meeting, write down your update in one sentence. Then read it out loud. If it sounds like jargon, rewrite it. After a few weeks, it becomes automatic. Luna: I think this is actually one of the most underrated skills in tech. I've seen brilliant engineers get passed over for leadership roles because they couldn't communicate with the business side. Lucas: A hundred percent. And that's exactly why we wanted to do this episode. If you're a bootcamp grad, you already have the drive and the technical foundation. Adding this communication layer makes you much more valuable to any team. Luna: Speaking of valuable — if this show helps you think through career moves, we really appreciate the listeners who support it. It's what keeps the podcast ad-free and focused on practical advice. Lucas: Yeah, if you find these episodes useful, you can support us at buy me a coffee dot com slash fexingo. That's buy me a coffee dot com slash f-e-x-i-n-g-o. No pressure — just if you want to help keep the show going. Luna: And we mean that. Every bit helps, but the main thing is that you're here learning. So back to stakeholder communication — what's one exercise our listeners can try this week? Lucas: Pick a project you're working on right now. Write a one-sentence update that a non-technical stakeholder would understand. Then rewrite it to include a single number. Then practice saying it out loud. Do that every day for a week, and you'll be amazed at how much more confident you sound in meetings. Luna: That's a solid takeaway. Thanks, Lucas. And thanks to all of you for listening. We'll be back next week with another episode. Lucas: See you then.