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.

  • 4
    "had fostered a culture of hobbyist code purity / idealism, and weren't actually interested in the company or our product" - you ever wonder if this is because the entire software industry now almost exclusively hires hobbyists, and short-term tenures (not to mention short-term firms, with no history and no future) make it unreasonable to be interested in the company or the product? – Steve Sep 13 '20 at 12:34
  • 2
    It may just be my unfamiliarity with the jargon, but it reads to me as if OP's definition of a "rogue team" is (at least in part) a team that wants to make a higher-quality product than OP does. – Daniel Hatton Sep 13 '20 at 13:48
  • 1
    @Drudge OK. It was just a feeling I got from some bits of wording you used, e.g. "code purity" and "idealism" sound to me like "commitment to high product quality", and "triaging business requirements" sounds like a process by which a manager decides that some other consideration is more important than product quality. – Daniel Hatton Sep 13 '20 at 19:29
  • 1
    @DanielHatton worded differently, I knew someone who worked on a personal game they never planned to ship because it provided an environment for them to experiment with interesting challenges. Similar story here, but instead of a personal project, the sacrificial experiment was an entire org. We reached out to them many times, but they were in a bubble that only cared about making a Super Epic Framework as an interesting challenge. Anything outside of that bubble like the existing problems of our old tech stack and things we needed from the new one were outside of their concern – Drudge Sep 13 '20 at 22:41
  • 2
    Bays have always been pirate havens – Kilisi Sep 14 '20 at 2:01
  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.

  • I would challenge the "full-stack world" assertion. I know plenty of backend only developers that are doing fine and are getting offers as well. I'd say it depends on the field you're in. That said, a web developer should at least be aware of the latest frontend developments - and a bit of javascript never hurt ;) – bytepusher Sep 14 '20 at 21:50
  • 1
    I would also challenge the short term work. I can neither confirm it in my company nor for my friends. Most have been sticking around with their first job for years and are still at these companies. I definitely do not know switching your employer every year as the norm. Maybe this is different in north america or this is depending on your specialisation. – Manziel Sep 15 '20 at 7:47
  • @bytepusher fair. I made the mistake of extrapolating my local market (no mega tech firms) and Y Combinator jobs. – Matthew Gaiser Sep 15 '20 at 15:44

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.


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.

Not the answer you're looking for? Browse other questions tagged .