Should be proactive or reactive?

[Vis Deo]

How many times have you regret being proactive?

You are a developer, all leads (business, analyst and tech) had reviewed, approved & designed the implementation, and you raise concern, find the fault and proactively raise it.

The reaction from team - not at this time, or how come, as lead or approver I didn’t catch it, Most of the reactions are unpleasant.
If this feature goes into production without catching and critical problem occurs, the person who solves is appreciated more.

From this I always feel, I need to be reactive than proactive. What do you think?

[Ulf Dittmer]

I guess it depends on what "concern" and "fault" mean. A concern could be valid or invalid; a fault sounds like something that should be fixed. Even then, a suboptimal or faulty design may still result in a working software (which may be more important than a software with a perfect design).

You need to learn how to handle people. Some people take (perceived or real) criticism the wrong way; a lot may depend on how you raise it - publicly or privately, constructively or destructively.

That said, proactive is generally better than reactive. If the culture in your company, or maybe just individual key people, persistently react negatively to dissenting opinions, you may want to look elsewhere for professional contentment.

[Jeanne Boyarsky]

It's a mix. Sometimes is is "unpleasant" to be proactive. However, being reactive on purpose isn't the right thing to do. Someone else will have a problem later because of not bringing things up. It could be as "little" as working late or as big as something that as a financial or reputation cost to the company. I'd rather have a reputation for bringing things up proactively.

I'm surprised your company doesn't do a finger pointing exercise after the critical production problem. Many do.

[chris webster]

Your example seems pretty clear to me: It is your duty to raise a genuine concern at the earliest opportunity, because it is your job as a team to deliver the best solution possible within the constraints of your project. If your colleagues feel there is no problem or decide to ignore the issue, that's their responsibility, not yours, and they should be prepared to answer for their decision later on.

Similarly, you should be prepared to answer for your decision to conceal an issue that you knew about before the code went into production, in the apparent hope you will get more credit for fixing it later on. Your suggested approach sounds like somebody who starts a fire so he can be praised for putting it out later on. Do you think anybody really wants to work with people like that?

If you can see a problem that your colleagues appear to have missed, it is your job to raise the issue in a constructive manner. If possible, try to have a suggested solution or at least some questions that you can all work on to find the solution. If it turns out they knew about the problem all along, then no harm done - and you may impress people with your problem-finding ability and responsible approach. If they missed it, they now have an opportunity to fix it or at least add it to the list of things to fix in the next release.