[hbrn]

Any "architect" joining the company and pushing for drastic changes like that is either an idiot chasing the hype, or a malicious actor trying to boost their importance.

Good news: your gut feeling is correct.

Bad news: you will likely lose this battle, unless you're good at playing company politics.

Here's how it typically goes:

1. A new lead/architect/manager joins the company.

2. They push for a new hyped technology/methodology.

-> you are currently here <-

3. The team is split: folks that love new things embrace it, folks that care hate it, rest are indifferent.

4. Because the team is split, the best politician wins (usually the new hire).

5. Switch happens and internally you know it's fucking disaster, but you're still forced celebrate it.

6. When disaster is becoming obvious people start getting thrown under the bus (usually junior engineers or folks that opposed the switch).

[filoleg]

> Any "architect" joining the company and pushing for drastic changes like that is either an idiot chasing the hype, or a malicious actor trying to boost their importance.

Or, which seems more likely, but still just as bad - someone chasing the "successfully redesigned the infrastructure on a scale of the entire company" on their promo packet and resume.

Whether it actually improved the infrastructure is of no concern to them. Not needing to even try to understand the existing infra in-depth to make it happen, and the added job security (due to making the infra more complex and confusing for the rest of engineers to understand), are just a cherry on top.

Call it a cynical take, but this is one of those situations where "the simplest explanation is probably what actually happened" feels about right.

[thunky]

> someone chasing the "successfully redesigned the infrastructure on a scale of the entire company" on their promo packet and resume.

Also don't underestimate someone that is smart and well intentioned but dangerously overconfident and completely unaware.

These may be the toughest for manager types to sniff out because they believe their own hype.

[spiffytech]

5.5 - the new hire adds this project to their resume, uses that to land a new job with a fancier title, and leaves the project to fall apart because there's no longer anyone committed to its success.

[gw98]

Seen that. Currently living it.

Honestly it has pretty much destroyed our business and customer relations looking after the pile of steaming shit that remains.

[intelVISA]

Don't leak my playbook, spiffytech..

[johngalt]

How to derail this dynamic early:

"Does this solve a problem we have?"

"Of the top five things that we are trying to build, does this add any of them?"

Often the problem isn't that the new methods/tech is bad but that all the effort spent transitioning to it could be better spent directly attacking the goal in the first place.

[hbrn]

I wish it was that easy.

"Of course it does: engineers will be more productive, we'll have less bugs and better performance. {TECHNOLOGY} has been around for {N} years and getting more and more traction. Do you want us to be ahead of our competitors or not?"

"You need to understand that sometimes you have to sharpen your axe before cutting the trees. Have you heard the phrase 'work smart, not hard'?"

"So essentially you're saying we shouldn't change anything despite having issues (bring up any bug/downtime you had recently). John, sometimes you have to escape the comfort zone and learn new technology."

I once worked with a person who talked like this in front of non-technical founder. I bet he did sound quite convincing, it took me a while to cut through the bullshit.

[hutzlibu]

Those quotes ain't generally bullshit. They are general and generic pieces wisdom - but of course, whether they are really wise, depends on the actual technology and the actual product and the actual problems.

[tacostakohashi]

Yeah that doesn't work with things as hugely hyped as the cloud, agile, etc. Obviously it's a cult and it doesn't solve anything in and of itself, but you're not allowed to say that.

Rather, I'd go for:

"Let's solve this problem we've been having with Azure Cloud Functions!"

"Of the top five things that we are trying to build, let's build them with Agile!"

Otherwise, you are not a team player, part of the problem not the solution, etc. It sucks, but that's politics.

[birdstheword5]

Sadly, I think you are completely correct, and this exact sequence of events will go down. I don't think they're an idiot or malicious - I think they're clever and mean well, but perhaps they're blinded by their enthusiasm after getting certified

[x0x0]

Or it's pure RDD (resume driven development.)

That said, you can figure out (just ask!) if this person was brought in as the result of an already-made decision to move to this type of development, or if this person is pushing it. As an EM, I'd have no problem with a report directly asking that question.

If the answer is the decision was made, and this hiring was a downstream result, then your choice is likely to deal with it or move on. If the decision hasn't been made / this architect is advocating for it, then a cost benefit analysis (which you'd think would be a standard part of any work) will be illuminating. My understanding of the tooling / debugging / monitoring tooling for serverless is that it's still quite raw. Although my bias is towards not wasting innovation tokens on things like serverless / I align strongly with the choose boring technology view advocated by Dan McKinley [1], amongst others.

[1] https://mcfunley.com/choose-boring-technology

[tillmannhgl]

just a great explanation ;)