In this episode of the International Web Effectiveness Podcast, Bill Hunt and Bill Scully tackle the challenge of overcoming the “IT line of death,” or the struggle to prioritize and move development tickets through the approval process. They share actionable strategies to enhance ticket clarity, streamline communication with IT, and effectively manage high-priority issues to improve global web presence
Key Takeaways
- Understanding the IT Line of Death: The “IT Line of Death” describes the challenge of prioritizing IT tickets amidst numerous high-priority tasks.
- Effective Ticket Writing: Ensure tickets are clear and detailed, outlining the problem, impact, proposed solution, and success metrics while suggesting solutions without prescribing implementation, to respect developers’ expertise.
- Prioritization and Simplification: Consolidate similar tickets to reduce backlog and streamline the process, and simplify complex issues into actionable steps with specific instructions to facilitate easier execution.
- Piggybacking on Existing Work: Leverage ongoing projects or existing work to address new tickets more efficiently, thus reducing redundant efforts and enhancing productivity.
- Building Relationships with Approvers: Develop strong relationships with approvers to foster better communication, gain insights into their priorities, and expedite the approval process for critical tickets.
Catch the Full Episode
YouTube: https://youtu.be/DZOwm8KNT3o?si=9R152gxYnGUkB_ry
Spotify: https://open.spotify.com/episode/2D2TzBunFyfAsMEyZKbJkt?si=sl2ykRb2QuqJ9nnuugizIQ
Transcript
Bill Scully: Welcome to Episode 8 of the International Web Effectiveness Podcast, where Bill Hunt and I, Bill Scully, focus on strategies and techniques to improve web presence and manage global websites. In our last episode, we discussed creative ways to leverage other people’s money to budget web projects. Today, we’re tackling a common challenge—overcoming the IT line of death, also known as getting your tickets into development.
But before that, I want to give a shoutout to Mario Fisher, who wrote a fantastic article and created an insightful visualization titled How Google Search Ranking Works on Search Engine Land. The article breaks down how new content is discovered, indexed, and ranked using systems like Alexandria, Superroot, Twiddlers, and NAVboost. These elements refine rankings based on user behavior, content relevance, and search intent.
Bill, I know you shared this article with me. Have you had a chance to dig into it?
Bill Hunt: Yeah, I think it’s a great visualization of how Google search ranking works. While we can’t say for sure that it’s 100% accurate, Mario’s research is well-sourced, and it provides an interesting look at how everything fits together. What stood out to me was the implications—not just for today but for the future. I’ve already noticed a lot of chatter in the industry.
What surprised me was how many people still don’t understand some fundamental concepts. And I know saying that might invite some backlash, but it’s interesting to see reactions like, “Wait, Google doesn’t retrieve a page in real time when it discovers a link?”
Let’s look at this visual breakdown. The article and the Search Off the Record podcast both discuss crawling, indexing, rendering, and ranking. It’s crucial to understand that when Google finds a URL, it doesn’t immediately fetch and process it. That’s a key nuance that people often overlook.
For example, if you run a crawl with Screaming Frog, you’ll notice a delay before results populate. That’s because the tool, like Google, avoids getting stuck in loops. Let’s say you have 100 pages on your site, and each page has the same navigation bar with 10 links. All 100 pages will report those 10 links, but Google won’t follow them immediately—it queues them for later to avoid redundancy.
Bill Scully: Right. And that ties into how Google prioritizes indexing. The article explains that Google determines priority based on factors like backlinks. If a newly discovered URL has a lot of links pointing to it, Google is more likely to fetch, render, and index it quickly. Then, it applies ranking factors.
Bill Hunt: Exactly. And that’s the crux of the article—getting indexed is step one. Nothing else in search happens until a page is discovered and indexed. We spend so much time on optimizations, but if our pages aren’t even getting indexed, none of that matters.
The section about Alexandria explains how URLs are queued and prioritized. Google likely prioritizes pages that:
- It has never seen before.
- Other websites consider valuable (based on backlinks).
- Have been submitted via sitemaps or Search Console.
The article also touches on refreshes. Google doesn’t just discover content—it revisits pages to check for updates. That’s where signals like material updates come in. John Mueller often emphasizes that minor changes, like updating timestamps, don’t count. But significant updates—new sections, rewritten content, or major structural changes—are meaningful signals for re-crawling.
One thing Mario didn’t mention, but is worth noting, is Bing’s IndexNow. If you want to understand how crawling and indexing are evolving, look at what Cloudflare is doing with IndexNow. Cloudflare developed a system called crawler hints, which signals search engines when content is updated. Instead of blindly re-crawling everything, Google and Bing can focus on retrieving genuinely new or changed content.
Bill Scully: That’s a great point. And it aligns with how Google is refining its approach. They’re looking for efficiency. They want to minimize redundant crawling and maximize the discovery of fresh, valuable content.
Bill Hunt: Right. And that’s something SEOs and content creators need to understand. It’s not just about technical SEO. Content teams need to grasp these principles too—especially those managing content reductions or consolidations. If we understand how Google discovers, queues, and indexes content, we can make smarter decisions about site structure, updates, and removals.
So, my takeaway? Read the article. Mario did an excellent job visualizing this process. Understanding these mechanics is critical if we want to improve visibility in search.
Bill Scully: Absolutely. We’ll include a link to the article in the show notes. Definitely check it out.
Anything else you want to add, Bill?
Bill Scully:
The level of detail he laid out is fantastic. I’ve never seen anything like this before. It aligns with most of what I’ve been reading over the past year. More people are getting into Google’s systems, but it’s not always clear how they work together. This really did a great job of putting it all on one page.
Yeah, this was excellent. So, go check it out, people.
Alright, let’s get into this week’s topic: getting through the IT line of death.
As most people know, teams often struggle to prioritize tickets, especially when multiple high-priority issues arise. Sometimes, decision-making is influenced by the people involved—there’s always someone involved—but there are strategies to help push your tickets through. I’d like to discuss some of those today with you, Bill.
I’ll start with one I often see during planning calls. You don’t want to be the person known for rejecting tickets because IT should have known better. Instead, you need to ensure that your tickets are clear. They should outline the problem, its impact, and a proposed solution—if you have one. Don’t tell IT how to do their job, but you can suggest an approach. It’s also crucial to define what success looks like. Include how they should test to confirm the task is complete. This helps approvers understand the urgency and ensures developers have the right information. Developers do a great job, but often, people don’t take the time to write tickets correctly.
Here’s an example I shared with you the other day. I was creating a ticket for a language redirection—redirecting a domain, like domain.com, to Italy if the user’s browser language is set to Italian. I spent a lot of time on it, thinking I had it all figured out. Then, the next morning, I realized, “Oh, I’m only telling them to redirect the dot com.” But what if someone adds a marketing parameter? That wouldn’t work. If I hadn’t caught that before submitting, we might have approved the ticket, only to realize later that it was flawed. Or worse, we’d get the work back, and I’d have to say, “Oh, that’s not what I meant.” So, that’s my take on it. What do you think, Bill?
Bill Hunt:
You’re absolutely right. The easier you make a developer’s job, the better the outcome. Everything you mentioned contributes to that. Here’s another example: We had a dozen Jira tickets, all essentially saying the same thing—broken links, redirects, etc. Different markets and agencies submitted them with varying levels of detail, and they sat in the queue, untouched.
When we reviewed them, we saw they were all addressing the same issue. So, we consolidated them into one ticket and took it a step further. Imagine a developer receiving a ticket that says, “Fix 37,000 redirects and 20,000 404s.” That’s going to be deprioritized instantly—if it even gets attention. The first thing they’ll ask is, “Where are these errors?” They’d have to crawl everything just to locate them.
So, we crawled it ourselves and found every single broken link. Turns out, the UX team had changed the header, altering the links—some redirected, others 404’d. Instead of saying, “Fix thousands of redirects,” we rewrote the ticket to specify: “Go into the header script and change these URLs.” It was a simple A-to-B fix. The revised ticket instructed them to update two templates, which affected all twelve markets. Suddenly, something that had been sitting in Jira for months was completed in ten minutes. We resolved twelve tickets with one clear, actionable request.
You mentioned simplification and quantification—both are crucial. We framed it in terms of impact: Fixing these redirects would resolve thousands of errors across multiple markets. That made it an easy priority.
One challenge we face is not insulting our developers. In my experience, developers don’t receive training on SEO-related issues. Take redirects, for example. Developers learn multiple ways to move users from point A to point B, and they usually choose the fastest option. That’s why we used to see so many zero-second meta-refreshes—it was quick to deploy. A proper 301 redirect, which is best for SEO, takes more effort, requiring collaboration with server managers or CDNs like Cloudflare.
Here’s a great example. I worked with a company that submitted a ticket requesting a canonical tag on every page. They copied an example from Google’s documentation. The developers implemented it exactly as written, without understanding its purpose. Within ten days, traffic plummeted, and thousands of pages dropped from Google. When we investigated, we realized the ticket’s wording had caused the issue.
That brings me to my main point: What defines “correct”? If you don’t provide a clear definition, developers will interpret the request in their own way. The best approach is to include detailed examples and QA scenarios. For instance, you could specify: “A user from Italy, whose language preference is Italian, should be redirected to this page.” That gives the QA team a testable scenario.
Bill Scully:
Exactly. The more prescriptive you are, the better. QA testing is often automated—someone runs a tool to check if the output matches the expected format. If you provide detailed test cases, they can plug them in directly, making it easier to verify success.
Bill Hunt:
Right. And in that ticket we discussed earlier, the proposed solution was to handle redirects in Cloudflare. That’s not ideal if you can manage it on the edge. Cloudflare workers introduce caching complexities, which can cause inconsistencies. Instead, you should specify where and how the change should be implemented.
The bottom line? Be as specific as possible. Provide examples, test cases, and context. That’s how you move tickets through the IT pipeline efficiently.
Bill Hunt: Everything you mentioned in your tips—I think we need to put that into a blog post—all those great suggestions on how to write the perfect ticket. In fact, I’m blanking on her name—she’s with SEO In-House. She used to have a training module on how to write the perfect SEO-friendly, developer-friendly ticket. She’s going to kill me for forgetting her name. I can picture her face, but it’ll come to me.
One thing I want to come back to is this concept of “The IT Line of Death.” There’s an interesting story behind it.
I had just come out of a meeting with the CEO of a company. The project they gave me was Google launching paid search—that’s how old this was. Google was going to all of this company’s clients, saying, “You don’t need to pay for traffic from them; we can send it to you. Just give us the money.” The company panicked. They realized, “Oh my God, our clients don’t need to come to us for traffic anymore.”
So, I wrote up a set of recommendations for what needed to change. The CEO told me, “Whatever you need, this is project number one. Whatever my resources are, your resources are.”
I walked into the CTO’s office, and he already knew what I was going to say. He said, “So, Steve told you that you can have whatever you need.” I replied, “Yep.” Essentially, he was saying, “Hey, you work for me now. Let’s get cracking on this. Here’s my list of stuff.” That’s when he introduced me to the IT Line of Death.
He pointed to a whiteboard and said, “Everything on this board was blessed by Steve or one of his subordinates.” Then he pointed to a faint dotted line down the middle of the board and said, “That’s the IT Line of Death. The reality is we only have the staff and resources to do what’s above that line. Yet every single thing on this list has been approved by the same person who told you that you have full access to all his resources. Unless you can get your priorities above that line—and that means you have to fight for it—it’s not going to happen.”
So, like we discussed, the number one way to move something above the Line of Death is to make it easy. Make a developer want to do it. The second thing I did that day was ask, “Do you have all of those write-ups? Where is the documentation for all those tickets?”
I went through every ticket to see if there was a way I could integrate an SEO requirement. For example, if I needed something like links in the navigation or changes to the homepage for content clustering, I looked for existing tickets that aligned with my needs. I found one listed as “Main Navigation Retooling.” It was already prioritized. I tracked down the owner, discussed my requirements, and we reconciled the changes. They had a proper taxonomist working on the logic, so we were able to incorporate about 70% of what I needed into their ticket. Since it was already blessed, funded, and prioritized, it only added about three hours of work.
I followed this approach for multiple tickets, embedding SEO needs into existing projects. For instance, if someone was working on site search improvements and site search was a major issue, I worked with them. Everything we needed for SEO also benefited site search. The site search team was frustrated with public criticism about their poor results, so they were happy to integrate SEO improvements into their project. We were able to incorporate 20 or 30 additional SEO requirements without raising new tickets.
One example was a boost list for site search. Not every team benefits from site search being perfect, but we did. We hardwired the homepage of a specific product to appear for its query. We also looked at the ranking signals site search used—titles, word frequency, and metadata. We needed to fix titles for SEO anyway, so we integrated that into their project without framing it as an SEO request. Instead, I just asked, “What do you need?”
What they needed included titles, meta descriptions, and, back in the day, meta keywords. These were all things we needed to improve Google rankings. Since we were addressing factors affecting site search rankings, every single item on their needs list aligned with ours. By the end of the day, about 85–90% of my critical SEO tickets found a home within existing projects. The remaining tasks, primarily content-related, weren’t in the development cycle, so we approached them differently.
We did a training on how Google discovers content. We used some light embarrassment tactics—pointing out cutesy, unclear headings—and introduced the team to Google’s keyword query tool. We taught writers to think about primary entities and sub-factors when structuring content. Instead of focusing on single keywords, we showed them how to map out query chains.
For example, if someone searches for “diabetes,” we could predict the next eight related queries. If someone is looking for “laptops,” we could anticipate their next questions. Teaching writers this approach allowed us to push content improvements much faster than if we had just posted tickets and hoped they’d be prioritized.
One of my strategies—whether it’s right or wrong, but it works for me—is using the 80/20 rule. I don’t flood the system with dozens of tickets every week. I create one, maybe every other week, depending on the size. High-effort tasks typically provide the most value, unless they’re fixing issues from an audit. For audits, don’t submit every small issue as a separate ticket. Prioritize key areas, like the footer and header, and work down from there.
For pages, prioritize based on impact and the need for links.
Bill Scully: That’s brilliant. There are two sides to this. Some agencies try to prove their value by submitting a high volume of tickets, knowing that not all will get done. But I love how you balance difficulty and value, focusing on tasks that aren’t too much work yet provide significant impact.
Bill Hunt: Exactly. In one of the next episodes, we’ll discuss the benefits of centralization. This is especially relevant when a single web development team handles changes for multiple markets, while multiple SEO teams are involved.
Bill Hunt: You need a dedicated team—going back to our Center of Excellence or our Search Console team—to manage these tickets. Bring them into this team, prioritize them using the 80/20 rule, and weigh their impact. It’s fascinating how some of the most extreme situations arise. I once saw a case where it took nine months to get H1 tags implemented on a page with a creative design. Then, a few months later, another audit from a trendy agency recommended removing all H1 tags.
There was a huge battle to get them in, and suddenly, an audit suggested taking them out. That made no sense. H1 tags are not going to harm us.
By having a group of experts, including members of your Search Console or Center of Excellence, you can properly vet these recommendations. It’s about assessing difficulty and value to the organization. That’s how you move things up the value chain. I keep coming back to centralization because it makes such a difference.
Just this week, I was asked to write a brief for a ticket. But I knew that upcoming work would undo everything the ticket proposed. It made more sense to wait a month rather than do the work now and redo it later in a different format.
One of the best strategies I’ve seen was a company funding a dedicated person whose primary job was writing tickets and attending scrum meetings. They were trained as an SEO but were more of a junior scrum master with project management and ticket-writing skills.
They listened for key terms like JavaScript, Angular, or redirects, then flagged those tickets for review. Since the SEO team couldn’t attend every meeting, this person acted as their voice, identifying potential SEO issues early. If they overheard plans to shift to Angular or React, they could intervene before performance was impacted.
Having this role ensured SEO had a seat at every meeting and translated SEO needs into project management and developer language. They wrote every test case because they understood how to validate it, making a huge difference in getting projects through. Even though we technically lost an SEO headcount, this role compensated by driving more work to completion.
This approach integrates SEO into the workflow, helping to avoid catastrophic issues before they occur. If you’ve tried all these methods and still find resistance, have you encountered cases where projects just don’t get approved? Maybe it’s not malice, but rather company priorities?
We discuss this in our business case course: identifying who is blocking progress. In some organizations, if a project doesn’t increase revenue or improve usability, it won’t get attention. That’s not necessarily malicious; it’s just perceived as unimportant.
One tactic I used was reviewing the company’s annual report. If it listed risks related to Google’s algorithm changes or declining organic traffic, I would link those concerns to my ticket. Not to embarrass anyone, but to provide justification. If the executive team acknowledges organic search as a business risk, you can tie your ticket directly to that concern. Quantify it wherever possible.
I’ve also used embarrassment effectively. My favorite trick was listing all submitted tickets, tracking their submission dates, and calculating how long they had been pending. Then, I estimated the lost traffic potential. If an unresolved ticket could have driven 10,000 extra visits per month, and it had been pending for five months, that’s 50,000 missed visits. Multiply that by the average CPC, and you get a clear financial impact. Showing the cost of inaction often moves tickets up the priority list. But you have to quantify the value loss for this to work.
It’s not enough to just submit a ticket and wait. You need to follow up, provide clarity, and build relationships with decision-makers. If you’re not in the meetings, you don’t control the narrative. Build trust with the approvers. They might even guide you to others with similar goals. No one wants unnecessary tickets clogging the system, so only submit those with clear value and enough detail for an informed decision.
Bill Scully: One bonus tip as we wrap up: something I learned from Frederick Septon of Septon & Company when working with Absolut. He introduced us to something called Scrum Bingo.
You create a board with all pending tickets and describe them. Developers can pick a ticket, complete it, and then spin a wheel for a reward. Prizes ranged from Swedish taffy to a $500 Amazon gift card. It was a great way to motivate people. Every time you solved a ticket, you spun the wheel and earned a bingo stamp. Five bingos won you a bigger prize.
It was amazing how many tickets we cleared using this method. It wasn’t that people waited until the end of the quarter to do their work, but this strategy helped close out a lot of lingering low-hanging fruit. They called it Scrum Bingo.
Bill Hunt: That’s a great idea. It’s like a hackathon, but structured around getting real work done. Putting tickets on post-its, letting developers choose one, completing it, spinning a wheel, and winning a prize—it turned ticket resolution into a game.
This is something global webmasters need to master. If you can’t get your SEO work implemented, your job becomes impossible. We should consider creating additional training around this topic.
Bill Scully: Absolutely. And for those interested, check out our courses. We cover everything from business cases for Hreflang to indexing best practices and centralization strategies. We have four or five new courses in development. Join our Facebook group, post your questions, and let us know what topics you’d like us to cover.
Bill Hunt: Great. Thanks, Bill. Talk to you soon.
Bill Scully: Thanks. Have a good one. Bye.