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 individual 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 code purity / idealism, and never bothered with 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 because they just wanted to work on "cool" code purity stuff and had no interest in the company, 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.

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.

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 individual 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 code purity / idealism, and never bothered with pesky things like eliciting & triaging business requirements or architecture review. 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 got canned because they just wanted to work on "cool" code purity stuff and had no interest in the company, 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.

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 individual 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 code purity / idealism, and never bothered with 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 because they just wanted to work on "cool" code purity stuff and had no interest in the company, 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.