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.
Changing companies to become promoted starts petering out once you reach sr and if you want to become a manager, your often not hired as a manager directly without any previous management experience.
But anecdotally from friends and colleagues, that wall is a place with extremely generous compensation anyway, past the point where more money is all that life changing.
Because the hot market for software developers won't last forever and for those that don't know how manage that aspect of their career when future downturns come, well, life's going to be rough, very rough.
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.
The weird thing is that it has an iframe that doesn't load, but the text is right there in the frame title in the parent document:
> "You can either complain and pontificate on Twitter on how the tech industry should ideally work, or you can learn how your org really works and what's rewarded, and optimize for that. Or quit and find another job. This might sound cynical - but it's what it is."
Given that the parent document had the text already,
they didn't really need the frame.
They could just show the text.
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."
Esp. at most early/midscale startups, the culture of work is pretty much defined by a small subset of folks who lay down the "rules of the land" and it's very much possible for people to be part of that subset. However, the systems at play don't always make it straightforward to do so. Weirdly enough, this is probably why:
1 - Many early stage employees feel disillusioned as the company grows because they go from being part of a flat structure to being part of a mid-low level informal/formal hierarchy, esp. as more external folks are brought in and the style of work revolves more and more around the ideas they bring (It's very hard to avoid this, esp. if you are in a junior role)
2 - Companies can seem entirely different with changes in far fewer roles than you'd expect. A few high profile exits can lead to a snowball effect, but in a few quarters the company usually tends to recover, albeit with a style of work that the older folks would find alien, but the newer folks adopt quite readily. A great example of this is Basecamp. Yes, Basecamp today is very different to the company it was a year ago culturally, but I'm wholly unsure if that is good, bad or just the nature of the game.
> Companies can seem entirely different with changes in far fewer roles than you'd expect.
I have seen this as well.
I've also noticed this occur because certain roles are able to create unofficial networks in the organization and entirely auxiliary systems, independent of how the organization "works" on paper. I've seen this across all departments and all levels of seniority: from the highest to the lowest. They're the black markets of the economy to borrow an analogy.
I consider them the most effective and the real leaders (with or without title), as they change the scope of what is possible.
>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."
Why can an individual not make an impact unless they change the system or demonstrate that they are not "a follower"?
My issue is that this article emphasizes how to go with the flow of an existing system. It also implies that changing the system is outside the reach of ICs.
Not only do I believe partially changing the system is not outside of the realm of ICs, I've rarely seen successful engineers who didn't do it when necessary. If an engineer only feels comfortable changing the system when they're promoted into an official title, they are still operating on the tracks laid down by others. They'll be incapable of altering fundamental flaws or making fundamental improvements.
More specifically here, I think the apologia for this very specific (and exhausting!) list of procedures for how to navigate company politics indicates not just a specific career on autopilot, but a whole company on autopilot. I can't imagine an environment like this that is high performance.
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.
all the other comments are saying what i am just in a more nice manner. of course I get downvoted tho by boomers. Probably the people that sent this rubbish to the front page downvoted me. Sorry for caring about the quality of stuff on Hacker News
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.
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.