The tendency for corps to automate away low-tier work has some unfortunate consequences when this tendency hits things like SOCs - at that point, removing e.g. tier-1 triage type work produces minimal cost savings (junior analysts aren't all that expensive) but also removes the work experience that is required to learn how to become a senior analyst.

When your educational pipeline is interrupted, this also interrupts knowledge transfer from seniors within the organization, resulting in increased institutional knowledgebase decay over time.

Many of the services currently in production are highly resilient to disruption - and well they should be; they've been built from the accumulated knowledge and expertise of many people over a period of years, with the explicit goal of creating resiliency, maintainability, and performance.

However, that resilience is a finite resource for these services, and is maintained over time by the application of institutional knowledge and expertise; even the best-documented and most-resilient systems will decay over time if the personnel who comprehend its structure and maintenance requirements depart the service-operations role without passing this distillation of knowledge down to their successors - successors who, in turn, need an onramp to obtain such roles in the first place, an onramp that was formerly expected to be the tier-1 roles that are being progressively automated away.

And that's not to say that all tier-1 roles will vanish, and certainly not immediately - but the progressive reduction in their availability will impact the pool of personnel available for these roles.

Like all complex systems, the ones I'm talking about aren't going to immediately fall over; instead, we see gradual losses in effectiveness over time - for "the system by which security analysts are trained from neophytes to senior level" this will look like a much-reduced qualified candidate pool over time, with fewer and less-qualified candidates for the jobs that are available.

This is likely to end up being compensated for in the short run by outsourcing and exploiting international workers from areas that are lagging behind in technological availability of these junior-removing automations - but these workers will necessarily not have the same context and institutional knowledge that in-house workers will have about the nature and purpose of the systems being used, which will cause impedance mismatches that we already see with, e.g., MSSPs and their clients.

I don't have a clear feasible solution for this. I'd like to see various outfits that are working to automate away junior positions engage with this directly, tho, and to have frank and open discussions about ways to teach people how to work with their systems to gain that expertise so that they can be effective seniors in the paradigm that those companies envision in the future - tech requires people to operate, and if your product is intended -for- the disruption of such a market, describing the new system that you envision resulting from the disruption is, I think, a requisite for ethical participation in such markets.

Ultimately, I think that considering the whole lifecycle of how -your- product interacts both with the system as it is -and- with the system that your product will define with its success is absolutely necessary for a product to remain successful over time.

tl;dr:

If you want to automate away an onboarding pipeline, think about what happens if you succeed.

@munin on the opposite side, we’re working to reduce the dependence on unicorn seniors as a BCP thing, although kind of accidentally so, that was never the goal of #OpenTIDE it just became one of the things it does

@munin co-sign.

In my ideal universe where we have an apprenticeship model, the apprentices would learn to do everything manually, and only once they’ve proven themselves proficient are they allowed to use all the automation tools.

At the organizational level, failing back to manual would be part of your annual DR exercise. (As would actually rebuilding systems, not just restoring some data from backup, because HOO BOY do people not actually practice rebuilding systems)

@munin only half related but to me the difference between a tier 1 analyst and a tier 2 analyst is tier 2 understands

1. You analysis is only as good as the data you get, and

2. there is a point when your partners in the org stop wanting to provide you with more, better, or cleaner data, and

3. The reason why is almost never good for anybody.

@munin and you don’t get experience like that without seeing how it all works and holds each other up, including the people, and, fundamentally, learn how to move power around.

@thompsonize yeah, the social/political layer is one that many tech folks deliberately avoid engaging with - which, hey, mood; it took me years and hacking my endocrine system before I was able to engage with those layers productively myself; it doesn't come easily to many folks in tech.

But it's important to do so in order to have a complete understanding of the system.

@munin @0xabad1dea I'm reminded of the problem Japanese animation apparently has (well, one of them). The traditional route to becoming a full animator is starting out drawing 'inbetweens', the relatively mechanical transition frames between key frames (which are drawn by full animators). But inbetweening has been relentlessly outsourced to low-cost countries for years/decades (and people are working on automating it). This is seen as one of the cause of a significant (full) animator shortage.
@munin
1. Fail to promote level 1 staff because there isn’t enough room at the top
2. Fail to hire new level 1 staff because teams are at capacity
3. Fail to notice that operations doesn’t fail because the level 1 staff are level 2+ from years of experience, are overworked, and don’t have time for documentation or upskilling
4. Lay off all the level 1 staff and outsource their duties because they were overpaid for entry level work and didn’t make use of the training resources
5. Wonder why everything is failing all the time
@munin I was just thinking about this in re: expanding use of AI, and I agree with you entirely.
@munin I do mainframe adjacent stuff for a living.
The "young guy" amongst the mainframe admins at work is 55 years old.
Over half that team will retire over the next 5 years. The mainframe will retire with them. There is no more talent pool.
@Schlaf so what's happening with the services that that mainframe provides today?
@munin The COBOL has been transpiled into Java.
It can run on x86 now.
The devs are actually working with that java codebase now. I hear its terrible. Somehow they are doing it tho.
@Schlaf that sounds positively dreadful. And like it's a huge impedance towards getting anything actually -done-
@munin absolutely.
The Java transpile does extend the lifetime of the Software. They actually have time for a rewrite now.
I am thankfully not on that dev team.
@munin I'm not sure that's an unintended consequence. Other things (there's an article on react somewhere that talks about this) have shown that corporations don't mind reduced effectiveness in exchange for having their workers become interchangable replacable parts