[eawgewag]

I think the article is arguing that if you build the relationship, you can involve yourself into these conversations early enough to direct them the way that your idea would go. In your cases, for example:

1. Recognizing early enough that this Hot New Thing incentive is here and figuring out how your Good New Thing can live with the Hot New Thing

2. Helping show the Old Bad Thing is unworkable for your Good New Thing

3. Understanding that the org cares about New Buzzword and framing your work under those pretenses.

[garciasn]

I think the article is great, in theory; it just NEVER works this way in practice, unless you may be in a technical organization. There are ALWAYS business reasons that cause technical projects to fail. We regularly see the articles about the failure rate of technical projects all the time on the front page.

Why is this? Because the number and weight of the business folk almost always outnumber the technical. You can be the best fucking political engineering wrangler in the world; building relationships, taking people along for the ride, helping others gain understanding and those projects still fail.

[circlefavshape]

> There are ALWAYS business reasons that cause technical projects to fail

So it's always business folks' fault, and never the nerds' fault? My experience has been different (full disclosure - professional nerd for 30 years)

[lmm]

For the overwhelming majority of day-to-day, line-of-business software, the nerds are a commodity and the project succeeds or fails on how good or bad the business folks are. They should get the blame for the failures but also the credit for the successes.

For the stuff that is genuinely pushing the technical envelope, it's possible for the nerds to make the difference. In those cases you do see the projects fail for technical reasons like "the code couldn't scale to the required number of users" or "the technical functionality never worked reliably", and those kind of failures are the nerds' fault. But that's the minority of failures IME.

[garciasn]

I appreciate you replying. My intent was never to place blame; instead, it was to point out that while the article's author suggests technical folks need to play the game better, I feel that it won't matter and getting the rest of a non-technical-first org along for the ride is more difficult than just being a solid political player.

[dwohnitmok]

The article's point is that "the rest of a non-technical-first org along for the ride" is indeed playing politics (or at least a subset thereof).

[Maro]

This.

I've recently been promoted to be a VP (so, an executive) at a large corporation of ~50,000 people. Of the top ~250 people, so the top 0.5% of the hierarchy [who get invited to the annual leadership offsite], I estimate there are maybe 2-3 technical people like me. Also, within the executive hieararchy, these 2-3 are at the lowest level, this is not even where the big decisions get made, we're just put in charge of executing the decisions made by MBAs and Finance people.

[fuzzfactor]

>There are ALWAYS business reasons that cause technical projects to fail.

I agree with this concept and what's worse is when a project is technically sound but still fails, or even when a complete high-performance accomplishment fails to be deployed.

But I'll bend the terminology of "always" and "business" because it applies even wider than that.

If you've ever worked for a 19th century company that is an actual bureau by definition, and has had literally over a century to develop from those roots into a much more resilient bureaucracy than could be accomplished in less time, you know what I mean.

What if it's not always a business reason for failure but a bureaucratic component that rises above a tolerable level?

i.e. a non-business reason for "businessmen" to fail.

In a pure bureaucracy that exists solely to maintain standards of some kind, the focus can not be on making money, or the standards could be compromised.

Others will fall by the wayside and only the most successful bureaucrats will prevail in their efforts. Handsomely rewarded sometimes through fees and taxes paid by the real money-makers whom the bureau has evolved to serve.

Yes, rewarded for their efforts, none of which are business-like at all and without any internal focus on making money whatsoever.

These organizations can be some of the most stable and long-evolved of all, plus set the most consistent example of political hierarchy that people in all kinds of places can tend to emulate when they don't have any better ideas.

So when bureaucracy creeps into a business where it has not yet made an incursion, it has to do so under the radar because it's the opposite of trying to make money.

People get good at this and move up in the hierarchy, and eventually there's nobody who's even good enough at actually trying to make money any more. It's a full-time effort just building & maintaining the bureaucracy.

You end up with people that "look" like businessmen, act the way they think businessmen should act, golf like businessmen, etc.

But haven't got a clue how to make a dollar from a functional technical success that's a complete no-brainer :\

[zanellato19]

Never works in practice is such a strong statement and I would argue that most of the time is because the technical people avoid politics entirely, like the article says

[eawgewag]

I dunno, honestly, my organization works a lot like what the post is describing. I think my org has healthy politics but at the same time I can't really tell if the times I thought the politics were "toxic" were simply because I was on the outside looking in, whereas this time I'm an operator in the space.

[Spooky23]

Engineers are always insufferable with this stuff. I can think of dozen times where everything was perfect, except for <thing we didn’t think of> or <thing we knew but didn’t bother to engage the customer on>.

There’s a million reasons why projects fail, but astute engineering mangers who are able to understand what the business really needs are invaluable.

[some_guy_nobel]

What about RTO? New 'ai-first' genai initiatives?

[eawgewag]

I mean sometimes you are outruled. That's part of recognizing politics, in my opinion. If your VCs want you to do GenAI and you think it's dumb, you are overruled. But you can still benefit from this in a lot of ways. You just need to recognize what you can benefit from.

[some_guy_nobel]

Sure,though this stands in contrast to the author's thesis: "It’s the loud person who’s wrong getting their way because the quiet person who’s right won’t speak up."

[eawgewag]

Politics involves understanding the hierarchy though. And understanding when you are overruled.

If the hierarchy is saying "it's time for GenAI", you have the option to participate in a way that raises your profile and positively influences the company (involving politics), if you hate GenAI so much you can leave, or you can stay silently and opt out of the process. These are all choices. Personally I'm fine with my VCs making strategic decisions since they trust me to make technical decisions. So we can do GenAI, we'll just do it in a way that works and is sustainable for the codebase.

You should realize that as a technical person your domain is not business strategy. Similarly I'd be shocked if any VC ever came in and told me "to use PostgreSQL" or some other nonsense. If you want to be the person deciding what we build, go into Product.

[some_guy_nobel]

I will repeat again, this is in direct opposition to the author's thesis: "It’s the loud person who’s wrong getting their way because the quiet person who’s right won’t speak up."

Given that, I'm not sure what your message is in response to. I will say that 'learn to parcipate in the hierarchy' and 'everything is a choice, just quit!' are hardly solutions at all, and read more as truisms.

I'll add that I'm not sure what VCs have to do with anything here, though as someone who formally took VC funding, I wouldn't want them making technical or strategic decisions on my behalf, and I suspect the majority of founders (and others on my cap table) would agree.

[eawgewag]

I think if you're in the position of being a founder, this article isn't for you. And our conversation isn't really talking about the same thing, which explains the lack of common ground here.