[ruraljuror]

Yes. We have at least one team dedicated to identifying bugs and maintaining technical quality. For example they statistically analyze our CI runs to identify regressions. They find some subtle bugs that would be difficult to identify through one's own experience.

https://lethain.com/managing-technical-quality/ discusses when it makes sense to build such a team.

[scarface_74]

This is a team that no one interested in their career progression should ever be on. This is usually a dead end and almost impossible to spin in behavioral interviews.

[ruraljuror]

Well, not my experience at all and combining that with the link I posted, I suspect you are mistaking what I am referring to. What are you basing your statement on?

[scarface_74]

Let’s say I am interviewing two people with the same technical skills.

One says that they have spent the last couple of years fixing bugs and analyzing the CI builds. The other talks about leading major new initiatives or being responsible for a major new feature and I dig into it. Guess which one I’m going to hire?

In the terms of promo docs, which shows more “impact”, “scope” and “dealing with ambiguity”?

https://www.levels.fyi/blog/swe-level-framework.html

[ruraljuror]

It sounds like you would hire the one building CRUD apps. Perhaps I was unclear in my original post, technical quality teams don’t analyze CI and fix bugs. The team in my org builds sophisticated tools to analyze CI runs and teams self service the bug fixes. When you are operating at large scale and delivering products, there is no limit to impact or scope; ambiguity is inherent.

[scarface_74]

That’s fair. Isn’t that more of a DevOps/SRE team then and a completely separate career track for most people than software development?