Latest / The Promotion Memo with Fexingo: Getting Visibility, Sponsors, and Executive Presence / How One Employee Got Promoted by Creating a Cross-Team Project
Transcript
- Lucas: So we get a lot of questions about how to get promoted without explicitly asking for it, and a few episodes back we talked about how one person used internal data to make their case. Luna: Right, that was episode eleven. But today's angle is different — it's about creating a project that doesn't exist yet, across teams that don't normally talk to each other. Lucas: Exactly. And the person at the center of this is a mid-level engineer at a mid-size tech company — let's call her Priya. She worked in the platform engineering group, which built internal tools for other teams at the company. Luna: And she noticed something. What was it? Lucas: She realized that the customer support team was spending an enormous amount of time manually pulling data from three separate systems to respond to tier-two tickets. Each system had its own format, its own access protocol — and the support team had no engineering resources of their own. Luna: So she saw a gap between two silos. Platform engineering wasn't assigned to help support, and support didn't know how to ask for engineering help. Lucas: Right. And here's the key: instead of just building a quick script and handing it over — which would have been a favor, not a project — she went and talked to the head of customer support. She asked questions. How many hours a week does this take? What's the average ticket resolution time? How often do errors happen because of manual data entry? Luna: She built a business case before she wrote a single line of code. That's smart. Lucas: Exactly. And then she went to her own manager and said, 'I think I can save the support team about forty hours a week. That's roughly one full-time employee's worth of time. If I build an integration tool, we could redeploy those hours to higher-value work.' Luna: So she framed it as a return-on-investment conversation, not a side project. Lucas: That's the move. Her manager agreed to let her spend twenty percent of her time on it for three months. But here's where the promotion piece comes in: she didn't just build the tool and walk away. She documented everything. Luna: In what way? Lucas: She kept a log of the before and after metrics. Before the tool, average ticket resolution time for those tickets was forty-eight hours. After, it dropped to twelve. Error rate on data entry went from about eight percent to under one percent. And she measured the dollar value — the equivalent of about ninety thousand dollars a year in reclaimed labor cost. Luna: So she had hard numbers to point to. That makes the promotion conversation almost self-executing. Lucas: It does. But the other thing she did was build visibility across the organization. She presented her results to the head of support, who then mentioned it in a leadership meeting. The VP of engineering heard about it. She got invited to present at an all-hands. Luna: So she had sponsors in two different departments, not just her own manager. Lucas: Exactly. And when promotion cycles came around, her manager had a folder full of evidence — testimonials from the support team, the VP's notes, the quantified impact. She didn't have to ask for the promotion. The case was so strong that her manager brought it up first. Luna: Let me guess — she got promoted to senior staff engineer. Lucas: She did. And the tool eventually became a company-wide standard for cross-team integrations. She ended up leading a small team to build similar connectors for other departments. Luna: That's a great example, but I think a lot of people hear this and think, 'Well, my company doesn't have that kind of culture' or 'My boss would never let me spend twenty percent time on something like that.' Lucas: That's a fair objection. And the thing is, Priya didn't ask for twenty percent time upfront. She asked for one week to build a prototype. She built it on nights and weekends initially, then showed a demo. Only after she demonstrated feasibility did she ask for official time. Luna: So she de-risked the ask. Prototype first, then business case. Lucas: Exactly. And that's the playbook for anyone in a more rigid environment. You don't need permission to explore a problem on your own time for a week. You just need to be strategic about where you invest that week. Luna: That makes sense. And it ties back to something we've talked about before — the importance of looking for pain points that are visible but ignored. Lucas: Right. And one way to find those is to talk to people in roles you don't interact with regularly. Go have coffee with someone in customer support, or operations, or sales. Ask them what their biggest frustration is. Nine times out of ten, they'll tell you something that engineering could fix but doesn't know about. Luna: And if you can fix it and measure it, you've basically built your own promotion case. Speaking of which, if you've gotten value from episodes like this and want to help us keep making them, a couple of dollars a month is genuinely what keeps these going — buy me a coffee dot com slash fexingo. Lucas: Yeah, it really does make a difference. We don't run ads, so listener support is how we stay independent. And now, back to the strategy — because there's a subtle mistake a lot of people make when they try this approach. Luna: What's that? Lucas: They overstep boundaries. They start making promises to the other team without looping in their own manager. Or they build something that solves a problem but creates a maintenance burden that nobody asked for. Priya was careful to always keep her manager in the loop and to frame the project as an experiment, not a permanent commitment. Luna: So the key is to stay aligned with your own chain of command while building relationships across the org. Lucas: Exactly. And another mistake is not documenting the impact in the language that leadership cares about. If you say 'I reduced error rates,' that's fine. But if you say 'I reduced error rates, which saves the company forty thousand dollars a year in rework costs,' that's a promotion-worthy statement. Luna: So translate technical wins into business metrics. Hours saved, revenue protected, customer satisfaction scores. Lucas: Right. And one more thing: don't wait for the promotion cycle to start. Start building your case six months before. Priya's project was done in the first half of the year. By the time reviews came around, the results were old news — but the impact was still fresh in people's minds because she'd presented it multiple times. Luna: So the visibility wasn't a one-time thing. She kept the narrative alive. Lucas: Exactly. She gave a brown-bag lunch talk. She wrote a one-page summary for the engineering newsletter. She made sure the VP saw the numbers again right before promotion decisions. Luna: That's a lot of effort. But I guess if it lands you a promotion and a new team, it's worth it. Lucas: Absolutely. And the beauty of it is, once you've done it once, you know the playbook. You can apply it again in your new role. Priya later used the same approach to identify a gap in how the company handled compliance reporting — and that led to another project and another promotion. Luna: So it becomes a career habit, not a one-off tactic. Lucas: Right. The core skill is spotting disconnects between teams, quantifying the cost of that disconnect, and building a bridge. That's valuable at any level, in any industry. Luna: Alright, so for someone listening right now, what's the one thing they should do this week? Lucas: Schedule a coffee chat with someone in a department you don't normally work with. Ask them one question: 'If you could wave a magic wand and fix one process that slows you down, what would it be?' Listen for something that involves data moving between systems or people. That's your starting point. Luna: And if you don't have a coffee chat culture, send a Slack message or an email. Just start the conversation. Lucas: Exactly. The next Priya is out there, and she's probably reading this right now. Go be that person.