The Human Side of Technology
AI is Preventing Me From Getting a Job: The First Artifact Isn't a Resume
I got tired of pretending a 30-year engineering career is best explained as a chronological collection of bullet points.
There. I said it.
I've been looking for my next role for a while now, and I have done all of the things you're supposed to do.
I've tailored resumes to job descriptions.
I've changed summaries. Moved skills around. Rewritten bullets. Added the language employers use when it accurately describes something I've done. Removed things that don't matter for a particular job. Made resumes shorter. Made them longer.
I've had AI review them. I've had recruiters review them. I've looked at them as a hiring manager who has read more resumes and interviewed more engineers than I care to count.
And somewhere along the way I started wondering:
What if we're working on the wrong artifact?
Not because resumes are useless.
Not because ATS systems are evil.
Not because AI has ruined hiring.
And certainly not because I'm going to tell you I invented some magical document that fixes recruiting.
I just started to think that maybe the first thing I needed wasn't another resume.
Maybe I needed to understand my own career, not as chronology, but as archaeology.
Stop Writing. Start Digging.
This started, as many of my recent experiments have, as a conversation with my coaches.
We were supposed to be working on my resume.
Instead, I started having my AI collaborators interview me.
Not:
What were your responsibilities at Pocket Communications?
But:
What was happening when you got there?
What wasn't working?
Why did it matter?
What did you actually do?
Who else was involved?
What went wrong?
That last one turns out to be especially useful.
And we kept digging.
At some point we started calling the process career archaeology. Nothing could be more fitting.
We weren't trying to make the existing resume sound better. We were excavating things that had been compressed into bullets years ago and then copied, rewritten, shortened, optimized and reorganized so many times that much of what actually mattered had disappeared. It was too monotone, too whitewashed.
And, boy, did we find stuff.
The Million-Dollar Renewal
Take Pocket Communications.
On a conventional resume, one of the bigger projects from that period might become something like:
Led replacement of third-party billing platform, reducing vendor costs and successfully migrating approximately 450,000 customers.
That's not wrong.
It's also not the story.
Pocket was approaching renewal of a third-party billing system.
The renewal was going to cost about $1 million.
Someone asked whether we could build the thing ourselves.
I said something along the lines of, "Sure, but let me find some stuff out first."
We knew the system. We knew the APIs. We'd been living with it for years.
The harder question wasn't whether we could write software.
It was whether we could replace a production billing system while the business kept running.
We put together a small cross-functional team. Software engineers. DBAs. Systems people. A designer. Me playing some combination of project manager, architect, developer, cat herder and, occasionally, therapist.
We gave ourselves roughly 90 days to build it and another 10 to pressure-test it.
Meanwhile, production kept being production.
Customers kept signing up.
Payments kept happening.
Data kept changing.
So we built beside the existing system. We mapped and cloned databases. We isolated what we needed. We practiced the data delta. We created a cutover plan.
Then came Day 95.
We cut over.
The data checks didn't look right.
So we rolled it back.
Four days later, on Day 99, we did it again.
This time it worked.
Roughly 450,000 customers moved to the new billing platform without knowing we'd done anything at all.
And Pocket didn't write that $1 million renewal check.
Now that tells you something about how I engineer systems.
And it isn't:
Experienced in billing migrations.
It's this:
Good migrations aren't defined by never failing. They're defined by making failure recoverable.
That sentence didn't exist on my old resume.
The experience did.
We just had to dig it up.
Then It Happened Again
Once we started looking at the career this way, something interesting happened.
Companies started becoming less important than patterns.
Years later, at Constant Contact, we moved an internal application platform from on-premises infrastructure into AWS.
We didn't switch everything off one Friday afternoon and hope CloudFormation was feeling cooperative.
We built the new machinery beside the old machinery.
We moved lower-risk workloads first.
We learned.
We left the largest internal workload until later.
And when the first major cutover exposed a networking problem?
Rollback.
Fix it.
Try again.
A few days later, successful migration.
Different company.
Different decade.
Different technology.
Same engineering instinct.
Change the machinery while it's still running.
That was the moment this experiment started getting interesting.
The Resume Had Hidden the Patterns
We kept going.
At Newfold Digital, I helped modernize an aging Jenkins environment.
The obvious resume version is full of wonderful keywords:
Kubernetes. Helm. Docker. Jenkins. Artifactory. AWX. Ansible. CI/CD. Infrastructure as Code. Ephemeral build agents.
All true.
All useful if you're trying to help a recruiter or a machine determine whether I've worked with a technology.
But that's not what I find most interesting about the project.
We could have automated more than we did.
We deliberately didn't.
Application teams needed to understand their pipeline templates. They needed to understand what changed when their applications moved from bare metal into containers. They needed enough ownership to succeed without a platform engineer standing beside them forever.
So we provided templates.
Documentation.
Training.
Reporting.
Deadlines.
Hands-on help.
And automation where automation removed work that taught nobody anything.
The principle we eventually pulled from that story was:
Automate the work that teaches nothing. Don't automate away ownership.
Again, that had never appeared on my resume.
But it explains quite a lot about the way I think about developer platforms.
And Again
During the separation of Constant Contact from what became Newfold Digital, the problem wasn't primarily a technology problem.
It was a legibility problem.
One company needed to retain a platform.
The other company still needed many, if not all, of the same capabilities.
There were applications, databases, networks, payment systems, security requirements, dependencies and people spread across all of it.
So the questions became:
What gets duplicated?
What stays temporarily shared?
Whose data is this?
What depends on what?
What order does this happen in?
Who owns each piece?
How do we know when it's actually done?
Once we could answer those questions, we could turn an enormous technical problem into work that engineering teams, database teams, network teams, security people, contractors, project managers and executives could all reason about.
Make the problem legible.
Another pattern.
At Fugro, we introduced Docker, Git, Jenkins pipelines, versioning and repeatable delivery practices into an offshore survey software environment.
But the part I remain happiest about isn't that we introduced those technologies.
By the time that I left, the engineers didn't need me to operate them.
Build platforms engineers can own.
There it was again.
Wait a Minute. Wait a Stinkin' Minute.
At this point, we weren't really looking at jobs anymore.
We were looking at recurring problems.
Across companies, titles and technologies, I kept doing variations of the same things:
Change the machinery while it's still running.
Remove operational toil without removing ownership.
Make complex infrastructure problems legible.
Build platforms engineers can own.
Those seemed much more useful than:
Company. Title. Dates. Bullets. Next company.
The chronology wasn't wrong.
It just wasn't the most interesting organizing principle.
That realization changed the entire resume experiment.
The First Artifact Wasn't a Resume
Before we could write a better representation of my career, we had to build a better model of it.
That became the real first artifact.
Stories. Failures. Constraints. Decisions. Outcomes. Receipts. Patterns. Principles.
Bring it all to the table.
Some of the best material didn't belong on this resume at all.
That didn't mean it wasn't resume material.
We talked about hiring.
About a young engineer I hired because I saw a spark.
About another very capable engineer who taught me that aptitude without judgment and humility can be dangerous.
About the steady engineers who rarely make the most noise but carry enormous amounts of institutional knowledge.
I call those people the Sun.
We talked about the Air Force and learning that everyone needed to understand the whole mission.
We talked about the difference between leading engineers and merely managing their work.
We talked about when a technical leader should step in, when they should stay out, and why you have to remain close enough to the work to know the difference.
Not all of it belonged in the resume.
That wasn't the point.
Excavation isn't editing.
First you find what is there.
Then you decide what matters for the artifact you're building.
Which is how we ended up with a ten-page resume.
Of course.
Ten Pages
The first narrative version was enormous.
And that was fine.
For the first time in years, the problem wasn't:
How do I make myself sound like this job description?
The problem was:
Which parts of this career actually help explain who I am as an engineer and manager?
That's a much better problem.
The scissors came out and the cutting began.
We trimmed. We trimmed some more.
We reorganized. Shuffled things around.
Then a Principal DevOps Engineer role appeared.
Perfect.
Now we had a test.
Instead of returning to the job description and rebuilding my resume around its list of requirements, we started with the narrative baseline we'd already built.
What problems does this company need this person to solve?
Which stories from my career demonstrate that I've solved similar problems?
Which technologies provide useful evidence?
Which stories don't matter much for this particular conversation?
And, just as importantly:
What haven't I done?
The role called for Terraform. I've done some Terraform, but my Infrastructure as Code experience has centered on CloudFormation.
So the resume says CloudFormation.
It called for other things that weren't part of my experience.
We didn't sprinkle them into a skills section.
We didn't play keyword Mad Libs.
The goal wasn't to make me look like a perfect match.
The goal was to make it easier for someone to decide whether the engineer I actually am might be useful to them.
The ten pages became six.
Then five.
And eventually we had something I hadn't expected.
A resume I actually liked. (Hey, Mikey!)
So I Shipped It
The final version still contained technology.
Plenty of it.
AWS. Kubernetes. Docker. Helm. CloudFormation. Jenkins. Ansible. Artifactory. Linux. REST APIs. PCI. Payments. Distributed systems.
Machines need nouns.
Recruiters need recognizable signals.
Hiring managers need enough context to know whether continuing the conversation is worth their time.
But those things weren't the structure anymore.
The problems were.
The decisions were.
The outcomes were.
The engineering judgment was.
At the top we put the sentence that had emerged from the entire experiment:
I got tired of pretending a 30-year engineering career is best explained as a chronological collection of bullet points.
Followed by the thing we'd finally figured out:
It's better explained by the problems solved.
And yesterday, I attached it to an application for Principal DevOps Engineer role.
Version 0.5.
Production deployment.
Ship it.
And then Workday tried to read it.
That...
...was interesting.
Continued in Part 2. (which is coming soon)