Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Build Influence Without Authority
Transcript
- Lucas: So there is a question that comes up in almost every coaching conversation I have with mid-level engineers at FAANG — 'How do I get people on other teams to care about what I think?' And the honest answer is, you don't. Not directly. You don't make them care about you. You make them care about the problem. Luna: That is a big shift from how most engineers think. We're trained to believe that being right is enough. Lucas: Exactly. And it's not. I want to tell you about a specific engineer I worked with at Google a couple years ago — let's call her Priya. She was a senior engineer on the infrastructure side, and she needed to convince six different product squads to migrate off an old logging framework that was costing the company about eight hundred thousand dollars a year in unnecessary compute. Luna: Eight hundred thousand is real money. But that's company savings, not team savings. So why would any of those six squads volunteer to do extra work? Lucas: Exactly the problem. Priya had no authority over those teams. She wasn't their manager, she wasn't their tech lead. All she had was a conviction that the migration was the right thing. So she did something really smart: she spent two weeks just talking to people. Not pitching. Listening. Luna: Listening to what, exactly? Lucas: She asked each team lead two questions. One: 'What is the biggest headache you deal with every week?' Two: 'If you could wave a magic wand and change one thing about our infrastructure, what would it be?' And what she found was that three of the six teams were already frustrated with the old logging framework — it was slow, it was unreliable, it was generating false alarms in their on-call rotations. They just didn't know they could do anything about it. Luna: So she connected her agenda to their pain. That is influence without authority 101, but most engineers skip the listening step. Lucas: They skip it because they think the hard part is the technical solution. Priya already knew the solution — the new framework existed, it was tested, it was cheaper. The hard part was getting six busy teams to agree to a migration timeline. So she wrote a one-pager. Not a twenty-slide deck. A single page with four sections: the current situation, the cost of doing nothing, the proposed timeline, and a space for each team to write their concerns. Luna: She left a blank space for concerns? That's almost like a permissions to disagree move. Lucas: Exactly. She sent it to the six leads with a note: 'I'd love your feedback. If this doesn't work for your team, tell me what would need to change.' And because she had already done the listening, the one-pager reflected their language. She quoted their own complaints back to them. 'Team A reported that logging delays are causing incident response slowdowns.' That's not Priya's problem. That's Team A's problem, and she's offering a fix. Luna: So the one-pager does the arguing for her. She doesn't have to defend the idea because the document already addresses the objections. Lucas: Right. And the result was that within three weeks, all six teams signed on to a staggered migration. Some started earlier, some later, but everyone committed. The whole project finished under budget and the company saved about six hundred thousand dollars in the first year alone. Luna: That's a great story. But I want to push back a little — this works at Google, where the culture values data and one-pagers and async communication. What about at a smaller company, or a place where the culture is more top-down? Lucas: I think it works even better at smaller companies, because there's less bureaucracy. Let me give you a counter-example. A friend of mine — let's call him David — was a mid-level engineer at a B2B SaaS company with about two hundred employees. There was a project that had been running for eight months, called Project Phoenix. It was supposed to modernize the billing system. It was going nowhere. Luna: A zombie project. Everyone knows it's not going to ship, but no one wants to kill it. Lucas: Exactly. David was not the tech lead on the project. He was a contributor. But he started doing the same thing Priya did — he spent a week interviewing the stakeholders: product, sales, customer support, engineering. And he found that the reason the project was stalled wasn't technical. It was that the original scope was too ambitious and no one had the authority to cut scope. Luna: So he didn't try to become the scope-cutter. He just surfaced what everyone already knew. Lucas: Right. He wrote a one-pager titled 'Options for Project Phoenix' with three paths: full scope in eighteen months, reduced scope in six months, or cancel and reinvest the team elsewhere. He sent it to the VP of Engineering with a note: 'I talked to ten people. Here's what they said. I think option two is the best, but I'd love your read.' The VP read it in ten minutes and made a decision that same week. They went with option two. Luna: And David got no formal promotion from that, I assume. But he gained credibility. Lucas: He gained enormous credibility. Six months later, he was asked to lead a new initiative. That's the real return on influence without authority — it compounds. Every time you successfully align people on a shared problem, people trust you with bigger problems. Luna: So what's the practical takeaway for someone listening right now? If you're a senior engineer who wants more influence, what's the first step? Lucas: Pick one cross-team decision that you want to influence this quarter. Not a huge one. Something modest. And then spend a week just listening. Don't propose anything. Talk to the stakeholders — at least five people from different teams — and ask them what their biggest headache is related to that topic. Write down their exact words. You'll find that your proposed solution either already matches their pain, or you learn something that changes your approach. Either way, you win. Luna: I love that. It's almost like the opposite of the stereotypical engineer move — instead of jumping to solution, you sit in the problem space longer. Lucas: Exactly. And here's a quick honest thing — a handful of listeners chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what funds making shows like this. No ads, no sponsors, just people who find the content useful. If you've gotten something out of these episodes, that's the way to keep them coming. Luna: Yeah, it's a small group that makes a big difference. And it keeps us free for everyone. Lucas: So back to the listening step — once you've done that, write a one-pager. Keep it to one page. Use their language. Leave space for disagreement. And send it with a request for feedback, not approval. That's the key move: you're not asking for permission, you're asking for collaboration. Luna: And if someone says no, what do you do? Lucas: Then you've learned something valuable. Maybe the timing is wrong, maybe the problem isn't as painful as you thought, maybe you need a different ally. Influence without authority is a long game. No single 'no' kills it. You just iterate. Luna: Alright, I'm going to try this myself. I have a cross-team thing at my own company that's been bugging me. I'm going to spend next week just listening. Lucas: Let us know how it goes. And for everyone else — pick one problem, talk to five people, write one page. That's it.