There are pull jobs and then there are push jobs.

In a pull job your work starts when someone asks. Someone needs data, analysis, approval, context, a deck, a bug fix, a report. And they pull it from you. You respond. You check the box.

In a push job you create forward motion without waiting to be asked. You ship the code. You make the decision. You write the update before someone chases you for it. You spot the problem, frame it, and make progress on it without anyone following up with you.

Pull jobs can still be valuable. Plenty of important functions are structurally pull-oriented. Support tickets, compliance reviews, certain reporting cycles. They keep the machine running. But they usually have a ceiling.

If your contribution only appears when someone remembers to ask for it, your leverage stays limited. You become a function people call when they need something. An API endpoint.

While Push jobs compound. They change the pace of the team. They reduce coordination cost. They create momentum others can build on. When someone writes the spec before the planning meeting or fixes bugs without being asked, they don’t just do their job, they make everyone around them faster and better too.

A real example: You have an analyst who is extraordinary at pull work. Ask for a revenue breakdown by cohort and you’d get a perfect sheet in thirty minutes. But that analyst never once comes to you and say, “Churn is spiking in this segment. Here’s what I think is causing it. Here are three things we could test.” An analyst who pushes vs pulling is 10X more valuable.

The question you should be asking yourself: is your work shaped by demand, or are you creating movement? And if it’s demand, is that because of your role, or because of you?

That answer tells you a lot about your ceiling.

(A senior engineering leader at Gojek first shared this framework, and it has stayed with me.)