Tip: AI doesn’t eliminate the need to know how things work. It increases the value of knowing why they work.
I ran into a problem this week with an email that was sent with a bad link. To fix it I needed to create a redirect, but not a simple redirect. This particular link relied on a php script running on the server.
Just writing up the request for the tech people would have taken more time than I had. Subscribers were going to start clicking on that link. I needed to fix it fast.
I know some php, but I’m not an expert. I do know where the relevant scripts are, I have access to them, I know what sort of solution I wanted, and I know where that solution would have to live. I quickly solved the problem with the help of ChatGPT.
Tip: You don’t have to have the solution, but you do need to know what the solution might look like and what tools to use.
As technology gets better and better, the human role will change. We won’t be writing as much code, but we will be directing the outcomes based on our own business sense.
But there’s more. We also need to know …
- What are the boundary conditions?
- What are the possibilities?
- What are the restraining factors?
I’ve known managers who trust their IT teams a little too much.
“No, look. You’re the tech people. Find the solution.”
Sometimes that works, but often it doesn’t. Not because the IT people are stupid, but because the nature of their work requires them to think about their own systems in a certain way. Those systems are designed with specific goals and constraints in mind, and the IT people have to think inside those constraints.
That’s a good thing. If they didn’t keep the right constraints in mind, you’d have security vulnerabilities, crashing servers, and so on.
It works like this.
Back when I was leading a beta test of a new content management system, we had an onsite programmer who worked for the company that designed the CMS. He was a good programmer and he knew the system, but he wasn’t very creative.
I’d notice that progress on a key component was stalled, so I’d ask what’s up. He’d explain, and then we’d play, “Have you tried this?”
I knew the general requirements and the basic tech landscape well enough to come up with creative solutions. We’d talk through them. He’d shoot down a few, and then his eyes would light up and he’d say, “that one might work.”
A half hour (and two cigarettes) later the problem was solved.
I couldn’t have implemented the solution, but I knew enough to know what a solution might look like.
There’s a relevant Star Trek story here.
When Khan ambushed the Enterprise and caught an overconfident Captain Kirk with his pants down (as he said), Kirk found a solution (tell the Reliant to lower its shields) because, as he said to Lt. Saavik, “You have to learn why things work on a starship.” (I’ve always thought that was an underused quote, along with “you left space dock without a tractor beam?”)
The “why” is important. It’s not merely “know how to operate the equipment.” Kirk is saying you need to understand the underlying logic of the system well enough to do something new or unexpected with it.
This leads to another of my rules when it comes to tech development.
Tip: There are “yes” programmers and “no” programmers, and you’re better off with the “no” programmers.
IT staff tend to default in one of those directions. The first group wants to please, and they want to work with you, so they say “yes” to most requests. Then they come back later and tell you all the conditions, limits, and potential problems.
I prefer the “no” programmers. Almost every request is met with “it can’t be done.” It’s tempting to blame that on laziness, but I think there’s a deeper insight.
I prefer the “no” programmers because it tells me they have the system constraints top of mind. They know what’s going to break the system (lose data, cause slow page loads, open a door for hackers, etc.), and your idea scares them because they get the blame when the system goes down.
That’s when you play the “what about?” game.
Like Kirk, you need to know why things work on a starship so you can make reasonable suggestions. (Outlandish suggestions will hurt your credibility.)
You take the creative responsibility (in a constrained, reasonable way), and the tech team does their job – protecting the integrity of the system.
Some people think AI means it’s no longer necessary to know how things work. All you have to do is tell the AI what you want and it will find your solution.
My experience suggests almost the opposite. AI dramatically increases the value of the person who knows – not everything – but enough about how things work.
This skill is crucial, especially as more and more tools are automated. Humans who supervise tech development need to have an upper-level understanding of how and why things work so they can think creatively within the constraints of their mission and tech stack.
They also have to know when they’re being bullshitted – either by a reluctant tech team or a hallucinating AI.
