Know how your org works, or how to become a more effective engineer

I think the bit about informal hierarchies deserves some expansion. It's worth keeping in mind they're often not even hierarchies, they're graphs/networks.

The most effective type of leadership is not by authority and forcing people to bend to your will; it's by prestige and people paying attention to what you do because they respect you, and you have a good track record of improving their productivity, be it with suggestions, mentoring, explicit training, choosing a direction, or something else.

The directed, graph-like nature of these relationships mean that even as the most junior intern, you can usually find at least one other person who you help become more productive. And then you can slowly accrete more people you help be more productive, and eventually you'll find a large number of people agree you're a leader.

That type of leadership is available to everyone, and it's a fast track to being more productive as an individual, through the transitive closure of the improvements you can drive with the help of others.

You have got to really love a company to be willing to be promoted within it, given that it seems to take longer (as you can be hired for potential, but they want proof for promotion), suppresses your compensation, and requires learning politics.

This is a really good post that every engineer should read, especially early on in their career. I spent a lot of mine butting my head against a wall, and getting nowhere because I thought that soft skills and understanding organizational politics (not necessarily participating in them) weren't super important as long as you were good at the primary work of building software.

This post articulates exactly why those things are important and furthermore exactly how to pursue acquiring them in the right measure to get things done in your org. Brilliant stuff.

Funnily enough, Medium has a bug with Firefox on Android that doesn't show me what the "controversial statement" was, it's just a white box. From comments here I gather it is no great loss.

This could make for an interesting question to ask when interviewing. "I want to drive some contrived project that will impact multiple parts of the company. How does one build alignment for this sort of project, and how are projects like this usually managed?"

There is a large problem with the entire premise of this article.

Anyone who has been at enough companies know that companies "work" in very different ways over time. People with seniority, and leaders at all different levels of the informal hierarchy change how those companies work.

An alternate interpretation of this article is: "if you find yourself nodding with this article, know that you too have the personality of a follower of the system and will probably never impact the system yourself."

I think it is telling that in this exceptionally long set of bullet points, almost nowhere does the author have a perspective of the end user or goals of the software.

Aside from the ambiguous "get stuff done" and the bullet point around learning from past failures, every piece of advice is internally-focused. "Here are the best way to get those TPS reports done." "How to leverage the experience of the best TPS report creators." "How to understand the TPS report process in your company." etc.

Never once a comment on the analogous "should we be doing TPS reports?"

Effective engineers, as per the title of the article, are those able to build software that does the right stuff. It fundamentally isn't about whether or not work was able to be accomplished within the constraints of a company. (What if the company's structure is dysfunctional and you adding yet another checkbox is killing the product?)

Likewise, the insistence that ICs don't need to worry about these larger concerns because managers will is misplaced: every time an IC reinforces a dysfunctional structure, it makes it just that much harder for managers or more senior technical ICs to reform anything.

Please ban these type of articles from HackerNews. Has no substance whatsoever. It's like reading news articles written by bots.

I started hating on these kind of articles. They notice a problem with a subset of people and generalize to the whole when in fact another subset might be in the exact opposite situation and would benefit from the inverse advice.

True, I met a lot of engineers dreaming about the perfect organization. They take social media utopia ideas about IT and compare them to reality.

But it also true that people learn to game a broken system without realising they are doing no service to themselves or the org. And when that system breaks and the org fails they find they spent years only getting better at a special case of doing things wrong and are basically unhirable somewhere else. I get a lot of those in the interviews I hold.

On another hand people that really tried to fix the orgs - not just complain on twitter - gain valuable experience even if they fail in doing the saving. They learn from mistakes that are being made and will take steps to avoid letting other orgs start on wrong paths if given the chance.