All of this advice here is ok as long as you work in a functional organisation. However it should be used strategically, sparingly and only when you have gained the trust of your superiors.

If you work in a dysfunctional organisation I would advise against ever using any of this advice. Any of this advice can be and in some circumstances is, used to discredit you, even if the outcome was successful. In a dysfunctional organisation you should concentrate on protecting yourself.

▲

Aurornis a day ago | parent | next [-]

I’d go further and say the advice in this blog is rarely the right move. It’s written for a context where everyone else is wrong except you, dear reader, who can see the true path forward.

It also appeals to people who think in false dichotomies, where your only two options are to do strong-headed moves like this or become a passive sheep who fails because your boss is bad.

In real businesses it’s rarely that simple. Using “dangerous advice” or becoming the “scary professional” as another influencer words similar advice sounds best when you’re imagining how the interaction will go and how much you’ll be winning when it’s done, but in a real business where things get done through relationships and trust it’s very easy to find yourself moving backward and being pushed out when using advice like this.

	▲	extraisland 21 hours ago \| parent [-]
		I've read some other posts on there. I agree the advice is dubious. There is a bunch of caveats to everything and he doesn't make it clear what caveats are. I know what those caveats are. However if you are more inexperienced you don't know what those are.

▲

jemiluv8 a day ago | parent | prev | next [-]

I couldn't agree more. Software engineering environments vary so wildly that you better respect your own context

▲

dcminter a day ago | parent | prev | next [-]

I don't think I agree; some of what's recommended here is what stops dysfunctional orgs from getting their shit together.

Plus every developer believes they're a special and insightful little petal so all the caveats will get ignored.

▲

extraisland a day ago | parent | next [-]

It is a Chesterton's fence type argument. You need to understand the rules, before you know which ones you can break and when you should break them.

> Plus every developer believes they're a special and insightful little petal so all the caveats will get ignored.

I don't believe that is true. I think there is a vocal minority of developers that would apply to.

▲

scarface_74 a day ago | parent | prev [-]

As Kosh said, once the avalanche has started, the pebbles don’t have a vote. Unless you are high up in the organization, you can’t change a dysfunctional organization.

It’s best to just leave.

Hell as the most recent CEOs of Intel have found, even if you are high up in the org, you often can’t change a dysfunctional organization.

	▲	tpoacher a day ago \| parent [-]
		Nice quote, totally stealing this.

▲

tom_m 20 hours ago | parent | prev | next [-]

No, some of that is horrible advice even at a healthy functional organization. You don't want to break rules silently, defiantly, or row in the opposite direction.

Leadership should be establishing cultural and communication norms. So if you have ideas, questions, concerns, for example - you don't need to break rules or work against the engineering org vision, culture, or process.

Mistakes and learning and being busy and lack of communication process aside... You should be expected to have a negative consequence for following some of this advice. It'd be well deserved.

Now, hopefully, you have some excellent managers who can help guide and support you...but if we have articles like this that kinda drive the behavior we don't want to see and people put more trust in random internet junk than they do their managers. That's a problem.

	▲	extraisland 16 hours ago \| parent [-]
		> No, some of that is horrible advice even at a healthy functional organization. You don't want to break rules silently, defiantly, or row in the opposite direction. Breaking the rules Silently/Defiantly is being a diva and that is no good. I've had to inform superiors that I disobeyed their instructions to get something done, I had a good reason for doing so (it wasn't at a whim). You should do this sparingly and only when you established that you are competent enough to make that call. Sometimes you do need to push back hard against people. I've had to call co-workers and have an unpleasant conversation because repeatedly didn't even check something compiled. I was fed up with it and my superiors had done nothing, it was stopping me from getting my work done. > Leadership should be establishing cultural and communication norms. So if you have ideas, questions, concerns, for example - you don't need to break rules or work against the engineering org vision, culture, or process. I've found that even in "(more) functional organisations" cultural or communication norms are typically broken or preformative. e.g. I worked in one org where there were things obviously broken on a website and no bugs were raised because "there wasn't a requirement for it". Now I could have raised it. I felt like they should of immediately raised it, because it was so obvious (it wasn't the first time either). I deliberately left it an entire fortnight on the site to see if any of the QA raised it. Nobody did. I then used this an example to highlight the fact that people weren't thinking. It was a various the old "teacher leaves a deliberate mistake in to see if the students are paying attention". I shouldn't have to resort to high school teacher tactics. Sometimes you have to be very disagreeable for people to take notice.

▲

scarface_74 a day ago | parent | prev [-]

The two worse pieces of advice in the article are breaking the rules and making your own decisions on what to work on.

Everyone including the CEO [1] has a mandate on what they are suppose to be working on. If you choose to work on something else without a mandate and the buy in of your organization, it has downstream and upstream effects you aren’t innovating, you’re being disruptive and not in a good way.

If you have an idea that you think is good, first you sell it internally and get buy in - either via a proof of concept or at least a decent write up or conversation - then you implement it.

From 2016-2018, my responsibility coming from the director was “we just got acquired by a PE firm and you are responsible for integrating these disparate systems of these companies that are being acquired. Let me know your plan and how many people you need”.

Even with a mandate that broad, I knew what rules couldn’t be broken or when I needed to ask for guidance from legal, finance, the CTO, etc.

I didn’t get to “make my own decision about what to work on”. I had broad categories of objectives and I could choose how to prioritize and took some latitude about what to “delegate to the floor”. But anyone who needs to read his advice doesn’t have the experience or professional maturity to know that. I didn’t early in my career and I have the PIPs to prove it.

The next company I also had a broad mandate. But that doesn’t mean I was going to “break the rules” and start putting workloads on Azure in an AWS shop or implement something using Postgres when we were a MySQL shop.

Fast forward to the present. I am a staff engineer working at a cloud consulting company. My responsibility is to either deliver implementation projects or your standard 40-50 page management consulting type reports.

I still have rules I know not to break even though I’m given really wide latitude about how I deliver - they still have to be done on time, on budget and meet the guidelines of the contract.

And the ends justifying the means doesn’t work at large companies. I worked at GE when it was the 6th most valuable company (where I overcame a PIP that was caused because I wasn’t politically savvy) in the US and later Amazon (AWS). With a lot of startups and small and medium companies scattered before and between.

[1] If the company has outside investors they are accountable to their boards and investors.

	▲	extraisland a day ago \| parent [-]
		> The two worse pieces of advice in the article are breaking the rules and making your own decisions on what to work on. If you read some of his other pieces that are linked. There is other dubious advice and analysis on that blog. > Even with a mandate that broad, I knew what rules couldn’t be broken or when I needed to ask for guidance from legal, finance, the CTO, etc. Yes I agree. There are rules that cannot be broken in the organisation. It is highly dependant on industry and the size of the business. I think there are times when you need to break the rules to get stuff done e.g. Self approving a PRs to get something working when someone else isn't around / available on a non-prod environment. I categorise that as a "bit naughty". I am assuming that is what they mean, but the haven't made that clear if that is the case. > I didn’t get to “make my own decision about what to work on”. I had broad categories of objectives and I could choose how to prioritize and took some latitude about what to “delegate to the floor”. But anyone who needs to read his advice doesn’t have the experience or professional maturity to know that. I didn’t early in my career and I have the PIPs to prove it. I have got hosed by acting like a maverick. You learn quickly you can't behave like that. > If you have an idea that you think is good, first you sell it internally and get buy in - either via a proof of concept or at least a decent write up or conversation - then you implement it. I work in a small org. I will at least talk to my superior if I am going to implement something that hasn't been agreed or take a significant detour.