I've been working in DevOps for around 14 years, and I've also been teaching DevOps and Cloud subjects at universities for the last 4–5 years.
One thing I've noticed recently: getting your first DevOps job seems much harder than it was even 2–3 years ago.
A few years back, students and juniors would send me their CVs and I'd usually have something useful to suggest. Many of them would at least get interview opportunities.
Today, the market isn't great, and on top of that, everyone has access to AI-generated CVs, cover letters, LinkedIn profiles, and so on. When hundreds of applications all look polished, it becomes harder for recruiters to figure out who actually knows their stuff.
So here are a few things I keep telling my students.
1. Don't Choose DevOps Because You Think You Can Avoid Coding
I've heard this quite a few times:
"I'm not interested in coding, so I'm thinking of DevOps."
That's the wrong reason to get into DevOps.
You'll write scripts, automation, YAML, pipelines, Infrastructure as Code, debugging tools, and sometimes proper application code. More importantly, you need to enjoy investigating systems and figuring out why something isn't working.
If you hate both coding and troubleshooting systems, DevOps probably isn't the escape route you're looking for.
2. DevOps Comes With Responsibility
Remember Spider-Man?
"With great power comes great responsibility."
That applies surprisingly well to DevOps.
The infrastructure you're managing might be running someone's entire business. Sometimes you're having dinner with your family and an alert appears on your phone. Sometimes something breaks at an odd hour. Sometimes everyone else is enjoying a holiday while you're wondering why a production node suddenly decided it no longer wants to participate in society.
Not every DevOps job has terrible on-call expectations, of course. But ownership and accountability are part of the profession. Know what you're signing up for.
3. Build a GitHub History, Not Just a GitHub Account
When I started 13–14 years ago, having an impressive GitHub profile wasn't nearly as important for many infrastructure roles.
Today, if you're a student with no professional experience, your GitHub can become evidence that you actually build things.
Don't obsess over making every project impressive. First build the habit of creating things regularly.
Write scripts
Build Docker images
Automate something with Python
Create Terraform modules
Write an Ansible role
Deploy Kubernetes applications
Build CI/CD pipelines
And commit your work.
I actually suggest turning this into a game.
When I was in school, some friends and I wanted to improve our English. We made a game where we had to speak English all the time — if someone caught you speaking another language, you lost points. We did this for years, and it genuinely helped.
Do something similar with GitHub.
Find a friend. Every day you commit something meaningful, you get a point. First person to 100 wins. Then reset and start again.
You'll miss days. You'll get bored. That's fine.
But after a year, compare your GitHub profile with the one you had before.
4. Stop Sending the Same Application to 500 Companies
AI has made mass-applying ridiculously easy — which also means everyone can do it.
I'd rather spend proper time on 10 jobs I genuinely want than blindly apply to hundreds with the exact same CV and a generic cover letter.
Read the job description. Understand what they're actually asking for. Then explain why your experience and projects match those specific requirements.
Quality over volume, every time.
5. Don't Just Ask AI to Write the Entire Cover Letter
Use AI to proofread it, improve it, or organize your thoughts if you want.
But put yourself into it.
Mention something specific from the job description. Explain a relevant project. Explain why you're interested in this particular role.
It's okay if your writing isn't perfect. I'd personally rather read something that sounds like a real person than another perfectly formatted:
"I am thrilled to apply for the exciting opportunity to leverage my passion for innovative cloud-native solutions..."
You know the type.
6. Add Something Human to Your Application
One thing worth experimenting with: a short Loom or video introduction.
Not 10 minutes. 60–120 seconds.
Something like: "I know you're probably reviewing a lot of applications, so instead of making you read another long introduction, here's a 90-second video about who I am, what I've built, and why I'm interested."
Whether recruiters watch it is another question. But at least you've given them another way to evaluate you — something that's genuinely hard to fake with AI.
7. Make It Clear You're Willing to Prove Your Skills
When appropriate, mention that you're happy to go through a technical evaluation or practical exercise if that's part of their process.
For someone without much professional experience, being able to show what you can do can be far more useful than another paragraph claiming you're "passionate about DevOps."
None of these are magic tricks.
They won't guarantee an interview, and they definitely won't guarantee a job.
But the way people apply for jobs has changed dramatically with AI. If everyone's CV looks good, simply having a good-looking CV isn't much of a differentiator anymore.
Build things. Show your work. Develop consistency. Personalize your applications. Give people evidence that there's an actual engineer behind the PDF.
Curious what others think — especially people involved in DevOps hiring.
Has the way you screen junior DevOps candidates changed over the last 2–3 years?
I still remember the date almost. Not exactly, because it's been years. But I remember it was a Friday. I remember it was IPL season. And I remember I had a ticket in my pocket for my first ever live cricket match.
I was an intern back then. QA team. I'd been handed a project because I "liked Linux." That's it. That was my entire qualification. I'd played around with LAMP stacks, set up WordPress a few times, run enough commands to feel dangerous. So when they needed someone to set up a QA environment for a PHP application, my name came up.
Simple task, they said. Get the environment running. Make it accessible. Client's in Australia, they need to see it live if things go wrong.
Nothing about that sentence was simple.
The Setup From Hell
I started with VirtualBox, because that's what I knew. My boss shut that down immediately. Had to be AWS. Public URL. Client access.
New OS setup. New cloud platform. New tool called Composer that I'd never touched. I did what every self-respecting engineer with no documentation does: I Googled my way through it.
Every install hit a wall. Every wall meant a new Jira comment. Developers would reply with fixes: use this version, open this port, set the database up like this. I'd write it all down on a random notepad. Spin up a new instance. Try again. Snapshot everything because god forbid I lose progress. Scrap the instance. Repeat.
Three weeks of this. Three weeks of two steps forward, one step into a wall.
The Comment That Ruined My Friday
Mid-day, that Friday, I saw it. A comment on the ticket from the client. Something like "not happy with the delay."
As an intern, that hits different. You don't have the thick skin yet. I read it and felt genuinely sick.
I made a decision right there: I'll fix this today. Match or no match.
6 PM came and went. 6:30 too. Office was emptying out. I was still at my desk, notepad open, trying combination number forty of the same setup.
That's when my boss's boss walked past. Not my direct manager, the guy above him. Saw an intern still sitting there at that hour and got curious enough to ask what was going on.
I showed him the comment. Told him I couldn't crack the setup.
The Question That Changed Everything
He sat down next to me. We started fresh, new instance, working through it together. At some point he noticed my notepad, full of scribbled notes from old chats and Jira threads.
"What's this? Who gave you this?"
I explained. Historical Jira comments, cobbled together over three weeks.
Then he asked the question I should have asked myself on day one:
"Do you not have documentation for this setup? Surely someone who built this environment before has notes. Did you ever ask?"
I hadn't. It genuinely hadn't occurred to me that documentation was something you could ask for. I thought my job was to figure it out, silently, on my own, because asking felt like admitting I wasn't good enough.
He looked at me and said something I've never forgotten: learn to say no, or learn to ask for help, when you need it. You're an intern. You're not the highest paid person in the room. Nobody expects you to know everything. But dragging on for three weeks because you were too afraid to ask a question? That helps nobody.
The Email
We tried the setup a couple more times together. Then we did something I hadn't thought to do in three weeks: we wrote an honest email to the client. Explained the real story. No documentation had ever been shared. No process existed. That's why this dragged on, not because anyone was slacking.
We left the office around 10 PM. I walked out past people who'd already watched their match and were heading home. My ticket was still sitting unused in my bag.
I won't lie, I was gutted about the match. But I was also carrying something heavier than disappointment. I'd learned something that had nothing to do with Linux or AWS or Composer.
The Payoff
Next morning, a full documentation package landed in my inbox from the ops team on the other side. Turned out it existed all along. Nobody had thought to hand it to an intern, and I'd never thought to ask.
With that doc in hand, I set up the entire environment in one shot. Automated it with a shell script right after, just so nobody after me would have to go through what I did.
Why This Still Matters
That lesson didn't stay in that internship. Years later, at a different company, a server went down and the CEO's email landed straight in my inbox asking what DevOps was doing about it. I told him straight: DevOps isn't magic. Some things need process, not miracles. That confidence to say it plainly came from that Friday night.
Since then, I've made it a habit. If I know the answer, I say yes upfront. If I don't, I say so, without the fear of looking incapable. That fear is expensive. It cost me three weeks and a cricket match. It doesn't need to cost you anything if you learn the lesson early.
So here's the takeaway, for every intern, every junior engineer, every person new to a team: ask for the documentation. Ask for help. Say no when you need to. Nobody's going to think less of you for it. If anything, they'll respect you more for not wasting three weeks pretending you have it figured out.
I missed a cricket match to learn that. You don't have to.
Let me take you back to 2012. I was young, curious, and had just been handed the keys to a Nagios server. One server, a handful of clients. Nothing fancy. Just config files, cron-like discipline, and a dashboard I had to check every single morning like it was my first cup of chai.
That daily ritual taught me something no course ever could. Logging in, scanning the trends, noticing when something looked "off" before it became a full-blown crisis. Disk filling up because some user decided the server was their personal Dropbox? Caught it. CPU spiking for reasons nobody could explain? Went hunting for the process before it became a 2 AM phone call. This wasn't fancy AIOps. This was just paying attention, the old-fashioned way.
Every new server that got provisioned, I added to Nagios myself. Every new process, I wrote a check for it myself. There was no abstraction between me and the machine. If something broke, I knew exactly why, because I built the thing that was watching it.
Then I moved organizations, and Nagios grew up with me. Suddenly it wasn't one server and a few clients, it was a clustered setup monitoring 5,000 servers. A team of 10 DevOps folks, SaaS tools watching Nagios itself (yes, we had to monitor the monitor), and Icinga entering the picture as the better-looking cousin of Nagios. That's when things got serious.
This is also where I learned Nagios could do more than just "is the server alive." We started writing bash scripts and plugging them in to parse logs, actual business logs, to generate reports for sales and marketing. Number of deals closed, tracked through log monitoring. When those reports failed, guess who had to debug the script at odd hours. Character building, as they say.
I last touched Nagios seriously about two years ago, mostly for bare metal setups. Since then, I've worked with Prometheus, New Relic, Zabbix, the works. And they're good. Genuinely better dashboards, better scaling, better everything on paper.
But here's the thing nobody tells you about Nagios: it keeps you rooted to the system. You're not looking at pretty graphs from a distance. You're inside the OS, understanding processes, permissions, disk layouts, the works. When I automated Nagios setup with Ansible and later with Fabric in Python, things broke constantly. And every time they did, it was my old shell scripting instincts and my bare-metal Nagios days that bailed me out. That knowledge doesn't come from reading a Prometheus exporter's YAML file. It comes from getting your hands dirty.
I recently came across a blog from another engineer reminiscing about Nagios, and it hit me that I'm not alone. There's a whole tribe of "Nagios oldies" out there who get it. We know the newer tools are shinier. We use them daily. But there's something about Nagios that built our fundamentals in a way nothing else quite has.
Better monitoring tools may exist. But Nagios will always be the one that taught me how to actually understand a server, not just watch it.
I set up an MCP server for MySQL last month. Took maybe twenty minutes. FastMCP, running on port 9100, exposing a handful of database tools to any agent that connected to it.
Then I asked myself a question I should've asked before writing a single line of code. What exactly is this server trusting, and who gave it permission to trust that?
Turns out, the answer was: whatever connected to it.
Here's the thing about MCP servers that nobody warns you about when you're following a quickstart guide. The server doesn't inherently know the difference between "an agent I authorized to run read queries" and "an agent that happened to find my endpoint." If your auth model is weak or missing, every tool you expose is available to every connection that shows up. Credentials don't need to be stolen. They just need to be reachable.
I built this specific setup as a demo, deliberately, to see how bad it could actually get. Not theoretical. A real MySQL MCP server, real credential handling, real tools exposed. And what I found is that credential bleed isn't some exotic attack. its the default state of a lot of MCP setups people are shipping right now, without realizing it.
Think about what an MCP server actually does. It sits between an agent and a real system, translating natural language intent into real actions. Real database queries. Real Terraform applies. Real file writes. Somewhere in that translation layer, credentials have to live. And if that layer trusts the connection instead of the identity, you don't have an access control system. You have an open door with a "please don't" sign on it.
This is the same failure mode I saw with a Terraform agent demo I built separately. An ambiguous prompt walked straight through terraform_plan into terraform_apply and created a real S3 bucket in AWS. Nobody meant for that to happen. The agent didn't misbehave. The boundary that was supposed to stop it simply wasn't there. Same root cause, different door.
The uncomfortable part is that this scales with adoption, not against it. The more useful MCP servers get, the more tools get exposed, the more valuable the thing sitting behind that unguarded connection becomes. A vulnerable server nobody uses is a curiosity. A vulnerable server your whole team routes agent traffic through is a real incident waiting on a slow Tuesday.
None of this means don't build MCP servers. It means stop treating the connection as the identity. An agent proving it can reach your server is not the same as an agent proving it should be trusted with what's behind it. Ephemeral credentials, scoped tools, intent validation before execution, these aren't nice-to-haves you add later. They're the actual product. Everything else is just a demo that works until it doesn't.
I'll probably write up the full technical breakdown of the MySQL demo separately. For now, if you're standing up an MCP server this week, ask the boring question first. Not "does it work." Trust what, exactly.
Auto-posting my Telegram channel posts everywhere sounded like a dream. Then I actually built it.
The plan was simple. Write one post on my Telegram channel (@securedevops). Let a pipeline pick it up. Reformat it for each platform. Push it out to LinkedIn, Twitter, Instagram, Facebook, Dev.to. Zero manual work after hitting publish once.
I built it in n8n. A webhook catches new posts from the channel. A dedup check makes sure nothing gets posted twice. Then a handoff point where ChatGPT would rewrite the post per platform, and push it live everywhere.
Sounds clean right? It mostly worked. Until it didn't.
Here's where it broke. I was using ngrok's free tier to expose the webhook. Every time my machine restarted, the URL changed. Which meant every time I restarted, I had to manually go re-register the new URL with Telegram. A pipeline that's supposed to save me time now needed me to babysit it every morning. Not exactly "fully automated."
And the more embarrassing part. the actual multi-platform posting, the part that was supposed to save the most time, never got finished. I built the capture layer. I built the dedup layer. I stopped right before the part that mattered most.
Thinking about it now, this wasn't really an automation failure. It was a sequencing mistake. I built the fun part first. Webhooks, dedup logic, the architecture diagram in my head looking clean. The boring part, a stable public URL, I left for later. Later never came.
This keeps happening in infra work and I don't think its a coincidence. The AI reformatting step, the multi-platform posting, that was the exciting 20%. Getting a reliable endpoint that survives a restart was the unglamorous 80%. Everyone wants to build the 20%. Almost nobody wants to build the 80%. But the 80% is usually what decides if the thing actually runs unattended or not.
So the pipeline still sits there. Half built. Working, technically, if I remember to re-register the URL by hand.
Anyone else have an automation project that stalled right at the boring part? curious if this is a me problem or a universal one.
Because the loudest idea in the room is not always the best experiment.
In the last post, I wrote about the main experiment types: A/A, A/B, Split URL, and multivariate testing. I also introduced the formula that quietly changed how I think about experimentation:
Success = Chance × Frequency
Once that clicked, I assumed the next step would be simple.
Pick an idea > Run a test > Measure it > Repeat.
Then I actually tried to do it. Because once people around you start thinking in CRO terms, ideas come from everywhere.
The designer wants to test the hero image. The founder wants to rewrite the pricing page because “it does not feel premium enough.” Someone from sales heard that a competitor changed their CTA and now wants to copy it immediately. Someone read a blog at midnight and suddenly wants to add a chatbot, a quiz, a floating banner, and possibly a dancing mascot.
Before you know it, your experiment backlog looks like a Jira board after a chaotic sprint planning session.
Lots of tickets.
Very little structure.
Everyone convinced their idea is the one that will change the company’s destiny.
This is where prioritization comes in. Not because prioritization makes you smarter, but because it protects the experimentation program from becoming purely opinion-driven. And in CRO, opinions can multiply faster than credit card debts.
The Hidden Cost of Running the Wrong Test
At first, “let’s just test this” sounds harmless. CRO is about experimentation, right? Just run everything. But every test has a cost.
Even when the testing tool makes setup easy, a test still consumes traffic, time, design effort, analysis attention, and usually a couple of weeks of your roadmap. If your site has enough traffic to run two meaningful tests this month, and your backlog has twenty ideas, running the wrong two means you delayed the better ones. That is not a small cost.
This felt immediately familiar from Devops work. You do not deploy every feature request just because someone suggested it in a meeting with confidence and a nice slide deck. You triage. You look at impact, risk, effort, dependencies, and what the system is actually telling you before you start making changes.
CRO needs the same discipline. An idea is not valuable because it sounds smart in a meeting. It becomes valuable when it is connected to evidence and scored against other ideas in the backlog.
The HiPPO Problem
Before getting into frameworks, there is a force you need to understand. It quietly kills many CRO programs. It is called the HiPPO: the Highest Paid Person’s Opinion. Every team has one. In fact there is a rude saying about opinions. “Opinions are like…” (well… Google it)
The senior leader who says, “I think the button should be green,” and suddenly the next sprint is about button colors. The founder who saw a competitor’s landing page and wants to rebuild yours to match it by Thursday. The VP who has “a feeling” about the checkout flow. The stakeholder who says, “Can we just test it?” in the same tone people use before creating six months of technical debt.
To be fair, these inputs are not useless. People close to the business often have genuine intuition worth exploring. Sales teams hear objections. Support teams hear confusion. Founders understand positioning. Product teams know what users struggle with. The problem is not the idea. The problem is when the idea skips the queue without being scored.
In DevOps, we do not prioritize incident response based on who is shouting loudest in Slack. At least, we should not. We prioritize based on system impact and what the metrics are actually saying.
CRO needs the same structure. A prioritization framework is your polite defense against the HiPPO.
You are not saying: “No, your idea is bad.”
You are saying: “Great, let’s score it the same way we score everything else. If it ranks high, it goes first.”
That small shift changes the conversation. The framework depersonalizes the argument. The number does the heavy lifting. Very convenient, because numbers do not get awkward in meetings.
Start With the Funnel, Not the Idea
Before scoring individual test ideas, figure out where to look first. Not every page deserves equal attention. A page with very little traffic will take forever to produce statistically meaningful results. A page with high traffic but no meaningful business impact may still not be worth optimizing ahead of a page that sits directly in the conversion path.
Press enter or click to view image in full size
So before asking: “What should we change?” ask, “Where are we losing people?”, and then. Map your funnel.
Landing page > Form view > Form start > Form submit > Qualified lead
Then look at where the biggest drops are happening. If 70% of users are abandoning at checkout, testing a homepage headline is probably not the first move.
It might be interesting.
It might even win.
But it is probably not where the biggest leak is.
Analogy in DevOps: If the database is causing 90% of your latency, shaving 20ms off a frontend asset is not the priority. Sure, the frontend improvement may look nice in a performance report. But the database is still sitting there like an overloaded elephant in the server room.
Find the bottleneck first. Then fix it. In CRO, high-traffic pages close to revenue, signup, checkout, or lead generation are your hot paths. Start there.
Small disclaimer:Read at your own risk. This may make you hungry
The Two Frameworks: ICE and PIE
Once you know which pages to focus on, you need a way to score the ideas sitting in your backlog. Two common prioritization frameworks in CRO are ICE and PIE. Both are simple, both use overlapping dimensions and both are easier to remember if you stop thinking about frameworks and start thinking about food. Which, honestly, improves most business concepts. ;)
ICE: Ordering Food at Midnight
ICE stands for:
Impact
Confidence
Ease
Think of ICE as ordering food on delivery app at 11 pm. You are hungry. You are tired. You are already in bed. This is not the time for adventure. You are not trying to discover a hidden culinary gem. You are trying to avoid sleeping angry. You see a biryani place.
Before you tap “Order,” three thoughts happen automatically.
First:
“How good is this actually going to be?”
If it is bad biryani, why bother?
That is Impact.
Second:
“Can I trust this place right now?”
Will it arrive hot, on time, and with raita? Or will it arrive cold, late, and missing the one thing that emotionally holds the whole meal together? You check the rating, reviews, delivery time, and whether someone recently complained that they received only rice and sadness.
That is Confidence.
Third:
“How easy is this?”
Is the restaurant open? Is delivery available? Will it reach in 25 minutes, or will the app say “arriving soon” until you lose hope? Will it ask you to verify your phone number again even though it has known you for five years?
That is Ease.
ICE is practical and slightly paranoid. It wants evidence before committing.
In CRO terms:
Impact asks: If this test wins, how much could it move the business? Confidence asks: How sure are we that this is a real problem worth testing? Ease asks: How difficult will this be to build, QA, launch, and analyze?
Score each dimension from 1 to 5. Then average the three. The highest-scoring ideas usually go first. ICE works especially well when you already have research data: heatmaps, recordings, analytics, surveys, support tickets, or past experiment learnings. Low confidence should lower the score, no matter how exciting the idea sounds.
Because “I saw this on a competitor site” is not research. It is browsing with ambition.
PIE: Choosing What to Order When You Have Options
PIE stands for:
Potential
Importance
Ease
Now stay in the same food delivery app. You are still hungry. It is still 11 pm. You still should have eaten earlier like a responsible adult, but here we are. This time, you are not evaluating one biryani place. You are deciding what category of food deserves your attention first.
Biryani? Pizza? Rolls? South Indian? Chinese? That one “healthy bowl” option you add to cart and then remove after seeing the price? PIE helps you decide where the biggest opportunity is.
First:
“How good could this get?”
Could this be the kind of meal that fixes your mood, your evening, and possibly your belief in humanity?
That is Potential.
Second:
“How important is this meal?”
Is this a casual snack, or have you skipped dinner and now your stomach is sending production-level alerts?
That is Importance.
Third:
“How easy is it to get?”
Is it nearby and deliverable in 25 minutes, or is the restaurant far away, closing soon, and likely to cancel after making you wait?
That is Ease.
PIE is more optimistic than ICE.
ICE asks, “Can I trust this specific choice?”
PIE asks, “Where is the biggest opportunity?”
In CRO terms:
Potential asks: How much improvement could this page or funnel step realistically have? Importance asks: How valuable is this page or funnel step to the business? Ease asks: How simple or difficult is the test to implement?
PIE is useful when you are comparing broader areas of opportunity.
For example, if you are deciding whether to focus on the homepage, pricing page, checkout, signup form, or onboarding flow, PIE can help you decide where the biggest opportunity may be.
So, in food delivery terms:
ICE helps you decide whether to trust one restaurant. PIE helps you decide which food category is worth exploring first.
ICE vs PIE: The One-Line Difference
Press enter or click to view image in full size
Here is the easiest way I remember them:
ICE helps you decide whether to trust one restaurant. PIE helps you decide which food category is worth exploring first.
ICE is about confidence. Can I trust this specific option to deliver? PIE is about opportunity. Which area has the biggest upside if I focus there? Same food app. Different thinking.
With ICE, you are asking: “Should I order from this biryani place?” With PIE, you are asking: “Should I even be looking at biryani first, or is pizza, rolls, South Indian, or Chinese the better opportunity tonight?”
Both end with Ease, because nobody wants unnecessary complications at 11 pm. Especially not when they are hungry and the app is already saying, “Restaurant is closing soon,” like it is adding pressure to your life.
Which Framework Should You Use?
Use ICE when your team already has research data and wants to prioritize based on evidence. ICE is useful when you are evaluating a specific hypothesis. For example:
“Should we move the CTA above the fold on the pricing page?”
You already have heatmap data. You know users are not scrolling far enough. You want to know whether this specific idea deserves to be tested next. That is ICE.
Use PIE when you are earlier in the process and still deciding where the biggest opportunity is.
For example:
“Should we focus on the homepage, pricing page, checkout flow, signup form, or onboarding?”
That is PIE.
At Convert.com, the Compass feature includes both PIE and ICE inside the hypothesis builder. When you create a new hypothesis, you can choose a framework, score each dimension on a scale of 1 to 5, and use that score to sort your backlog.
That helps because the score becomes visible to everyone. It is much harder to push your pet idea to the top when the number is sitting right there on the screen, judging you quietly. A visible score is like the delivery rating on a food app. You can still order from the suspicious restaurant. But now everyone can see that it has 2.3 stars and seven reviews mentioning “never again.”
Turn Ideas Into Hypotheses Before You Score Them
Press enter or click to view image in full size
One thing both frameworks require is that your ideas are written properly before scoring.
“Change the button color” is not a hypothesis.
“Move the CTA above the fold” is not a hypothesis.
“Make the page look more premium” is definitely not a hypothesis.
That is a mood.
A proper hypothesis looks like this:
If I change X, then Y will happen, because Z.
The “because” is the most important part. Without it, you are not testing an assumption. You are just making a change and hoping the graph goes up, which is basically the CRO version of deploying to production and whispering, “Please work.”
Or, to stay with the food delivery analogy, it is like ordering from a restaurant with no ratings because the photo looked nice. Could it be amazing? Maybe. Could it be regret in a plastic container? Also maybe.
For example:
If we move the main CTA above the fold on the pricing page, more visitors will start the demo request flow, because heatmaps show most users are not scrolling far enough to see the current CTA.
Now you have something worth scoring.
You know:
The page
The change
The expected outcome
The evidence behind it
Even if the test loses, you learn something specific. A backlog full of vague ideas becomes a dumping ground. A backlog full of hypotheses becomes a learning system.
Or in food terms:
“Order something nice” is not useful.
“Order from a highly rated nearby restaurant because delivery time is low and reviews mention fresh food” is much better.
Specificity saves you from bad decisions. And occasionally, bad paneer.
The One Thing ICE and PIE Get Wrong
ICE and PIE are useful, but they share a blind spot. They often treat every idea as if it exists in a vacuum. But it does not.
Every idea exists inside the history of your previous tests. If you have run five tests on your pricing page and four of them lost, your confidence score for the next pricing-page idea should reflect that history. Something on that page may be resisting your assumptions.
Maybe the traffic quality is different from what you expected.
Maybe the real problem is upstream in the funnel.
Maybe people already understand the pricing page, and the actual friction is in signup.
Maybe your pricing page is innocent and has been framed by bad hypotheses.
The same applies to food delivery. If you have ordered from the same restaurant four times and three times they forgot the raita, you should not treat the fifth order like a fresh mystery.
You have history. Use it. Past experiment results should feed into how you score new ideas. They should not sit inside a spreadsheet named something like: final_results_v3_really_final_updated_NEW.xlsx
This is why documentation matters as much as the framework itself.
After every experiment, write down:
The hypothesis
The result
The confidence level
The primary metric
The key learning
What it suggests about the next test
Even a losing test is useful if it tells you where not to look. Without this history, your backlog resets to zero every quarter. With it, your scoring gets more accurate over time because you are building a picture of what your specific audience actually responds to. A CRO backlog without documentation is like a food app that forgets every bad order you ever had. You keep making the same mistake. And somehow, the raita is still missing.
What to Do When Everything Scores the Same
Sometimes three ideas all score 4.2 and suddenly you are back in the same argument. This is normal. Frameworks help, but they do not eliminate judgment. A few tiebreakers can help. Pick the page with the most traffic. More visitors usually means faster results and less time waiting for statistical significance.
In food delivery terms, this is like choosing the restaurant with enough recent orders and reviews. If only two people have ordered from it since 2021, the rating may not tell you much.
Pick the test that is fastest to build. A high-scoring idea that takes three weeks of development work may be worth doing after a slightly lower-scoring idea you can ship in a day. Remember the frequency side of the success formula.
This is the difference between ordering something that arrives in 25 minutes and choosing a dish that says “preparation time: 95 minutes.”
Technically, it may be great. Emotionally, you may not survive. Pick the test that teaches you the most regardless of outcome. Learning value is underrated. A test that answers a fundamental question about your audience is worth more than a test that optimizes something already working reasonably well.
In other words, do not only ask:
“What might win?”
Also ask:
“What will we learn even if this loses?”
That question saves a lot of time. And occasionally, a lot of ego.
Define Success Before You Launch, Not After
One mistake that shows up in beginner backlogs is choosing the primary metric after the test has already started. That is dangerous. If you look at enough metrics, something will always appear to have improved.
Clicks went up.
Scroll depth changed.
Form starts increased.
Time on page looked different.
Someone in Nebraska spent 14 minutes reading the footer.
But what was the experiment actually supposed to improve? Every test needs a primary metric before launch.
Demo requests.
Purchases.
Trial signups.
Form completions.
Revenue per visitor.
Pick one. Commit to it. Let that metric make the call. This is like deciding what “good food” means before ordering. Are you optimizing for taste? Delivery speed? Price? Portion size? Not waking up with regret? If you decide after the food arrives, you can justify anything.
“The biryani was cold, but the container was sturdy.”
That is not success. That is coping. You can still watch secondary metrics for learning, but the decision should rest on the primary one. And alongside your primary metric, define your guardrail metrics. These are the things you are not directly trying to improve, but cannot afford to break. For example:
If you are optimizing demo signups, lead quality should not drop.
If you are optimizing checkout completion, average order value should not fall.
If you are optimizing form completion, spam submissions should not explode.
If you are optimizing clicks, downstream conversions should not suffer.
This is the CRO version of SLOs. You define what success looks like and what failure looks like before you are emotionally invested in the outcome. A test that increases clicks while damaging qualified leads is not a win. It is noise wearing a party hat.
Or in food delivery terms: A restaurant that delivers in 12 minutes but sends the wrong order did not “win on speed.” It failed dinner.
A Practical First Backlog
If you are starting from zero, here is the workflow I would follow.
Map your funnel and identify the biggest drop-off point.
Use heatmaps, session recordings, analytics, surveys, and any sales or support feedback you can access.
Write down every test idea without judging too early.
Convert each idea into a proper hypothesis using the “If X, then Y, because Z” format.
Score each one using ICE or PIE.
Pick one high-scoring, reasonable-effort test.
Define the primary metric and guardrail metrics before launch.
Run the test.
Document the result and the learning.
Then re-score the backlog based on what you now know.
That last step is what most teams skip. And it is what separates a backlog that compounds from one that stagnates. A CRO backlog should not be a parking lot where ideas go to quietly disappear. It should be more like a living system.
Or, to stay on brand, a well-maintained CI/CD pipeline for learning. Every test should make the next decision smarter. Just like every food order teaches you something.
Restaurant is reliable.
Delivery is slow on weekends.
The “extra spicy” option is not a personality test you need to pass.
Never trust a place where every menu item has the same stock photo.
Learning compounds when you write it down.
The Real Takeaway
Prioritization is not about finding the cleverest idea. It is not about the biggest redesign. It is not about the most senior opinion in the room. It is about running the tests that have the best combination of meaningful impact, strong evidence, reasonable effort, and clear learning potential. Done consistently, this turns CRO from a collection of random experiments into a learning system. You find the biggest leaks, collect evidence, write hypotheses, score ideas, run the most valuable tests first, document what happened and then repeat.
The DevOps parallel is hard to miss. Good infrastructure teams do not just ship more changes. They improve how they decide what to change, how they measure it, and how they learn from it.
Good CRO teams do exactly the same thing. And the food delivery parallel is also hard to miss. The goal is not to order everything on the menu. The goal is to make better choices each time, based on what you know, what matters, what is realistic, and what you learned last time.
That is prioritization.
In the next post, I want to go deeper into reading results without fooling yourself: statistical significance, confirmation bias, and why the most dangerous moment in CRO is when a test is almost winning.
I work with Convert.com and write about the intersection of DevOps and experimentation. If you are building your first CRO backlog or trying to move your team away from opinion-driven testing, drop a comment or reach out. Happy to compare notes.
When my manager first mentioned A/B testing, I nodded confidently. I knew exactly what it was.
Except I didn’t.
In my head, “A/B testing” meant Apache Benchmark, the ab command-line tool DevOps engineers use to hammer HTTP servers and measure throughput. Requests per second. Latency percentiles. That kind of A/B testing.
What followed was a humbling unlearning. Concepts like Conversion Rate Optimization, variations, Split URL tests, A/A tests, I was reading all of this through a server engineer’s lens and none of it made sense at first. Why run experiments? Why not just change the code, redeploy, and see what happens?
That was my first mistake. And if you’re a technical person stepping into the world of CRO, you’ll probably make it too.
So, What Actually Is CRO?
Let me skip the textbook definition and use a story instead.
Say you’re selling a bestselling book online. You’re running ads, offering discounts, the traffic numbers look decent, but conversions are low. People are landing on your page and leaving. You’ve checked the backend, the server is healthy, the page loads fast. As a DevOps engineer, you’d call this “nothing to fix.”
But something is broken, just not in the infrastructure.
Conversion Rate Optimization (CRO) is the practice of understanding why visitors don’t convert, and systematically fixing it through experimentation. You introduce a change, a different headline, a reordered checkout flow, a new CTA button color, mark it as Variation A or Variation B, measure which one converts better, and iterate.
Simple math:
ConversionRate= (Conversions / Total Visitors) × 100
If 10 out of 100 visitors buy your book, your conversion rate is 10%. A CRO practitioner’s job is to move that number, but more importantly, to understand why it moved.
That last part matters. A random change that boosts conversions is luck. Understanding the reason behind the boost, that’s CRO.
The Hidden Cost of Ignoring CRO
Here’s a pattern that plays out more often than it should:
A business pours budget into ad campaigns. Traffic surges. Conversions don’t. They spend more on ads. Still nothing. Eventually someone realizes the problem wasn’t the ad, it was the landing page. Confusing layout, unclear value proposition, a checkout flow that made users feel unsafe.
By then, they’ve burned through their budget chasing the wrong problem.
CRO tools exist to surface these issues before they become expensive. Heatmaps show you where users click (and where they don’t). Session recordings let you literally watch a user struggle with your UI. Exit-intent surveys catch people right as they’re leaving and ask them why. These aren’t vanity metrics, they’re diagnostic tools.
As someone who spends a lot of time on observability and monitoring in DevOps, I found this framing familiar: if you can’t measure it, you can’t fix it.
Before You Start: Is CRO Even Right for You?
This is a question I wish someone had asked me earlier.
A/B testing requires traffic. Without enough visitors, you can’t achieve statistical significance, the confidence level that tells you a result is real and not just noise. Most CRO practitioners aim for 95% confidence, ideally 99%.
Here’s an analogy that clicked for me:
Flip a coin 3 times, get heads all 3 times. Is the coin rigged? Hard to say, could be luck. Flip it 1,000 times and get heads 900 times. Now you’re pretty sure something’s off.
That “pretty sure” feeling, measured as a percentage, is your confidence level.
If your site gets 200 visitors a month, running a statistically valid A/B test is going to take a very long time. Many A/B testing platforms offer sample size calculators, use them before committing to a test.
A Framework for Getting Started
When I started approaching CRO with more structure, things got clearer. Here’s the sequence that worked for me:
1. Define a Goal First
Don’t open a heatmap tool and start poking around without knowing what you’re looking for. Start with a concrete goal:
At a D2C roundtable conference I attended, participants were split into groups and given websites to audit, armed with CRO cards listing what to look for. Are visitors able to find what they need? Is the checkout frictionless? How long does the full journey take?
One presenter, Gursimran Gujral (Co-Founder at OptiPhoenix), walked through a heatmap that had driven several of their key CRO decisions. Seeing a real example in action made the whole framework concrete.
Auditing before testing gives you hypotheses. Hypotheses give your tests direction. A good hypothesis follows a simple structure: “If I change X, then Y will happen, because Z.” That “because” is what separates informed testing from random tinkering.
An example: If I change the CTA button text from ‘Buy Now’ to ‘Get Your Copy Today’, then more visitors will click through to checkout, because the new copy feels less transactional and creates a sense of ownership.
3. Pick the Right Tools
You don’t need everything at once. Start with one tool per job:
Funnel analysis: GA4 + LookerStudio, track where users drop off
Analytics alone won’t get you there. You need a dedicated testing tool to run controlled experiments.
4. Run Tests with Patience
One of the most common beginner mistakes is stopping a test too early because the early numbers look good (or bad). Let tests run for at least a week to account for day-of-week behavior differences. Trust the confidence interval, not your gut.
Resources Worth Your Time
These are the ones I actually found useful, not just names I’m dropping:
Ruben de Boer’s courses: practical, tool-focused, good for getting hands-on fast
CXL’s CRO Fundamentals: more rigorous, worth it if you want depth over speed
MeasureSchool on YouTube: excellent for GA4, GTM, and LookerStudio workflows
Baymard Institute: research-backed UX analysis, great for e-commerce audits
Robert Cialdini’s Influence: The Psychology of Persuasion: understanding why humans behave on pages is half the battle
For practice: volunteer your CRO skills to NGOs or small businesses. Real traffic on real sites teaches you things no course can.
The Real Takeaway
CRO isn’t a bag of tricks. It’s a discipline built on measurement, hypotheses, and patience, things that, honestly, aren’t that different from good DevOps practice.
You instrument. You observe. You form a hypothesis. You test. You learn.
The difference is that in DevOps, you’re optimizing for uptime and throughput. In CRO, you’re optimizing for human behavior. And humans, unlike servers, don’t always behave the way the logs suggest they should.
That’s what makes it interesting, and why I’m still learning.
If you’re a technical person who’s crossed over into CRO or is curious about it, I’d love to hear your experience. Drop a comment or reach out.
Posts
