Is it normal for large software companies in the Bay Area to have rogue teams? [closed]

Question

I have seen a number of questions about rogue individuals on SE (How to handle a senior developer diva who seems unaware that his skills are obsolete? famously comes to mind), to which methods of dealing with are well documented. If a team of these individuals develops, however, e.g. an entire DevOps team responsible for engineer tooling insisting against source control, managed by the individual in question, it would be comparatively more difficult to deal with by a large margin.

Like dealing with rogue individuals, questions involving what to do when someone finds themselves on one of these teams or in a dysfunctional company comprised of these teams are also well-explored on SE (typically, the resolution is to search elsewhere for a job). Unlike the typical case, I find myself in an otherwise seemingly-healthy company that has developed a few of these teams due to growing pains of tripling in size to several hundred employees & not having a mature leadership structure yet. Since my team was healthy & the executive staff has a disproportionately high approval rating compared to other companies, I decided to stick around rather than leaving, despite how unenjoyable work became, and attempted to help rectify the situation.

For example, one "rogue" team charged with replacing our old tech stack had fostered a culture of hobbyist code purity / idealism, and weren't actually interested in the company or our product, ignoring pesky things like eliciting & triaging business requirements or architecture review. I initially tried surfacing the early signs of this to my manager/director (I am only in a senior engineering position), but it wasn't concrete enough, so I had to build a paper trail.

For over a year, I had to do the legwork to figure out what was important for the tech stack, pepper the team with questions on how we would solve those (so that they would have to willfully ignore them instead of claiming oops didn't know), document every time that feedback was ignored, document all of the gaps surfaced in architectural reviews that were ignored, document every time they restarted from 0 in the name of code purity, etc and this took a tremendous amount of time and energy. Ultimately the whole management chain (their's; not mine) got canned, but the solution of wait-until-they-screw-up-enough required for paper trails meant that we are a year behind on replacing our tech stack now

This is not time/energy-efficient, and given that this is the third team I've had to do this for, I'm now wondering whether the company is actually "healthy". Given that, my questions is: Is it standard for a software development company in the Bay Area (the apparent role model of all software companies) to have this many rogue teams once it gets to a certain size? Or, despite it seemingly doing a fine job everywhere else, is my company comparatively awful at dealing with problems within? If it is not standard, can I determine whether a company or not is "healthy" from an interview? I don't think I would have caught it at my current company since the overall workings appear fine.

Answer 1

1. Lots of companies are disorganized and have a poor grasp of what is going on inside them. I found it surprising how often in the workplace that clients would be ignored, agreements would be forgotten, meetings would be held with deliverables nobody did, "emergencies" would be deprioritized before the hotfix even arrived in prod, nobody would have a clue what I was doing for days, major features would get half-built and churned into the mud of Scrum management, etc. I've met contract employees who have been redoing the mobile app in every new framework every little while for job security. Native to Xamarin to React Native to Flutter. Nobody notices them doing that. In most organizations, I would bet that nobody is looking at the big picture in detail.
2. Employment is now very short term and I am sure that changes how employees think. I just resigned from my current organization after a year. I was preceded by the product owner a week before, the communications lead a month before, the most experienced developer 5 months before, and the team lead 9 months before. On a 10-month-old project, half the people have departed. And I am not an anomaly. Plenty of friends from university are on their 2nd jobs as well (I am class of 2019). I have never known an employment environment where you aren't updating your resume every month. Why this matters is addressed by the next point.
3. Resume driven development has long been a thing as you need it to keep getting new jobs. That is the term for the "hobbyist" work many developers do in their companies to stay relevant. People do it because not doing it helps you end up with a lot of old tech on your resume. A friend of mine is a Java developer. Not a software developer, but a Java developer. He only knows Java and only does Java. Where does he fit in a full-stack world? He doesn't. He has been unemployed for 7 months in a red hot software engineering market. Plenty of interviews later, most fall apart on the JS stuff which he is not inclined to learn. Obviously he could rectify this on his own time, but the point is that most backend only jobs have disappeared which is a major development shift.

I can't say whether it is common in the Bay area for a lot of "hobbyist" type work to happen, but it has occurred everywhere I have been to some extent. Not entire projects usually, but who does what work, the tech stack used, and whether a library is used instead of a custom component. I do know friends who have done entire projects with completely new tech though and committed their organizations to TypeScript and Deno and Vue, even when they had none of those things before. But when they finished those projects, they turned them into much better offers.

Answer 2

Your rogue team is someone else's success team. Your statements are relatively ambiguous, and we cannot understand what is closer to the reality. @DanielHatton's comment expresses my feelings exactly.

Example:

---

In Peopleware. Productive Projects and Teams, chapter 19, Tom DeMarco and Timothy Lister talk about an unusual team:

[...] Thus was born the legendary Black Team.

The Black Team was initially made up of people who had proved themselves to be slightly better at testing than their peers. They were slightly more motivated. They also were testing code that had been written by someone else, so they were free of the cognitive dissonance that hampers developers when testing their own programs. [...]

To enhance the growing image of nastiness, team members began to dress in black (hence the name Black Team). [...] Some of the members grew long mustaches that they could twirl in Simon Legree fashion.

[...] Programmers began to mutter about the diseased minds on the Black Team.

Needless to say, the company was delighted. Every defect the team found was one that the customers wouldn't find. The team was a success. [...]

---

By the way, this answer applies everywhere, not only in the Bay Area.