[ozataman]

In further support of these points... Thinking outside the box, breaking the rules as a last resort to do the right thing and other similar actions can indeed produce the extraordinary results, in certain situations, the organization is hoping for after all. Yet this strategy will work only for the very top performers: Those who can sense and actually produce the truly largest "contribution" to their company (as opposed to what seems right, interesting or cool to them), even when it more or less eludes their higher ups; those who can do this while also being politically savvy enough to contain the consequences and sell their actions as actually in line with everyone's goals; those who are almost magical in being able to produce the kind of results others are very unlikely to do etc. It can work, I've seen it work, but I think it is important to realize that not everyone can or should do it. When it works, it is certainly a great boon to the career of the said top performer.

Know that by doing this, you may be counterproductive both to your organization and your career. If you take it to the extreme, you may become a friction rather than a "problem solver".

The most common pitfall I've seen is a highly technical person considering things like "refactoring", "getting it right" more important than getting to the finish line fast. Remember that you may be missing what's really the most important thing for your company at the time.

I've also seen commonplace "complaining" about inconveniences that are actually quite legitimate. It's just that you don't know all the facts or haven't been put in a position to produce the bottom-line results. Things look different when you're the one navigating the ship.

OTOH, I've seen this strategy work best when the very formal scope/objectives/deliverables of an effort are clearly wrong and would indeed lead to a subpar outcome for all involved. Implemented successfully, this strategy could produce outstanding results by forcefully course-correcting and then actually delivering great results. Remember though that you'll be blamed for everything if your course-correction isn't great, even if the original direction would also have been equally bad.

[daemin]

I always think that whenever a new rule or procedure gets created there should be sufficient reasoning as to why it had been created, what conditions prompted it, and what it's designed to solve.

With that information people can see why something needs to be done a certain way, and additionally they will know when rules and procedures should be eliminated. In my mind this would allow people to deduce when exceptions to the rules are applicable, and hence be more effective.

Unfortunately I have not actually seen this happen in real life.

[tomjen3]

Googles coding guidelines does exactly that, I imagine because they would otherwise spend too much time debating them over and over again.

[joefiorini]

At an earlier point in my career I was exactly the "highly technical person" in the above comment. I have always taken the approach to my work outlined in the OP, and therefore my emphasis on "getting it right" has caused me to switch jobs quite a bit over the past few years.

For people like me, understanding business constraints is crucial. We must constantly question decisions, not to condescend, but to understand.

Once I understand the context behind a decision, I can then decide if I agree with it or not. If I don't, then I'm in a fight-or-flight situation: try to change it (may not be a reasonable option) or get out as soon as my commitments allow.

Typically once I understand the constraints I start to less like a cog and more like part of a larger effort to ship in spite of our difficulties.

[tracker1]

That is where experience comes into play.. Knowing when to replace, rewrite, refactor, or hold your nose to get something done.