Pitch to the People Who Decide

You’ve spotted a real problem - a genuine, strategic, this-will-bite-us-in-a-year problem. So you do what feels natural: you raise it in your team’s engineering meeting.

The response is polite indifference. “That’s out of scope for now.” “Let’s just finish what we’ve got.” A couple of people nod. The meeting moves on.

You come away deflated, half-convinced the problem isn’t real. It probably is. You’ve just pitched it to the wrong room.

The Team Doesn’t Decide

Many engineering teams do not choose what they work on. Someone above them does - a lead, a head of product, a director. The team’s job is to execute well on the thing that’s been chosen.

So when you take a new problem to the team, you’re often asking people to engage with something they have no power to prioritise. Of course they shrug. Even if every one of them agrees with you, the best they can offer is “yeah, that does sound like a problem”. They can’t say yes. They can only say “not now”, because “not now” is the only answer available to them.

That’s not a criticism of the team - it’s just how decision power works. And it’s why “out of scope” should never be heard as a verdict on whether your problem is real. It’s a statement about who you’re talking to.

Find the Decider

So who do you pitch to? The person who decides what the team works on. The person whose signature actually changes the roadmap.

This feels presumptuous when you’re a mid-level or newly-senior engineer. It isn’t. It’s the entire difference between executing and leading. Executing is doing well on the thing you were given. Leading is saying “this is important, here’s why, and here’s what I think we should do about it” to someone who can act on it.

You don’t need a title to do this. You need a problem framed in the decider’s terms, and a solution they can understand.

Frame It in Their Terms

The decider doesn’t care that the architecture is awkward. They care about the thing the architecture is stopping them from getting.

So don’t say “our architecture doesn’t scale”. Say “every new opportunity in this area has to queue behind a single team, so we’re leaving most of them on the table - here’s roughly what that’s costing us.”

Give them a number if you can. Give them the strategic angle: “we could make this one team faster, or we could make it so other teams can build for themselves. The second option is the one that compounds.”

Now they’re not being asked to understand your codebase. They’re being asked to choose between two business outcomes. If you need help getting there, I’ve written a whole guide to speaking their language.

Validate Before You Write the Novel

Before you write the twelve-page proposal, have a conversation. Does the decider see the problem? Have they already deliberately deferred it for reasons you don’t know about? Is it already on their list for next quarter?

Any of those answers is fine, and each one gives you a next move:

• “Yes, it’s a problem” - write the proposal.
• “We’re doing it next quarter” - “Would you like me to prepare a document?”
• “We’ll get to it eventually” - “I’ve got some ideas. Come back to me when you’re ready.”
• “No, and here’s why” - you’ve just learned something about how the business prioritises. That’s valuable too.

Expect to Feel a Bit Alone

When you start doing this, rooms will feel strange. You’ll say “I think this is important” and everyone around you will give you the blank stare of people who haven’t been told to care.

That isn’t a sign you’re wrong. It’s a sign you’ve found a gap where leadership should be. It’s uncomfortable - growth usually is - but someone has to be the one who says “this matters” before anyone has given permission.

Make it you. Then go and find the person who can say yes.