See, most people seem to forget that if you want someone capable of doing complex tasks that require experience - they need a path to gaining that experience.
That's part of why I talk about pipelines so much.
Okay, I generally talk about leadership pipelines, but it applies to practically every task that isn't an entry level role.
Companies keep putting out these posts asking for '5-10 years experience', but where do they find the people with that experience?
Generally by hiring someone who got that experience somewhere else... which means that if they're not growing their own talent then they are compete for the (limited) pool of talent that someone else developed.
Basically, any time people complain about a shortage of workers you should ask yourself where the pipeline to building that talent is. And if the company doesn't have one, then they're honestly part of the problem.
But let's get back to AI.
AI takes some of the same challenges with automation and escalates it to the nth degree.
What I mean is this...
Automation is fantastic. I love it. It makes my job easier. Any time you have a repetitive task that needs to be done in the exact same way, the exact same order, repeatedly - automate it! You are only limited by the time and effort it will take to create the automation tools.
Heck, you can even create some type of 'self-healing', where you even automate a response to certain events.
At the same time, there's a very real problem that occurs when whoever created your automation moves on to a new role and the people remaining don't understand the tools they're using.
Need to update your automation in order to take into account changes to your business? Somebody has to understand what your tools are doing, so they know where and how to update it.
Have some bug that causes your automation to error out? Somebody needs to know enough about it to troubleshoot the issue.
Anybody can go to a CI/CD resource and click the button to run a pipeline that does whatever they're configured to do.
The real problem comes when that's not enough.
When it breaks, or needs updated, or requires knowledge that goes beyond just going to your Jenkins site, or Azure DevOps, or any other CI/CD tool and running it.
You cannot get away from human involvement. You may reduce the need, maybe one super-experienced DevOps expert can do what used to take 5 people to do, but you. will. always. need. someone. who. understands. it.
Someone who knows what your application or program or pipeline is supposed to do, how it does it, and how to revise it as needed.
And here's the thing... if you use AI to take away the first tier jobs, those entry level jobs?
Where are you going to get the people with the experience needed for the second tier? The ones who maintain your tools?
I don't have a problem with AI per se, I do have a problem with people treating it like some miracle tool that will allow you to get around basic people management.
Tech keeps getting more and more sophisticated, which is awesome. It also means that there's more and more places where things go wrong (to quote Murphy's law), and the more that complexity is hidden away in layers, the more difficult it is for the people maintaining it to understand the problem.
I think that's part of why I did so well in my last DevOps role, tbh. We've got all these complex tools to do all sorts of things, and once you get past the superficial basics like running pipelines or monitoring dashboards and alerts, most of the issues require a deeper understanding of the application. Like understanding why a bad record in one particular kafka partition will eventually stop all consumption in that consumer group. Or understanding how to check those partitions in the first place. Or understanding how to update your consumer so that it skips a bad record.
In some ways, this reminds me of qualitative and quantitative analysis. See, quantitative analysis deals with cold, hard facts. At least, it does if you're doing it right, for example by successfully creating questions that aren't biased and try to push survey takers to give a certain response.
Quantitative analysis let's you say 'oh, 56% say x' or 'there's a relationship between income, education, and support for y'.
But the thing of it is, quantitative analysis requires you to already know enough about the topic to know which questions to ask. If there's a relationship between income, education, and support for y... but you never ask your responders for information on their education level, then you won't ever be able to tell whether there's a relationship or not.
This is where qualitative analysis starts getting important, because it allows you to have focus groups and in-depth interviews with people involved with a topic, which can give you a much better sense of what questions to ask and what factors might have relationships worth investigating.
This is not an either-or thing. One is not better than the other. They are complementary, and work together.
In the same fashion, human judgment and computing technology is complementary and should work together.
I am absolutely for anything that helps reduce the stuff I hate doing. The boring, repetitive tasks. Especially ones that are easy to screw up if you're having a bad day and aren't thinking too clearly.
Using a pipeline to make sure our application is created correctly, in the right order, every time? Yes, please. Even using one to run through the thousands of calculations and steps needed to prepare a daily report?
Yes please.
But that does not and should not mean you can replace people entirely. Especially if you ever want to update your pipelines, or migrate to new technologies... or ever need anybody who actually understands what your application does and how it works.
And all of that? Applies to AI, to an even more exaggerated degree.
My last company tried getting us to use a company AI for a bit, and yes... it's nice when it can clearly summarize and articulate something about our application. Makes it a lot easier for me to understand things that were kind of hard to figure out.
Except...
It's basically making up for the loss of tribal knowledge. And given its ability to 'hallucinate', it does a poor job of making up for that loss. I mean, it's better than nothing? It can be convenient? But... it'd be even better if there was a good onboarding program to make sure everyone knew what they needed to know. (and yes, we did have one. We had a whole list of videos on relevant topics, as well as multiple company wiki pages. Much of it quite disorganized, and you could search the wiki to find some of what you needed to know but the pages were often made for quite specific issues and didn't necessarily give the broad overview. And as for the videos? You had to have the time to work through them, which... well, is kind of hard to fit in sometimes.)
Anyways... it just seems like people are pushing these things because they don't understand or want to deal with the basics.
Build your team. Create your talent pipelines. Capture institutional knowledge and make sure it gets passed along to new members.
And make sure you have people who understand what your tools are supposed to be doing, how they do it, and how to fix it if needed.
No comments:
Post a Comment