Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Build Trust With Non-Technical Stakeholders
Transcript
- Lucas: There's this moment every engineer at a big tech company eventually faces. You've built something technically solid — clean architecture, solid test coverage, everything's reviewed. But the product manager looks at you with that blank stare and says, 'So, when will it be done?' And you realize you've been speaking in engineering time, not business time. Luna: Right, that gap. It's not about being wrong — it's about not being understood. And that misunderstanding erodes trust. Lucas: Exactly. So today I want to talk about something a lot of FAANG engineers overlook until it's too late: building trust with non-technical stakeholders. I've got a concrete case from a senior engineer at Google who turned a six-month project into six weeks just by reframing how she communicated trade-offs. Luna: Six weeks from six months? That's not just communication — that's a career move. What did she do differently? Lucas: She stopped talking about architecture and started talking about outcomes. Her team was building a new data pipeline for a product feature. The initial estimate was six months because there were multiple dependencies — a new schema, a migration tool, some legacy cleanup. But when she sat down with the product director, she asked: 'What do you actually need to see to launch?' It turned out they only needed a subset of the data to ship an MVP. The rest could come later. Luna: So she basically exposed the hidden optionality. Most engineers present the full solution as the only solution because that's the technically correct path. Lucas: Exactly. And that's the first rule of stakeholder trust: use the language of outcomes, not outputs. Outputs are the code you write — the schema, the tests, the deployment. Outcomes are what the business actually gets — 'we can ship this feature to 10 percent of users by next month.' When you frame it as outcomes, you give the stakeholder room to make trade-offs. Luna: But isn't that just good product sense? I mean, engineers get told to 'think like a PM' all the time. Why is this different? Lucas: Because thinking like a PM isn't enough — you have to signal that you're thinking that way. There's a second part to this. The Google engineer also used what she called a 'risk one-pager' — a single page that listed the top three technical risks, their probability, their business impact, and a proposed mitigation. She shared it with stakeholders before every big meeting. Luna: So she wasn't just translating — she was proactively surfacing the things that could go wrong. That builds a different kind of trust. It says, 'I'm not hiding anything.' Lucas: Exactly. And that's the second rule: surface risk early and visibly. A lot of engineers wait until something's broken to escalate. But by then, trust is already damaged. The stakeholder feels blindsided. If you share a one-pager every two weeks that says, 'Here's what we're worried about, here's what we're doing about it,' you're essentially giving them a dashboard for your judgment. Luna: I've seen that work in practice. There's a study from 2024 by a workplace analytics firm — I think it was called 'The Trust Premium' — that looked at promotion rates across FAANG. They found that engineers who scored in the top quartile on stakeholder trust were promoted to staff engineer at 2.3 times the rate of those in the bottom quartile, even when controlling for code output. Lucas: That's a striking number. 2.3 times — and it's not about coding ability. It's about perceived reliability. And that perception is built through these small, consistent signals: speaking in outcomes, surfacing risk, and doing it regularly. Luna: But let's push back a little. There's a version of this that sounds like 'just manage up better.' And that can feel like playing politics — especially for engineers who just want to build good systems. Lucas: I hear that. And I think the distinction is intent. Managing up is about making yourself look good. This is about making the project successful. When you surface risk, you're not protecting yourself — you're protecting the outcome. And stakeholders can tell the difference. They've been managed before. Luna: Fair point. So what does this look like day to day? Give me a concrete practice someone could start tomorrow. Lucas: Tomorrow morning — before you write a single line of code — write a one-paragraph memo titled 'So what?' Take your current project and describe it in terms of the business outcome it enables. Not the feature, not the tech stack, not the API endpoints. The outcome. Then share it with your PM or your lead and ask, 'Does this match your understanding?' That one exercise forces you to translate your work into stakeholder language. Luna: I like that. It's low risk — it's just a paragraph. And if you're wrong, you find out before you've invested weeks of engineering time. Lucas: Exactly. And if you get into the habit, you start to see your project differently. You start naturally thinking about what matters to the people who aren't reading your code. And that's the skill that gets you to staff engineer. Luna: Yeah, that's the real takeaway. It's not about being a better talker — it's about being a more complete engineer. Lucas: Completely agree. And honestly, if today's conversation gave you something you can use — maybe that one-paragraph exercise, or the two rules — that's exactly the kind of thing that makes listener support so meaningful for us. If it was worth a coffee to you, that link is buy me a coffee dot com slash fexingo. Luna: Yeah, and we keep the show ad-free because of that. So genuinely, it helps. Lucas: Alright. So let's take this a step further. How do you maintain that trust when things go wrong — because they always do? Luna: Right, that's the real test. Anyone can look good when the estimate holds. What happens when the pipeline breaks at week five? Lucas: The trust you've built by surfacing risk early gives you a buffer. If you've been sharing your risk one-pager all along, when something actually breaks, the stakeholder's reaction is 'Okay, we knew this was possible, what's the plan?' instead of 'Why didn't you tell me?' That's the difference between a fire drill and a managed escalation. Luna: So the one-pager is like an insurance policy. You pay the premium of writing and sharing it, and the payout is that when things go sideways, you don't lose credibility. Lucas: Exactly. And there's a second part: when you do have bad news, deliver it with a proposed solution. Not just 'the migration is delayed by two weeks.' Say 'the migration is delayed by two weeks, but we can unblock it by partnering with the data team to get a read replica, and I've already scheduled a meeting with them.' That signals ownership. Luna: That's a good rule. Don't just escalate — escalate with a plan. Otherwise you're just transferring the problem. Lucas: Right. And that's the deeper skill here. Building trust with stakeholders isn't a soft skill in the fluffy sense. It's a technical skill in the same way that writing clean code is a technical skill. It's about reducing cognitive load for the people who depend on your work. Luna: I love that framing. 'Reducing cognitive load.' That makes it concrete. You're not being nice — you're being efficient. Lucas: Exactly. So the next time you're in a planning meeting and someone asks when something will be done, try this: instead of giving a date, give a range and the biggest risk. 'Probably six to eight weeks assuming the API integration goes smoothly — if it doesn't, we'll know in the first two weeks and I'll flag it.' That's a signal of competence. Luna: And it sets realistic expectations. Which is the foundation of trust. Lucas: Exactly. So to recap: two rules — speak in outcomes, surface risk early. And one exercise — write the 'so what' memo. Do that for a month and see if your relationships with product and design start to shift. Luna: I'm going to try that myself. I manage a small engineering team, and I think I've been guilty of over-explaining the tech and under-explaining the trade-offs. Lucas: We all have. The good news is, it's a skill you can build. And it's one of the highest-leverage investments you can make in your career.