A reader asks: I'm told to be proactive, but get snapped at when I try

The question (paraphrased from r/cscareerquestions):

My manager keeps telling me to “be more proactive.” But every time I actually try — pick up a ticket, suggest a change, bring an idea to standup — I get low-key snapped at. Last week I rewrote a config file because I thought it would help and my tech lead called it “unnecessary work.” Two weeks ago I proposed a refactor at a planning meeting and got a terse “let’s not go there right now.” What am I supposed to do? It feels like a trap.

It’s not a trap. It’s a miscalibration.

When a manager says “be more proactive,” they almost never mean “do more stuff without asking.” They mean: “anticipate more, communicate sooner, own the ambiguous parts.”

Those are almost opposite behaviors. The first is taking action. The second is surfacing judgment. If you’re pattern-matching “proactive” to the first one, you’re going to keep stepping on landmines.

The two kinds of proactivity

High-signal proactivity — the kind that gets you promoted:

• Flagging a risk before it becomes a problem (“I noticed X looks fragile — want me to look into it?”)
• Bringing a recommendation when you surface a question (“I think we should do A. Here’s why. Want me to proceed?”)
• Closing loops on the ambiguous pieces of a project. Notes, recaps, decision confirmations.
• Asking better questions earlier in a project, not at the deadline.
• Offering to help with a visible team priority.

Low-signal proactivity — the kind that feels productive but creates friction:

• Unilateral code changes or doc rewrites outside your scope
• Ideas introduced mid-meeting with no prior context
• Process suggestions in your first 60 days
• Scope expansion on tickets you didn’t own
• Refactors nobody asked for

Both feel like initiative. Only one reads as judgment. The difference is whether you asked before you moved.

Why your tech lead snapped about the config rewrite

Probably not because the rewrite was wrong. Because you:

• did it without context about why the config was the way it was
• did it without context about who might be affected downstream
• did it at the wrong time in the review cycle
• committed them to either defending your change or unwinding it

That’s three hours of their week that came out of your one hour of “being helpful.”

The fix isn’t to stop suggesting things. It’s to front-load a 60-second conversation:

“I noticed the config file is inconsistent and it’s slowing me down in the [X] area. Would it be useful if I spent an hour cleaning it up? I don’t want to create a rabbit hole.”

Now the answer is either “yes, please” (you’re a hero) or “hold off, that file is load-bearing in ways you don’t see yet” (you avoided a landmine). Either way, you look thoughtful.

Why the refactor proposal in the planning meeting landed badly

A planning meeting is not a brainstorm. It has a narrow agenda and a deadline. When you drop a new idea in, you’re asking the room to either take it seriously (which burns time they didn’t budget) or table it (which makes you look off-topic).

The move: propose the refactor before the meeting in a Slack to your tech lead.

“I’ve been thinking about the [X] area — I think there’s a small refactor that would save us time long-term. Want to talk about it before planning, or should I write up a one-pager you can look at offline?”

Now your idea has a champion before it enters the room. If your lead says “write it up,” the planning meeting becomes the place where they advocate for it — with your name on it.

The two-sentence test before you act

Before any proactive move, ask yourself:

1. Do I have the full picture of why things are the way they are?
2. If I’m wrong about why, is this reversible in under an hour?

If you can’t answer yes to both, ask before you act.

That’s not timid. That’s senior. The most senior people on a team are the ones who move slowly on things they don’t fully understand, and fast on things they do.

What to actually do more of

These will get you rated “proactive” on your next review with zero landmine risk:

1. Send a Friday recap. Five lines. What shipped, what’s next, what’s at risk, one question, one ask. Takes 10 minutes.
2. Flag risks early, in writing. “Heads-up — X might slip because of Y. I’m handling it by Z, but wanted you to know.” That line is career gold.
3. Take notes in meetings, send action items after. This gets noticed at a comical rate.
4. Bring recommendations, not questions. “I think we should do A because X. Any objections?” instead of “What should we do?”
5. Close the loop on things vaguely assigned to the team. If nobody owns a follow-up, grab it.

None of these require you to make a unilateral change anywhere. All of them read as “proactive” in a way your manager can articulate at review time.

The line to steal

In your next 1:1:

“You’ve mentioned a few times that you’d like me to be more proactive. Can you give me one or two specific examples — either from me, or from someone on the team you think does it well?”

You’ll get one of two answers. A specific example (great — now you know what to aim at). Or a vague “you know, just… take more initiative” (also useful — your manager doesn’t have a clear picture, and vague feedback won’t hurt you if you nail the five things above).

—

The asymmetry is brutal: a single unilateral move that backfires can erase weeks of well-built credibility, while six clean Friday recaps in a row build a reputation that survives most everyday mistakes. Optimize for the boring high-floor moves. The flashy stuff will come, and when it does, you’ll have the credibility to actually land it.

For the rhythm that makes “proactive” visible without the landmines, use the Status update template. For the meeting structure where the calibration conversation lives, use the Manager 1:1 agenda.

—

If you have a question like this, send it in. Anonymity guaranteed.